Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lively.next Stability and Release Roadmap #1666

Open
neolay opened this issue Aug 1, 2024 · 2 comments
Open

lively.next Stability and Release Roadmap #1666

neolay opened this issue Aug 1, 2024 · 2 comments
Assignees
Labels
💬 ideas welcome For feature ideas where more input on design decisions and conrete direction are warranted.

Comments

@neolay
Copy link

neolay commented Aug 1, 2024

Congratulations on the relaunch of the lively.next website! It's great to see the latest developments in lively.next. I think lively.next has tremendous potential to become a widely used and popular programming kit.

Morphic has always captivated me. It allows me to think about user interfaces in the same way I think about the physical world. I've worked with morphs in both Snap! and Lively Kernel, and both implementations use an imperative style. I evolve morphs through direct manipulation, with instances of these morphs existing in memory. For long-term use, serialization or manual extraction of symbolic descriptions is often required. While direct manipulation is wonderful, serialization or manual extraction can be cumbersome and sometimes lead to confusion. The Lively PartsBin used to be quite active but has since become rather quiet, many objects might never be lively again...

Fortunately, we now have the new lively.next! The concept of Reconciliation is very elegant and might represent the future of Morphic. It still involves direct manipulation, but this time we can directly have the symbolic descriptions of visual entities, which is fantastic! Declarative code for components is easier to maintain and reuse, state and behavior are also separated via ViewModel. All of this is thanks to the outstanding work you both have done in recent years!

I am an early adopter of lively.next. In fact, I have already been working with it for a few weeks and I am very impressed. However, the stability is not yet where it needs to be, particularly with Reconciliation. I will report specific issues in separate tickets.

In this ticket, I’d like to ask a broader question: How far are we from releasing a stable version? And do we have a roadmap to reach this milestone? This is also related to #998.

I look forward to the continued evolution of lively.next.

@linusha linusha self-assigned this Aug 2, 2024
@linusha linusha added the 💬 ideas welcome For feature ideas where more input on design decisions and conrete direction are warranted. label Aug 2, 2024
@linusha linusha pinned this issue Aug 2, 2024
@merryman
Copy link
Member

merryman commented Aug 5, 2024

Hey @neolay, thanks for being a user of the project! We really appreciate it.
The way things stand right now, I am hoping to spend the remainder of this year fixing bugs with regards to the following things:

  • Bugs and performance issues with layouts
  • Bugs and performance issues in style policies (in particular due to interference with layouts)
  • Refactoring of the reconciliation and even out bugs here
  • Make lively.modules work with esm servers that are based on import-maps
  • Provide source mapping support for lively.next

With regards to #998 I am not so sure we can get there during this year but I agree that it is key towards a truly first stable version of lively.next. Timing wise, it will depend a little on how much we prioritize features we want to implement vs stability. Currently I am leaning a little towards that latter. If that works out, we can maybe expect a stable lively.next by the end of 2025. Fingers crossed.

@linusha
Copy link
Contributor

linusha commented Aug 6, 2024

Two cents to add to everything @merryman already said:

I'll not be continuing developing lively.next with the same capacity as previously, but I'll still be here to iron out bugs and UX problems.
For this, any reports of problems are extremely valuable! I know, that it sometimes can be frustrating and a lot of work to report issues, but we'd really appreciate anything you find! This is especially true for the reconciliation! In our experience, it is extremely hard to pin down the root cause when someting goes awry here, as one usually does not look at the code all the time, but only sees after a bunch of changes that something went wrong. However @neolay, if you are able to reproduce a problem, ideally with code example/screencast of something that does not work, any report is invaluable!

I am still extremely interested in tackling #998, but have to confess that part of the problem is that we are not exactly sure how to design such a system. The problem lies not so much in the implementation, but rather figuring out what one really wants and what an elegant design for this needs would look like. I am not sure yet, how much time I can spend on actually researching this. In the meantime, I am honestly waiting for a "lightbulb moment"...if/when that comes is unfortunately hard to predict. 🙈

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💬 ideas welcome For feature ideas where more input on design decisions and conrete direction are warranted.
Projects
None yet
Development

No branches or pull requests

3 participants