Wow, hearing about “tea mushroom” (that’s how it’s called in Ukraine) for my whole life, and it’s not a mushroom!
Fascinating.
1,342 karma · joined February 7, 2008
Fascinating.
I also really liked an idea about class-less CSS frameworks, as I was frustrated with all the `<table class="table">` and so on. Then I've tried it for one project where I had to integrate Leaflet map on a page. And it's just not possible to do with class-less CSS frameworks.
Since then I write `<table class="table">` and have zero problems with that.
How would you do that with Figma, YouTube, etc?
It has "actions" that bridge a need for some client-side interactivity, without resorting to write lots and lots of JS. I have some interactive stuff that don't touch server. Also it's pretty easy to add more actions when needed.
And if I need to do something really complex, I can just go and read its source code. Which is really hard to do with unpoly and its really complicated OOP style.
SQLAlchemy is leagues above and beyond Django ORM. I can’t say I have nightmares from dealing with it, but it certainly was not pleasure. A bit too much magic here and there, not flexible enough and provokes too much bad practices. Re-defining save() methods to do a lot of work, anyone?
The best “orm” that I’ve ever used was not an ORM but a query builder — HoneySQL from Clojure. That one is fantastic. No ORM bullshit, no extra data loaded from DB, no accidental N+1 queries. Not reading docs on how to do a GROUP BY, everything’s just easy to write.
Frankly, we often use SQLAlchemy as just a query builder too. Makes life so much easier.
I know you didn’t mean Low Earth Orbit agency, but the thought is funny.
If you’re not more than 1000+ km from the nearest satellite, you’re not in a remote area!
I’ve been using Django templates since 2006. Jinja was designed after Django templates of that era, fixing their most glaring problems. Don’t remember the exact year when I started using Jinja a lot. Maybe 2013.
For example, a pure existence of an {% include %} tag. People use it, implicitly passing many arguments to some other template. Which makes it very hard to understand and change later.
Macros are not that pleasant to use, there are less features in macros then in Python functions, and tools support is much worse too (static analysis, formatting, etc).
Filters… why do I need to write `value|string` instead of `str(value)`?
Etc.
…and impossible to understand and keep track of what goes where.
No, thanks. Components are a good idea, and no imports is a horrible idea.
How does the performance side of this thing look like?
It’s modeled after Django templates circa 2005, and that was designed with an idea that designers will write those templates, that they are not code.
I’m doing all this for 18 years, it was always programmers who wrote template code.
Why then we have such things as filters, in addition to functions? Untyped macros. Formatting template code is a struggle. Include tags are the worst.
The only thing I fear with regard to all these component libraries is performance. I actually wrote a PoC myself for such a library, but didn’t bring it to production quality.
Pretty interesting idea. Do you have any stories or experience to share when going with this approach?
I assume that if you do it this way, then you see a string key in logs, views of current/locked queries, etc. Which should immensely help when debugging any kind of problems.