Hacker News Reader

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.

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.

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.

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.

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.

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?

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

Currently dealing with a situation where a SPA app doesn't work with FB Sharing, because it exepects a set of META/Open Graph tags. So now we are going back to rendering a portion of the HTML on the server to support this.

In JIRA, if I hit enter in the wrong field, it does a post out to somewhere and returns me a weird xml page and I lose my work.

SPA apps are like building a browser, in a browser, and on the server. You lose some built in functionality and have to ship the framework down to the client.

JIRA is a case study in bad UI/UX and web anti-patterns, IMHO. I think my team at work is finally ready to ditch it in favor of basically anything else.

What else?

We're evaluating Basecamp, Asana, Codegiant, and Nuvro.

One of the managers at work swears that JIRA is the next great thing to happen to us. From all the negatives I have heard I get the feeling that the request to adopt it getting stuck somewhere in our parent company is a good thing.

In Jira, I constantly have a fear that I will update wrong thing. Every single click make something editable and the page jump around.

The worst I've seen is where the main content is served (if you curl the website, you can see the text content is there), but it's hidden by a full-page loading animation which is removed by JS.

AMP? (https://amp.dev/documentation/guides-and-tutorials/learn/spe...)

The saving grace in these cases is that often the reader mode would work with the HTML just fine and you don’t need to wait for the useless 3MB JS bundle which you may have blocked. The same reader mode trick sometimes works against subscribe-to-read-the-rest-of-the-article paywalls and no-scroll anti-adblock modals, too.

Of course I agree that if you’re only showing text with a few interactive enhancements, you can probably get away with jquery. The trouble is that too often a few enhancements turns into a few more enhancements, then a lot of enhancements, and then you end up with a huge mess of jquery spaghetti. It quickly becomes comical to claim that jquery would result in fewer bugs than pretty much any post-backbone UI library or framework you can think of.

I don't use jQuery much these days, but you can absolutely write quality jQuery code that is well structured and architected. It doesn't need to devolve into spaghetti code. It doesn't have guard rails like some frameworks might, and it's base examples don't really promote non-spaghetti code, but it's not that difficult for experienced JS devs to write good, high-quality jQuery code.

This is some special kind of madness and I wonder when it will stop.

There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks.

The improvement here is that since there's no special runtime the bundles are very small, so there isn't a lot of JS to parse.

Also the code you have to write is much shorter comparing to frameworks.

> There's light at the end of this tunnel in the form of compilers like Svelte or Stencil.js replacing frameworks.

I am a bit skeptical that adding more complexity to something that's already much more complex than it should can be a solution.

That's a healthy response to anything new in the front-end community.

Nevertheless I encourage you to check out this presentation:

https://youtu.be/AdNJ3fydeao

Which explains the idea much better than I ever could.

Two things had me sold on this:

1. They managed to make the thing so easy to use, that even people who's line of work involves mostly Excel sheets were able to create something useful after a short introduction.

2. The output is relatively readable JS. There are some surprises like a few one-letter method names, but overall you could open up the source of a running Svelte app(provided it weren't minified) and figure out what it's doing just by reading the code.

What are you saying that Svelte or Stencil are adding to? They are both complete toolchains.

I've seen the flip side of the coin in an app I inherited at work - it turns out server-side rendering can be significantly slower than client side rendering if you're rendering a lot of content, to the point where we hit an automatic timeout. If this app was a fat JS app, we probably wouldn't be trying to decommission it & it probably would load in seconds at worst, but the investment to modernize it/improve performance & scalability so it would meet our users' needs is too much.

That’s true in a lot of cases mainly because of the approach to rendering. So many languages focus on rendering the entire HTML structure before sending the first byte back, specifically so that the page can be wrapped in a cache. This forces a lot of memory allocation to build up strings and parts of strings that takes time on its own, is often repetitive over the same HTML tags and then all of that has to be garbage collected at the end of the request.

The approach taken by Elixir’s Phoenix framework is so fast because it avoids all of those pitfalls. Most people have to do a double take when they see the speed comparisons.

Here’s a great write up: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2...

Your older app may be serializing a lot of work. For instance, it could be issuing 10 SQL queries, one after another, which take 200ms each to answer - that's 2s total just waiting for the database. Compare to a JS client which issues 10 backend API calls, each being a 200ms request from the server's perspective (and the JS may parallelize many of those requests)

If this is a factor, rearchitecting the backend wouldn't necessarily be easier than an SPA rewrite. But it's not a fundamental limitation of server-side rendering.

If all the cool kids are doing a thing, you have to do that thing else you’re not a cool kid.

There’s no other explanation.

Elixir/Phoenix’s new LiveView seems to really hit this sweet spot

Why stop now when we got so much out of it? Maybe we will have even better solutions coming now that we have learnt so much.

It's like "Please stop enhancing stuff it's good enough" - I like to enhance stuff, yeah it has costs but you can master them. That's definitely not the end of it. I hope we will do better. Maybe your "problems" will be resolved as well!

Server-side rendering is the best front-end architecture at the moment. Superior first content paint and is better at SEO than SPA, and have a better architect than MVC.

So in what way does if differ from traditional MVC? In MVC, the final output is HTML strings. Easy example: supposed you have an array of Posts in your controller, and a HTML template. The final result will be the combination of both of them. But when the HTML strings get sent to browser, you lose the array !!! It's gone. The client never receives an actual array, just DOM nodes.

In Front-end framework SSR (NextJS or NuxtJS), what you work with is a component. A component can have data (an array), and the data is pushed (serialize) as-is to browsers. On the browser, you won't ever have to work with low level DOM nodes. You continue to see the component and data in its original form. This is the biggest win of SSR that is easily overlooked.

If you need that array you could just embed a script tag in your html template.