The HTMX part and discussion of the Islands architecture is funny, because it reminds how Facebook originally positioned React.
People who use React will know that React expects you to tell it what component to mount your root component to; these days, that means the Application component, as most React projects are SPAs. But React was developed at Facebook specifically for this Islands type approach; you didn’t have a whole application built from React. Instead, you would have a largely static page, often with specific elements that already had static/light JS implementations.
You could build specific interactive components in React, mount them to static elements of the DOM you wanted to progressively enhance, and the rest of the page was still static. You can probably figure out why this was desirable; in 2013, the desktop Facebook experience was still largely driven by a server-side rendered PHP application; this progressive enhancement model allowed them to enhance the existing application gradually (or strangle it, if you prefer) without doing a stop-the-world rewrite.
One thing I don’t dig into much in the article is how these big tools like React are the product of larger projects and feel sort of like they make more sense in bigger scale applications. I’m excited to see people explore islands in more detail and I’m hopeful that they’ll fit into a nice middle ground between hardcore SPA and CRUD site with JS sprinkles.
Django is definitely a solid choice for most applications. It’s quite well-engineered and saves you from the headache of having to make a lot of choices yourself. It’s not best-in-class for anything, but “good enough” for everything:
The ORM is a bit clumsy and has some gaps in it when doing complex queries. But they keep plugging the gaps and it gets better every release. And like the post indicates it allows for some meta-programming and is quite pluggable when you want to work with custom types and has very good support for “advanced” Postgres features.
The templating engine isn’t great but good enough. Haven’t used it enough to comment on it more.
The routing is a bit awkward, requiring you to explicitly mention every single path. I liked it better how Rails did this where an entire class gets routed to a path with view methods (although in Rails that has some drawbacks too). With some hacking you can make Django work like this as well, and more cleanly by using decorators on the view (we did that in Django-Binder).
In case you need support for pushing data from the server to the client, its websocket support is not great, I remember only pain when trying to use Django Channels (but that was just around the time it was officially integrated). We wrote Django High Templar to overcome those issues, and that worked fine in production under relatively high loads.
And the same goes for Python - a solid language that’s easily picked up by newcomers, with plenty of (mostly minor) flaws that can be overcome.
Django is a “boring” solution in the right sense of the word. I’d definitely pick it over the overengineered mess of Java frameworks, for example. And it’s also more disciplined and less “magic” than Rails, which helps. Flask is a great light-weight alternative, but it requires reinventing a lot of wheels, and requires you to wire together more yourself, which is more likely to end up in a mess unless you’re very disciplined.
That’s all good and well, what made it stand out to me was being able to onboard a team with zero Django experience to productively contribute to web application development in 1-2 weeks.
The documentation is great, things are quite straight-forward and the layers and infra (testing for instance) are factored quite nicely to be clean but not too clean.
Documentation is definitely a plus for Django! And onboarding is indeed a lot easier when you have good docs. Python itself also helps with this, being quite straightforward and easy to read. And like I said, the fact that Django doesn’t pull too many magic tricks makes it straightforward to understand, too.
I realize my post might’ve come across as dismissive, but that wasn’t the intention. I just wanted to balance the conversation with some observations on how it can indeed be a great and solid choice, it also has its flaws that one should be aware of before committing a project to use it. If you go into a project well aware of the flaws you won’t get any nasty surprises. For example, if you have a project that’s quite heavy on complex queries or two-way data flow, you might want to think extra hard before using it.
I feel like this needs to be said, and I’ll say it here. I don’t believe the statement to be entirely true: “In software, there aren’t a lot of tools that are allowed to get old”
What the author might may be claiming is that old tools don’t get the spotlight as much as new tools. That seems to ring a bit more true in my ear.
The HTMX part and discussion of the Islands architecture is funny, because it reminds how Facebook originally positioned React.
People who use React will know that React expects you to tell it what component to mount your root component to; these days, that means the Application component, as most React projects are SPAs. But React was developed at Facebook specifically for this Islands type approach; you didn’t have a whole application built from React. Instead, you would have a largely static page, often with specific elements that already had static/light JS implementations.
You could build specific interactive components in React, mount them to static elements of the DOM you wanted to progressively enhance, and the rest of the page was still static. You can probably figure out why this was desirable; in 2013, the desktop Facebook experience was still largely driven by a server-side rendered PHP application; this progressive enhancement model allowed them to enhance the existing application gradually (or strangle it, if you prefer) without doing a stop-the-world rewrite.
At $work we’re actually doing exactly that with react. It’s not a common way to use react anymore, but it does still work quite well!
awesome ya that totally makes sense.
One thing I don’t dig into much in the article is how these big tools like React are the product of larger projects and feel sort of like they make more sense in bigger scale applications. I’m excited to see people explore islands in more detail and I’m hopeful that they’ll fit into a nice middle ground between hardcore SPA and CRUD site with JS sprinkles.
Django is definitely a solid choice for most applications. It’s quite well-engineered and saves you from the headache of having to make a lot of choices yourself. It’s not best-in-class for anything, but “good enough” for everything:
And the same goes for Python - a solid language that’s easily picked up by newcomers, with plenty of (mostly minor) flaws that can be overcome.
Django is a “boring” solution in the right sense of the word. I’d definitely pick it over the overengineered mess of Java frameworks, for example. And it’s also more disciplined and less “magic” than Rails, which helps. Flask is a great light-weight alternative, but it requires reinventing a lot of wheels, and requires you to wire together more yourself, which is more likely to end up in a mess unless you’re very disciplined.
That’s all good and well, what made it stand out to me was being able to onboard a team with zero Django experience to productively contribute to web application development in 1-2 weeks.
The documentation is great, things are quite straight-forward and the layers and infra (testing for instance) are factored quite nicely to be clean but not too clean.
Documentation is definitely a plus for Django! And onboarding is indeed a lot easier when you have good docs. Python itself also helps with this, being quite straightforward and easy to read. And like I said, the fact that Django doesn’t pull too many magic tricks makes it straightforward to understand, too.
I realize my post might’ve come across as dismissive, but that wasn’t the intention. I just wanted to balance the conversation with some observations on how it can indeed be a great and solid choice, it also has its flaws that one should be aware of before committing a project to use it. If you go into a project well aware of the flaws you won’t get any nasty surprises. For example, if you have a project that’s quite heavy on complex queries or two-way data flow, you might want to think extra hard before using it.
I feel like this needs to be said, and I’ll say it here. I don’t believe the statement to be entirely true: “In software, there aren’t a lot of tools that are allowed to get old”
What the author might may be claiming is that old tools don’t get the spotlight as much as new tools. That seems to ring a bit more true in my ear.
Totally hear you!