Wow I like it, simple like Flask, but with the HTML in the same file (as opposed to the jinja templates) which is a pattern I really like!
Makes me wonder if you could integrate this ambition to do the web-stuff in your Python file with the FastAPI/Pydantic BaseModel situation. Like a HTML templating library made out of Python data classes (or Pydantic BaseModels).
Either way, I respect the ambition! :) Always cool to see web stuff with Python.
Technically the string return type is just a shorthand, IIRC render_template returns a Response object that sets Content-Type and other things appropriately. But yeah it’s pretty trivial to create an HTML formatting library and use it with Flask. (I think there’s already libraries for the tag syntax, you just need to hook it into Flask, or literally any Python web framework really.)
I went over the docs and couldn’t find anything about state management and client/server actions.
I’m guessing this would be similar to LiveView? If so, I’m not sure Python will handle the concurrency as well as Elixir…
Edit: I see now that the goal is to compile this to JS, so I’m assuming it’s going to be quite the opposite of LiveView and will do everything on the client?
This looks like the regular server side web framework with helpers to create html. State is (likely) managed by using the appropriate python library, or just a global variable or dict if race conditions don’t matter.
Then why compile to JS? And what happens when the client performs any actions, e.g clicks a button that should send an outgoing request either from the client or from the server?
Would like to see a simple site built on it besides basic examples (can even be used as a tutorial to the framework). The components seem interesting but feels like will quickly get complex.
I would say, focus on what makes your web framework different.
i.e. if you want to implement py-to-js, don't also reinvent routing at the same time. Grab an existing py-to-js engine and make something tiny with it. If it shows the value of the idea, then it will be picked up by the wider community.
I like the idea of decorators for turning query and body parameters into function parameters, I haven't seen that before, however is there a syntax where I can specify many parameters without taking many LOC?
For example you could have ``@query("name", "age")`` and look at the function signature using the 'inspect' module to determine that name should be a str and age an int. Or maybe ``@query(name=str, age=int)`` .
Also, mention it uses ASGI in the docs, so people are reassured on how to deploy it. And list that it is already compatible with uvicorn and etc.
Which is still somewhat maintained by folks from Internet Archive because it's used by Open Library. I'm not entirely sure what the benefit is to using that library but it sure is a PITA to Google about with a name like that.
Readit News
Makes me wonder if you could integrate this ambition to do the web-stuff in your Python file with the FastAPI/Pydantic BaseModel situation. Like a HTML templating library made out of Python data classes (or Pydantic BaseModels).
Either way, I respect the ambition! :) Always cool to see web stuff with Python.
I’m guessing this would be similar to LiveView? If so, I’m not sure Python will handle the concurrency as well as Elixir…
Edit: I see now that the goal is to compile this to JS, so I’m assuming it’s going to be quite the opposite of LiveView and will do everything on the client?
What did you learn from doing this one?
What makes your framework different?
i.e. if you want to implement py-to-js, don't also reinvent routing at the same time. Grab an existing py-to-js engine and make something tiny with it. If it shows the value of the idea, then it will be picked up by the wider community.
I like the idea of decorators for turning query and body parameters into function parameters, I haven't seen that before, however is there a syntax where I can specify many parameters without taking many LOC?
For example you could have ``@query("name", "age")`` and look at the function signature using the 'inspect' module to determine that name should be a str and age an int. Or maybe ``@query(name=str, age=int)`` .
Also, mention it uses ASGI in the docs, so people are reassured on how to deploy it. And list that it is already compatible with uvicorn and etc.
However, fastapi manages this without a decorator, only a type hint. Is there any gain doing it like this?