185 karma · joined September 30, 2024
Looks like it also supports some kind of models for JSON validation [0], it shouldn't be too hard to generate Swagger from them, just like FastAPI generates Swagger from Pydantic models.
So I left it in the state where the only thing you can do is to listen to ten descending gliders and that's it :)
Surprisingly, it still works, except now you have to click/tap anywhere on the screen to make the sound play. I think that 9 years ago browsers didn't have this feature and allowed sound to play right away.
Here is the link (CAREFUL, can be VERY LOUD): https://vovanz.github.io/conways_live_music/
Re templates: I understand that writing a new template engine can be a very fun task (it is both hard enough not to be boring and easy enough not to feel daunting). I also thought many times of creating my own template engine to fix things that I don't like in the language that I am currently using (mostly jinja2).
But if you intend this project to become an actual production ready solution, I see a lot of good reasons not to reinvent template language:
1. Forcing users to learn yet another template language is an additional entrance barrier
2. Tooling support. Existing languages might already have a good tooling support (coming from Python world: PyCharm supports both Django templates and jinja2 very well) including syntax highlighting, auto-complete, auto-formatting, linting etc. Are you going to create all of it yourself?
3. You mentioned planned migration from Python. How exactly I am supposed to manage templates during the transition period? Do I have to have two copies of each template: one in legacy language and one in your new language? If you had a template language compatible with Django/jinja2 [1] this problem would not arise.
4. Whether we like it or not more and more people are using LLMs for coding. This potentially could solve the issue of migrating templates. I expect LLMs to perform really well on the task of "translating" a template from a <popular template language A> to a <popular template language B>. The problem is that if your template language is brand new, LLMs probably didn't have enough examples in their training sets to "learn" its syntax. So, basically, you are setting up your users for a boring, tedious and error prone task of rewriting each template manually without a proper support from their IDE/editor. Meh.
BTW, Django makes it very easy to bring your own template engine [2].
[0] https://en.wikipedia.org/wiki/Not_invented_here
[1] https://github.com/mitsuhiko/minijinja
[2] https://docs.djangoproject.com/en/5.1/howto/custom-template-...
Also, I don't really understand what is the reason for creating your own ORM instead of integrating with, let's say diesel.rs [0] and what is the reason for inventing your own template language instead of just picking one of the most popular existing template engines [1].
Other than that this project looks really interesting and I will definitely keep an eye on it.
It's amazing how just one sentence can be so utterly wrong.
WSGI actually predates rack by several years: first WSGI spec was published in 2003 [0], rack was split from Rails in 2007 [1].
Flask is not an "application server", it is one of the web frameworks that implements WSGI interface. Another popular framework that also implements it is Django. Flask is not the first WSGI implementation, so I'm not sure why author decided to mention Flask specifically. It's probably one of the most popular WSGI implementations but there is nothing special about it, it hasn't introduced any new concepts or a new paradigm or anything like that.
I'm not sure if the rest of the article is even worth reading if the author can't even get the basic facts right but for some reason feels the need to make up total nonsense in their place.