> Usually, you throwaway all the cool things about Django and turn it into a stupid JSON API and then you build a bunch of cruddy shit with npm tooling and cry yourself to javascript dependency hell

Or you could just shift your backend expectations and adapt to the different needs. If you're doing an SPA because you want an app-like experience and very decisively not a website-like experience, your backend should be as simple and stupid as possible and not force you into a model like MVC; you shift much of the complexity to the frontend when you go from website to SPA. You know, like it would if you're writing a desktop app or a mobile app that uses an API. Because it's an application, not a website.

You could pull the 99.999% number out of wherever, but the truth is that many things we used to do as websites are better off as apps. My bank's website is better off as an app, the social networks I use work better as apps. Hacker news doesn't. Blogs don't. Online newspapers don't. It all depends on the amount of interactiveness needed and how much better the experience is with access to real-time information streaming and quick UI responses based on things other than data loads.

And as dreadful as Javascript dependency hell is, it's objectively better than Python dependency hell since it's had a passable package manager for much longer than Python (and even then, most Python devs still don't use or even know of Poetry) so the ecosystem is better aligned to modern software development expectations. You're just used to one variation of hell, and don't want to learn a new one.

Try to understand modern frontend needs before assuming newer frameworks are shit at everything and that everything related to it sucks. They might be shit at the specific thing you're doing, and some lessons seem to have been forgotten when things were redesigned.

What hasn't changed however, is how most software development sucks, and the fashionable things that were done under terrible standards (devs and/or management) have changed, but are still done by the same terrible standards so you still have shit results.

> VueJS is the only framework that allows you to progressively enhance something like a Flask based website in the most natural jQuery-like way.

No. You're just allergic to build tools because you have not enough knowledge of them. Probably because, from what I've been led to believe from your comment, most of your experience seems to be with Python. All your described problems ultimately stem from there.

Do social media sites really need to be SPA's? Does Twitter or Reddit really have to be a SPA?

Do Reddit really need the UI = f(state) paradigm? Is there much of any complex cross component state sharing that an SPA would be valuable there?

Here is an example of Hotwire with Twitter https://twitter.com/tonysmdev/status/1355996616361205760

Nope, they absolutely don't! And Reddit's SPA is a good example that is markedly worse than their old website. I was thinking of Facebook.

Twitter (and things like Instagram and TikTok) in particular is something where an SPA makes it easier to handle the different sections like the main feed, DMs, lists while keeping it responsive, but for those cases tools like LiveWire and Hotwire help make the gap between sites and SPAs much smaller and are an asset for avoiding having to rewrite websites into SPAs just for those smaller things.

But then you have cases like YouTube, where you could've argued that the initial case was a perfect fit for a website, and then as it has incorporated features like notifications, livestreaming with live chat, live donations with payment flows on top of the video and smaller things like the mini-player... you would end up with a huge amount of imperative JS sprinkled around your templates and carefully managed around your LiveView-equivalent's state updates; or you could just go with an SPA, vastly simplify your backend to be concerned on handling your data efficiently, and just having a frontend that makes managing complex state updates not-as-horrible.

It's trade-offs all the way down.

Agreed, but I think an SPA feels like optimizing way too early because of how far it seems you can get now with Hotwire etc.

Also with the pace of SPA's at the moment its a risky bet 2015 React code is nothing like 2021 React code with hooks and functional components etc. And Svelte is a new challenger which I really like but I'd try to avoid a lot of the SPA's as much as possible but when you have a page which clearly needs it you can drop it in. I hope we can somehow find a way to collapse the barriers a little more of SPA/SSR only and have 'sprinkles' of SPA when you need it for certain pages like large booking calendars or such. Maybe that's a silly and complex idea though.

But as you say if you were making a true 'appy app' today then that's an obvious SPA choice.

Instagram I'm very iffy on if that needs to truly be a SPA too, sounds like some Hotwire turbo-frames around some things could do the trick but I'm being arrogant here as I'm unsure.

Trade offs everywhere.

I’m allergic to build tools because I want zero JS in the backend.

Thanks for the counter, I have made previous attempts at App-like websites but have left me high and dry. There is something to be said about clarity and separation in MVC frameworks. I love MVC. I love boring tech.

Python dephell is no more after poetry. Have you used it?

I have! Poetry is definitely amazing. A while ago I had the misfortune of having to adapt an old Python 2 project with specific system dependencies, a mess of a C compilation pipeline and an annoying set of requirements.txt which made it pretty much impossible to convert (at the time at least), so I would say hell's not over for Python since it's simply been around too long with packaging being in a terrible shape and Poetry can't hope to solve all of it; but I'm sure this is not a problem if you're able to stick to current stuff in a greenfield project or if your brownfield codebase followed some semblance of good practices.

Then again, I would say the same for Node. Modern npm is much better than it used to, yarn 1 is even better (better DX between its CLI design and handling of vendored yarn's), and yarn 2 was magical in the smaller examples where I tried it, eliminating the need for node_modules.

Back on the topic for the SPA problem, I would suggest you take a look at Elm, at least for the learning experience. The Elm compiler ships all the tools you really need to be productive, it's performant, the Elm language gets across the usefulness of its state management model extremely well (unlike React, which is a terrible teacher) and as a bonus it will ruin you forever if you haven't seen functional programming actually being useful before.

Someone in this thread just posted Alpine.js. Literally made my day! This is what I want and would ever want in the kind of apps we build.

Node: I am not sure but so often do I come across a package that only works on a previous node version (say v10). How come Node is not backwards compatible? Node v14 should be able to run anything that runs on Node v10. This is a runtime, not some library. Also, I discovered recently about LTS and non-LTS versions of node. Who knew. The whole ecosystem is rickety and not up to standards IMO.

> Vue can be used just like jQuery without any nodejs tooling

You can, but you probably shouldn’t (outside of prototyping). It requires you to both ship the template compiler to the client, and to perform the template compilation on the client, on every single page load (vs serving a cached, pre-compiled JS file).

If you want to sprinkle JS onto an otherwise server rendered page, you’re better off with something like Alpine.js [1]

[1] https://github.com/alpinejs/alpine

You made my day. Thank you!

Hmm.. is jsx a standard tool these days for new React projects?

Sorry if this doesnt make sense. I am mostly backend/servers.

JSX is a way to express HTML but its a deception. It's all javascript that looks like HTML.

> Hmm.. is jsx a standard tool .. > Sorry if this doesnt make sense...

Dude! I am, like, humble-bragging here. I did some react UI, and i had to painfully adjust to jsx to import some components.

My question is, since i have to oversee a new interactive trading front-end thingy, should i push for jsx or plain html?

Thank for the reply!

Edit: grammar

Why was it painful? Learning JSX isn't that different from HTML.

If you're using React, and you're not using JSX you're gonna have a bad time. There is no option to work with plain html.