Lona 2

[fscherf]

Currently i am collecting ideas for the next generation of Lona. Some of mine would mean breaking changes, therefore i intend to release a new major version.

None of these ideas are set in stone.

Ideas:

1. HTML: Currently the HTML api is divided into nodes and widgets. That's because i wanted widgets to be able to have multiple root nodes. Its a cool feature, but brings a lot of complexity with it. Also it seems not to be that necessary. React and angular for example require components to have exactly one root node and it works fine for them. I would merge the features of widgets and nodes into a class named "Element". That would make rendering easier and would make naming more consistent with the DOM API in the browser.
2. Client: Currently the Client requires the client pre compiler module in lona, which is a poor-man's-javascript-compiler. At the time i wrote it, i didn't know better, and i want to get rid of this component now. I already started refactoring the Client to simple javascript modules, but this will change the API slightly.
3. Frontend Widgets: Currently Frontend widgets are no real javascript classes but hacky functions. I want to use classes here and overthink the API names (i am not to happy with the hopk names "setup" and "deconstruct")
4. Responses: Currently all view responses are dicts and get parsed by the respons parser module. I want to get rid of this component by introducing Response classes like "HTMLResponse", "Response", or "JSONResponse"

Update: I started working on a version of the client version that does not require a pre compile stage at runtime, and it seems to work fine. I realized that porting the client side rendering, which works with special DOM comments, to make multiple root nodes in widgets work, is a lot of work, if the whole API should be refactored anyways. I also realized that this piece of code would be much simpler and easier to maintain if it was rewritten in Typescript, instead of plain Javascript.

At this point i am reimplementing the whole rendering system. To make the switch as smooth as possible we will support both renderer at the same time for a short period of time (not in a released version, but on a dev branch). I will notify you guys here when a first showable version is ready for comments.

@maratori, @korantu, @grigolet, @laundmo, @SmithChart

[laundmo]

I would still argue that being able to run as a ASGI app would be a great feature, but since I don't have any usecase for Lona and dont foresee having one in the future either my opinion can easily be disregarded.

[korantu]

My first project with Lona is working well. I dont have another in the works at the moment, but in general I think moving to simplicity is good idea, even at incompatibility cost.

[fscherf]

@laundmo: I think it's a good idea, i had just no time to look into it in the past.

We can add this feature at any time, without breaking the API i think.

[SmithChart]

1. HTML: Currently the HTML api is divided into nodes and widgets. That's because i wanted widgets to be able to have multiple root nodes. Its a cool feature, but brings a lot of complexity with it. Also it seems not to be that necessary. React and angular for example require components to have exactly one root node and it works fine for them. I would merge the features of widgets and nodes into a class named "Element". That would make rendering easier and would make naming more consistent with the DOM API in the browser.

I like the idea of merging those two together: Why can a Widget handle it's events but a Node can not?
I just grepped through my work and private lona codebases and could only find one widget (out of like 20) that actually used multiple root-nodes. I would be fine loosing that capability.
And for me migration should be straight forward.

2. Client: Currently the Client requires the client pre compiler module in lona, which is a poor-man's-javascript-compiler. At the time i wrote it, i didn't know better, and i want to get rid of this component now. I already started refactoring the Client to simple javascript modules, but this will change the API slightly.

3. Frontend Widgets: Currently Frontend widgets are no real javascript classes but hacky functions. I want to use classes here and overthink the API names (i am not to happy with the hopk names "setup" and "deconstruct")

I do not really have an opinion on these two :-)

4. Responses: Currently all view responses are dicts and get parsed by the respons parser module. I want to get rid of this component by introducing Response classes like "HTMLResponse", "Response", or "JSONResponse"

And these classes then exist in Javascript and Python?

[fscherf]

Thanks for the feedback! :)

I don't understand the last question: What has the Javascript to do with the return type of the LonaView class?