4 ms·

This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we s

by candu 7y ago

This is the part that often gets forgotten in these discussions: it shouldn't be "SPA for everything" vs. "vanilla HTML / CSS / JS for everything"; rather, we should be using the most appropriate set of tools for the job. I've worked on simple static sites, for which I typically lean more on vanilla HTML / CSS with a sprinkling of JS as recommended here. I've also worked on heavy-lifting applications, for which the limitations of this approach quickly become evident; in those cases, I use reactive component frameworks like Vue and React. But there's also approaches in between! For mid-complexity sites / apps, I've used vanilla HTML / CSS / JS, with some additional Python / Makefile plumbing to generate more repetitive parts. I've also used hybrid approaches, where vanilla HTML / CSS / JS is used for more static parts of the site and Vue is used for more dynamic parts. You can use Vue in full-on SPA mode with "server-side rendering"...but you can also just generate HTML server-side as you would have before, then progressively enhance parts of it with Vue / jQuery / whatever. I've also used "unfashionable" frameworks like Spring before, simply because it met the client's available in-house expertise. As developers, it's incumbent upon us to step back, assess the task / team / environment at hand, and pick tools accordingly.

brightball 7y ago
Yep. This is one of the reasons that so many people are excited about Phoenix Live View being released. It bridges that gap much farther and let’s you avoid the SPA until you hit the “is absolutely necessary” point.
goostavos 7y ago
On a side project I recently tried the middle ground approach and absolutely loved it. There was really only one part of the application that had complex user interactions, so that was the only place that I shipped a React bundle. The rest was just plain ol' templates and HTML. On the whole, I'd say that I loved it. It is _staggering_ how quickly you can knock pages out when you're not coordinating data representations across different pieces of your app. The static-ness also lets you embrace a kind of UI feature simplicity. Does that form _really_ need live validation, or can we just pop the errors after submit? The latter is the only option unless you wanna (a) either vanilla Javascript or JQuery the interactions or (b) start shipping a React bundle down to this page. And thus, form validation was part of the request/response cycle, which further speeds up development. It does get a little awkward when a static page starts having dynamic features begin to creep in. You have to decide when to awkwardly cut over to having that page powered by React. That said, without a framework supporting this kind of development directly, I'm skeptical of how well it would work on a team. I did this style on a solo project, so there was no one complaining about 'mixing technologies' or bemoaning 'why don't we just use React everywhere.' I imagine that the first time we rewrote a page in SPA tech because it picked up enough UX to warrant it, people would be up in arms about how much time we've 'wasted' by not doing it in the first place.
giancarlostoro 7y ago
My rule of thumb is if you arent building some social / multimedia type of experience a SPA wont do much for you that you cant get done with HTML and CSS.
applecrazy 7y ago
I've made quite complex web apps with pure CDN-imported (i.e. no Webpack/NPM) Vue as a starting point. They work well, are easier to debug, and get the job done faster. Of course, it's a good idea to take that monolithic JS file and split it up into components for easier future work, but I've found that working like this leads to fewer "tooling hell" headaches.
andrei_says_ 7y ago
AT&T’s website account pages only serve static html. But they are rendered by js and I have to wait looking at a loader after every click. Why is that? Why do so many static websites and blogs use SPA technology for all their pages? It can’t be that it’s just to make me mad (although it works). Are people insane? How does spending 10x the $ and effort for a worse result make sense?
- deleted 7y ago
  [deleted]
jammygit 7y ago
What are the “indications for use” for a SPA?

by candu 7y ago

brightball 7y ago

Yep. This is one of the reasons that so many people are excited about Phoenix Live View being released. It bridges that gap much farther and let’s you avoid the SPA until you hit the “is absolutely necessary” point.

goostavos 7y ago

On a side project I recently tried the middle ground approach and absolutely loved it. There was really only one part of the application that had complex user interactions, so that was the only place that I shipped a React bundle. The rest was just plain ol' templates and HTML. On the whole, I'd say that I loved it. It is _staggering_ how quickly you can knock pages out when you're not coordinating data representations across different pieces of your app. The static-ness also lets you embrace a kind of UI feature simplicity. Does that form _really_ need live validation, or can we just pop the errors after submit? The latter is the only option unless you wanna (a) either vanilla Javascript or JQuery the interactions or (b) start shipping a React bundle down to this page. And thus, form validation was part of the request/response cycle, which further speeds up development. It does get a little awkward when a static page starts having dynamic features begin to creep in. You have to decide when to awkwardly cut over to having that page powered by React. That said, without a framework supporting this kind of development directly, I'm skeptical of how well it would work on a team. I did this style on a solo project, so there was no one complaining about 'mixing technologies' or bemoaning 'why don't we just use React everywhere.' I imagine that the first time we rewrote a page in SPA tech because it picked up enough UX to warrant it, people would be up in arms about how much time we've 'wasted' by not doing it in the first place.

giancarlostoro 7y ago

My rule of thumb is if you arent building some social / multimedia type of experience a SPA wont do much for you that you cant get done with HTML and CSS.

applecrazy 7y ago

I've made quite complex web apps with pure CDN-imported (i.e. no Webpack/NPM) Vue as a starting point. They work well, are easier to debug, and get the job done faster. Of course, it's a good idea to take that monolithic JS file and split it up into components for easier future work, but I've found that working like this leads to fewer "tooling hell" headaches.

andrei_says_ 7y ago

AT&T’s website account pages only serve static html. But they are rendered by js and I have to wait looking at a loader after every click. Why is that? Why do so many static websites and blogs use SPA technology for all their pages? It can’t be that it’s just to make me mad (although it works). Are people insane? How does spending 10x the $ and effort for a worse result make sense?

deleted 7y ago
[deleted]

jammygit 7y ago

What are the “indications for use” for a SPA?