Show HN: I built a Python web framework
github.com
been working on this for nearly a year
github.com
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?
What's the rationale behind view.py?
However, my opinion is that is a PITA that every Flask project has a different structure, unlike a "batteries included" framework like Django, Rails, etc.
However, the focus has moved to py4web [1] which has many of web2py's strengths (including the DAL), but with a more orthodox architecture at the cost of a little more complexity and a slightly steeper learning curve.
Edit: It looks like some of the hot-paths are implemented in C. Interesting! (I would recommend pointing this out in the readme)
this exactly. stop handwaving vague marketing terms, and spell out the technical reasons. this isn't good enough for a show HN imo
edit: just read that OP is 15 yo. ok, i get it. well, treat this is advice to improve your technical documentation, it'll do wonders for your career :)
Aside my web involvement I did a lot of print design as well. For print wysiwyg is perfectly fine.
But how would you wysiwyg for a medium that is inherently multifaced? I mean your window could be small, or huge, portrait or landscape, it could have colors or not, heck it could even be print.
So you won't get what you see unless you replicate the exact conditions under which it was seen when tou made it. Do you want that thing that you scale to stay at fixed size, should it stay at fixed distances to the viewport borders? If yes which ones? What happens if users set their font sizes differently and your perfectly scaled text box overflows? Either that wysiwyg editor has very opinionated choices that won't work for half of the people, or it will have auch a complexity in its options you will be better off with learning css in the first place.
Web is not print, nobody will get what you see.
That being said, if you are really just about content, I would just use the most basic default browser css (so basically none) and html and call it a day. That won't look shiny, but if people want shiny they can do their own styling. Some of my favourite blogs do this.
Other than that I wouldn't discount the fact that a backend can be a crucial part of the content as well as it allows you to do valuable things that are geared towards the consumption of said content, e.g. taxonomy (tags, categories, authors, consistent dates), but also more specialized things like linking between relevant topics, etc.
Of course you could also do that by hand, but then you wouldn't be focusing on the content, wouldn't you?
In the end it is your content and you want to present it in a certain way. If you want precise control over the how, you have to deal with these things — if it ia just about the content, use whatever CMS you like and never look back.
It is doable, but it requires a stable runtime. Just the HTML/CSS ecosystem is too flaky, and HTML/CSSS is a poorly design system for this type of interactive systems/apps.
1997 calling, they say they have that wysiwyg tool you’ve been waiting for.
Web frameworks need to be a visual medium where you can create ui using visual tools and the "backend" side of things merge seamlessly.
And by headless I mean something which builds on what the web provides like buttons but adds a whole lot more of components which are used but are unstyled.
Second, the graphical niceties of these platforms often run "in-process", and save what is basically code in the same database as content. This will anger most Smalltalk fans, but I think this style of development is a bad idea. I want to know that some folder full of source code is the program, and some other folder is the data, and that if I back up one or the other, it will be independently usable.
I'm not saying 90s IDEs were perfect, but I don't think there's been any successful successor to their style of development. Graphical GUI builders exist, but they usually don't support making web apps, and after working with modern JS GUI frameworks, manually syncing GUI state with app state seems antiquated and needlessly bug-prone. I suppose QML with Qt Creator comes closest.
You probably don’t want to know how Electron works then!
That would be completely ordinary with Smalltalk.
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
1984 Smalltalk-80 The Interactive Programming Environment page 46
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
Solving this “problem” just doesn’t seem like a good use of a time. There are now 4738484 different viable ways to build a website, adding another way is just a waste of everyone’s time
The problem is the amount of boilerplate and tool complexity involved. In a large project, the boilerplate can become a small fraction of total work put in (hopefully), with most to the work spent expressing the logic of the application.
In smaller projects, the boilerplate can be the vast majority of the work. Building a backend, a frontend, and a communication protocol between them (that includes reactivity). On the backend you need to learn HTTP/Websockets and a backend framework. On the frontend you need node, nvm, npm, yarn, React/Svelte/Vue. To do it right you need to implement automatic reconnect/resubscribe on reconnect, etc.
Several projects try to reduce this complexity in various ways, but they all have trade-offs and I don't think we've found a sweet spot. Drag and drop tools like Squarespace and Retool are heavily biased toward expressing UI and integrate clunkily with backend logic. Backend-based tools like Streamlit and Pynecone (Reflex) get closer to a sweet spot IMO but are either severely limited in what you can do (Streamlit) or ultimately expose you to the full complexity of the frontend (Pynecone).
I think further work in this space is warranted.
I have a good example of a small-scale problem that's a b** to solve with web technology.
In a nutshell, I have an application which sends batches of data to a remote client. On the far end, I want a little web app that pays attention to the incoming queue of batches, display that list of batches in a browser, each batch with a progress bar, and be able to click on a batch to start the next stage of processing it when the batch is ready.
making real-timeish display updates should be a canned function but there is a lot of frontend/backend stuff going on to make it work.
> I think further work in this space is warranted.
what he said.
These two solutions can address all of these examples I can think of for a "simple" site:
- static blog site
- interaction with a database
- interaction with external APIs
- simple games (Django is based in Python)
- more complicated interactivity (pick a language that's compatible with Wasm)
I wrote one in PHP and 3 devs were able to build and maintain a 800 page CRUD system with it (still going strong, makes a ton of money). It has complex business logic, is fully unit testable and allows for escape hatches when needed.
I'm in the process of rebuilding the DSL in C# with the lessons learned (because Entity Framework is awesome). And might open source.
About the framework, I just read in a comment below about Java's Vaadin framework and it looks very similar to what I made in PHP. It's code that generate UI.
See https://vaadin.com/docs/latest/components/crud
Please check my profile in a month. I'll publish contact info.
"Streamsync is an open-source framework for creating data apps. Build user interfaces using a visual editor; write the backend code in Python." [0] https://github.com/streamsync-cloud/streamsync
Personally, I think it's a great direction and hope it sticks.
is the biggest question here..
And I can't center a div without a google search...
(I am a back-end dev tho, so its a little better than it sounds)
I know I don't mention my age because I want people to judge my work objectively. (not to imply that I'm a teenager...)
Edit: ML research at Apple[0]
Internet latencies should be in single digit to low double digit milliseconds range.
I would expect the slowest of web frameworks in bash to parse and route an http request in 1ms, so even if you replaced that with a hand written custom assembly version running at 1nanosecond, that would still be dwarfed by the networking jitter.
I supposed that's one way to judge environmental footprint. Pretty sure the climate activists would be unhappy about it though. ;)