Maybe your prediction is informed by different internet usage scenarios but for general mainstream web surfers, I can't see how the industry will migrate back to server-side rendering in 3 years.

The unavoidable technical issue is the round-trip latency of the network. The same delays from the speed-of-light will still be there in 3 years. Most of the world is accessing the web through mobile phones which has worse latency than desktops. Server-side rendering (which means painful page reloads) is user hostile on slow network connections.

I’ve found many sites that use frameworks like react to be much more user hostile, particularly from a performance and accessibility standpoint. The reddit redesign comes to mind. It’s so much slower now than it used to be on a browser (perhaps they’re intentionally doing this to push people to their mobile app), that it’s noticeably reduced the quality of the experience.

I guess I just don’t understand how people see page reloads with proper caching as unacceptable from a performance standpoint compared some JavaScript app maintaining a virtual DOM, which is also likely regularly communicating with a server.

How easier? By dint of additional JS that an SSR doesn't have/need? Not sure how pulling a header nav (or any cell/element) from a server on pageload plays into that, but even today I've watched sites (plural) loading, pushing loaded parts all over the page for 30sec until everything settles down. Maybe blogs aren't quite so affected by this set of popular dark- and anti-patterns, but even so the post is almost always the last thing to load. Presumably, the monetization and data collection takes precedence over all else.

So is downloading an entire app when you only want to read one page.

Svelte also extremely promising. It brings a brilliant hybrid solution to the table.

  [:div {:style {:display "flex", :flex-direction "row"}}
   [:label {:for "email"}]
   [:input {:type "text"}]]

Perhaps it might look better if there's a bigger example?

The point of this is not of asthetics, (IMO it’s not that ugly :-)) but more that it just consists of common data structures that is easy to manipulate. If you’re a React person, think of directly writing JSON instead of using indirect React.createElement calls. Writing components in JSON would be impractical; (actually it might not be - I think I’ve seen blogposts using React without JSX) but writing components in cljs data structures are practical and less tooling is needed!

    <div style="display: flex; flex-direction: row">
        <label for="email"/>
        <input type="text"/>
    </div>

edit Oh I see. You don't need the extra {} to jump into JS mode. And, CLJS requires : to denote keys. I think as long as my editor colors the syntax appropriately I'm okay with either.

Compare to alternatives like Om, where the code looks like, well, code. Except in reality it's just Lisp sequences instead of Lisp vectors, so you still get all the same abilities to treat code like data. I don't think I'll ever willingly go back to JS. Maybe Purescript once of these days, but never JS.

Additionally, re-frame is absolutely wonderful and I cannot believe I waited as long as I did to switch to CLJS considering how much I prefer re-frame (and reagent) it over Redux (and React). Writing JS for immutability feels like such a chore now (Immer helps), since that part already just works in Clojure.

But I think it is wise to consider that there are advantages and trade-offs to a compiled template approach as used by Angular, Svelte, and probably some others I’m forgetting.

* potentially more concise syntax

* potentially more familiar syntax

* do more of the work at compile time, less of it at runtime in downloaded code

* avoid the GC pressure and other overhead of VDOM

JSX is just javascript. It's HTML looking, but is ALL (not some) a wrapper to write a JS function that outputs HTML. Need to have a loop? Loop in JS. Need to have a conditional? Condition in JS. What scope? This is all a JS function, so the scope rules are all JS scope rules.

I have no idea if I'm a weird minority, or if I'm just running into more people that felt better with Vue than React, but I really don't understand why.

If you look at the job market around here, it’s 70% react and 30% angular with almost no Vue jobs right now. The ones listing Vue as a requirement almost all use React, who are willing to retrain Vue developers. It used to be more evenly distributed between angular and react, but it would seem that react won the front end war.

This is HN though, it’s not very representative of what goes on outside of Silicon Valley. Right now there isn’t a single Rust job in my country as an example, at least not in any of our major jobbanks. There are thousands of PHP jobs though. But if you took HN to be representative for languages, you’d think it was the opposite.

Apparently they aren't that bad after all.

JSX is the one mixing echo like statements with proper JavaScript.

I've been trying trying this out [1] with a thin 300-line DOM wrapper, and works wonderfully well so far.

There are also libraries like lit-html but I prefer to construct html as an object tree, and not a string.

1: https://github.com/bwindels/brawl-chat/blob/master/src/ui/we...

Serving the same static, "prerendered" HTML file with no customization to every user is always going to be the fastest method of getting something to display in the user's browser, so perceptually it's much faster to serve a static html file and then hydrate it with any custom data using frontend JS.

Just seeing the skeleton of the web page doesn't make it fast. The page will be unresponsive for longer and will visually stutter while rendering. It's a much worse user experience imo.

I didn't say it does. Skeleton loading is slower. It feels faster though, and that perceptive improvement is more important than the actual time something takes. If you ask users which they think is faster they usually say the skeleton version regardless of the facts. When your key metric is user satisfaction rather than raw download speed that's important.

The page will be unresponsive for longer and will visually stutter while rendering.

That doesn't have to be the case though. There are plenty of techniques for writing client side code that doesn't block user interaction.

I don't want to program iOS and Android and web.

Plenty of gigs available.