I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6). So why would I ever do an SPA again if it were up to me? I would use https://github.com/jfyne/live which is inspired by Phoenix LiveViews. This is my professional opinion, having many years of experience in both kinds of web apps.
Template based UI programming is like going back to the year 2007. Your views should be reactive. Elm, Flutter, React, Et Cetera understand this. Having a function that takes data and returns a view is much better.
Isn't a template essentially a "function" that takes data and returns a view? I don't have much experience with UI programming but I don't really see the conceptual difference.
No, the template is usually a static file that is read into memory and served over HTTP or locally if it's a JS only site. But before being served, it's being picked at via imperative operations. And if it's really bad, then when a user presses a button it triggers some event that actually statefully changes the view itself.
I don't see template operations as imperative, rather I see them as declarative: you write the HTML and declare lists/placeholders inside the HTML. You also don't generally do much with the data except insert it into HTML; the rest of the backend is responsible for fetching/etc the data.
Yeah, but the function itself doesn't return that view. The framework you're working in essentially composes the view based on the associated code and template. This is fundamentally different from just returning the view itself in the function. These are all declarative approaches, but leaving your view in code is a lot better.
Every template-based framework I've seen has involved a lot of magic, syntax and DSL. That's not to say that JSX isn't a DSL as well but you can return regular React.Elements just as easily. You shouldn't need to remember a unique expression system just to be able to conditionally render. The premise that you're just not doing much with the data except dumping it into HTML is less true the more complex your site becomes. Think of the loads of conditions and evaluations that happen when you go to your Facebook wall or friends list.
It's okay because despite JSX being a DSL you don't have to use it even though everyone does?
Your line of thought is a large part of why I prefer ClojureScript to Javascript for SPAs. With reagent your components just work like the language, with nothing particularly special to remember.
Surprisingly enough, I'm a clojure developer and I really do like the hiccup syntax in Reagent. I haven't had the courage to use it in anything professional yet though.
EDIT: To answer your question, I actually think that JSX is a downside to React. I get that it was needed to convince the web crowd to adopt the library, but we need to stop pretending like we're writing HTML. We're not. The framework will take our JSX and do whatever it wants to it. I wish we just treated the DOM like a compilation target. That's actually what I like about Flutter - it treats the view as a render target and not as a document that you write to. Flutter web actually uses the canvas API to draw actually. And because of this, you can define your View model in a much more sane way (while still being fast). E.g. Flutter's Layouts make much more sense than HTML and flexbox/grid. They managed to separate the layout from elements. https://docs.flutter.dev/development/ui/layout
Amrita for ruby. That was one of my favorite template frameworks. It parsed your HTML document as HTML and used element attributes to mark which elements corresponded to which keys in your data model. Incredibly simple and unreasonably powerful.
These days.. I just an Amrita like engine I've built myself and I just use <template> elements directly in the document. It only takes 40 lines of code to match child elements to data model items and fill in the template. Your browser already has a powerful parser and literal templates built in.. why invent a whole new language just for HTML templates?
I've never been able to fully apprehend the reasoning for JSX.
That is a usual way this is done but not what it means. In fact, HTML recently got a `<template>` tag which is definitely not a separate file or served separately. Vue.js also refers to the HTML-ish portion of a component as "template".
We can debate syntax but a Go or Python based template language is not conceptually any different to JSX based syntax. Both are essentially functions that take some input data and return the data formatted in HTML.
Sure, if you implement a trivial single-task app (one tiny feature of a Calendar app) with an unfriendly UI, you don't need an SPA. That doesn't prove anything.
It doesn't "prove" anything, but it's a data point, and quite a lot more thorough than your dismissive comment. If you want to make a well supported counter-argument, please be my guest. It's easy to criticize, it's harder to make a thoughtful argument.
I kind of have to agree here. There are very few times I've ever worked on a SPA and felt like throwing it all away and using the alternative.
The last time I thought about this, which admittedly was many years ago, the alternatives that I knew about were: server-side frameworks like ASP.NET MVC Razor, PHP, RoR templates, Node.js EJS, Jade (now Pug), and static HTML.
Nowadays, you can create extremely elegant and performant SPAs with tools like Next.js and Remix, so I really couldn't agree less to the OP.
You're being very rude and dismissive. I may well have more SPA experience than you do. Don't make assumptions about people and then use that to dismiss something they say - we're better than that here on HN.
I am indeed (rude). You can have 100 years of experience, it doesn't make you more credible at thinking that engineers who makes choices that are different than yours as incompetent, by deeming them as mistakes. I mean, if a company wants to choose a tech stack, there are so many things to consider for that choice. Your article is just generic ideas about the fact that SPA are mistakes and SSR apps are better. You're not taking into consideration any of each industry's and company's means, priorities, specificities.
In fact, your 100 years of experience are what's hindering your ability to see how useful SPAs are. And you're resorting to that same old narrative of "it was better before". It's also the niche you decided to position yourself in to sell courses and stuff. Which makes your ideas even more suspicious as they can't be unbiased. Like in politics, they'll dogmatically say that their opponents are wrong, just because they have a "market" to preserve.
So yes, I'm rude, as much as you're inconsiderate to the vast complexity of software engineering, just to preserve your niche market.
And as you say in your website: "Hate the complexity of modern front‑end web development? I send out a short email each weekday on how to build a simpler, more resilient web. Join 13k+ others."
"I am indeed (rude). You can have 100 years of experience, it doesn't make you more credible at thinking that engineers who makes choices that are different than yours as incompetent, by deeming them as mistakes. I mean, if a company wants to choose a tech stack, there are so many things to consider for that choice. Your article is just generic ideas about the fact that SPA are mistakes and SSR apps are better. You're not taking into consideration any of each industry's and company's means, priorities, specificities.
In fact, your 100 years of experience are what's hindering your ability to see how useful SPAs are. And you're resorting to that same old narrative of "it was better before". It's also the niche you decided to position yourself in to sell courses and stuff. Which makes your ideas even more suspicious as they can't be unbiased. Like in politics, they'll dogmatically say that their opponents are wrong, just because they have a "market" to preserve.
So yes, I'm rude, as much as you're inconsiderate to the vast complexity of software engineering, just to preserve your niche market.
And as you say in your website: "Hate the complexity of modern front‑end web development? I send out a short email each weekday on how to build a simpler, more resilient web. Join 13k+ others."
"
wow you must be incredibly smart and discerning, being able to confidently make assumptions and judgments about people's lives and background based on one or two HN comments, and then dismiss them as an ignorant and incapable fool.
