For a long time I was in the server-side html + js for ajax/validation/effects camp, but I'm starting to gravitate to the SPA side of the fence.
Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed.
Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloading a blob of gzip'd html, but wouldn't it be better to flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?
A SPA combined with websocket connections allows you to implement the, "don't call us, we'll call you pattern". Granted, for mostly static sites this isn't particularly useful, but still, in principle, only consuming server-side resources when state has changed is a "natural" goal I'd argue.
There are tradeoffs with both approaches, but I'm leaning toward SPAs more and more.
You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.
I’ve never used Stimulus, but I can concur that Turbolinks is magic, at least for the simpler Rails app I made. It took load times from over one second to feeling like a native app, didn’t require any changes on the backend (it’s enabled by default in Rails), and the site works just fine without it, for those of us who like blocking third-party JavaScript.
Just looked at stimulus. Really cool framework. circa 2008 or so there was this concept of non-intrusive javascript where you bind js to elements. So you could wysiwyg html and then inject js where you need it. Thought that was a neat idea and like what stimulus does it. Any real life experience from anyone ?
Just for context, Stimulus is written by the same people who make Rails, Turbolinks etc - Basecamp. In fact, primary author Sam Stephenson was the author of Prototype, which was the library that inspired the creation of jQuery.
Stimulus and Turbolinks 5 don't have to be used together, but when they are it's a beautiful thing. That's because Stimulus uses the MutationObserver API to observe for DOM changes (eg. loading a new view in response to a click). It is the nicest event handling concept I've ever worked with.
Let me know if you need any help getting up and running. I'm not involved but I'm a big fan.
For what it's worth, if you are impressed by the reasoning and design-thinking that created these libraries, I encourage you to try Rails sometime as well. I still consider it the best way to build a web application for 90% of use cases. I'm happy to answer any questions you might have.
Turbolinks will work great with Django, but I recommend configuring your stack to automate the inclusion of the Turbolinks-Location header in your responses.
> clicking around a site, waiting for server responses, when nothing has changed
> flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?
What are they clicking on that is being useless? Are you putting buttons on your page making requests for no reason?
When its server side you send them a mostly-static page with a bunch of links or submits to make more requests with. All those requests are for either sending data back or getting something new off the server. If your use case would involve a lot of user generated input in a streaming fashion then yes, SPA client side programs are th way to go, but if all you are doing is throwing mostly-static CRUD applications you aren't getting an efficiency advantage dumping all the data on the user at first request and then hoping to only get one response of everything they want changed later. You're burning a ton of client memory and CPU cycles to do work you could have done more efficiently with page caching on your end anyway.
Why not just make the traditional site, and then add what, a dozen or so lines of JavaScript (or some backend frameworks will do it for you) to make form submissions/links into XHR calls dynamically.
Also - using WebSockets for a one-way communication channel is ridiculous. I know it's the cool kid way to do things, but that invariably means it's over hyped and has a more appropriate alternative. In this case, it's EventSource/Server Sent Events.
Also - using WebSockets for a one-way communication channel is ridiculous. I know it's the cool kid way to do things, but that invariably means it's over hyped and has a more appropriate alternative. In this case, it's EventSource/Server Sent Events.
I have some sympathy for your view here, but there are some other practical concerns as well in this case. For example, EventSource/SSE are not natively supported on IE/Edge but WebSockets are, so how well whatever you need to do works with your chosen polyfill is a factor.
Oh, I agree, and under normal circumstances EventSource + polyfill is what I'd use too. I'm just pointing out that it's not always as simple as overhyped things being used only because of the hype, because sometimes there are genuine technical differences in areas like compatibility or performance as well.
Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed.
Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloading a blob of gzip'd html, but wouldn't it be better to flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?
A SPA combined with websocket connections allows you to implement the, "don't call us, we'll call you pattern". Granted, for mostly static sites this isn't particularly useful, but still, in principle, only consuming server-side resources when state has changed is a "natural" goal I'd argue.
There are tradeoffs with both approaches, but I'm leaning toward SPAs more and more.