The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no small task.
Compare this to server-side rendering where you run some DB queries, generate some HTML based on those results, and send it to the browser to be rendered.
There are some cases where you actually need a rich experience in the browser. In those cases, I would start by seeing if plain old Javascript would work.
In writing this, I definitely feel like a "get off my lawn" guy. But I've just seen too many junior and senior engineers (me included) fall flat on their face trying to use these SPA frameworks.
It's absolutely possible, dare I say easy, to do old school SSR wrong.
You start with an honest to god html file. Your IDE lints it. You are happy, life is easy.
Then you need a second page. So you copy some things over. Then you need a third page, and it becomes apparent that you need a way to share parts of your html pages across multiple files, in a generic way.
And kids, that's the story of how I met your templating system.
ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful.
It's easy to get things wrong in that world, because nothing gets things right.
There's kludges of course, things that generate html entirely programmatically from their own language, or some weird abstraction.
These all suck too. You have to learn new languages, or weird shorthands, or at best new APIs. None of them truly took off either so the tooling is poor.
You know what's a language that already has tons of tooling? JavaScript.
You know what's a robust API for building HTML that you already know, that is already supported by virtually everything? The DOM.
And you know what's a markup language you already know and can intuitively parse without having to learn new things? HTML.
> And kids, that's the story of how I met your templating system.
> ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful.
That's not really true. But fairly incredibly, it seems relatively little attention has been given to the design of HTML templating languages (certainly there are a lot of them, but most seem to have accreted rather than been designed).
Anyway, the least weird templating language that was designed that I am aware of is the TAL[0] syntax, which has as it's main constraint that unrendered templates must still be valid HTML. The original motivation for this was to eliminate the terrible workflow problems of round-tripping templates between a web designer and a (backend) developer, but there turned out to be other benefits, like taking care of linting difficulties. It is also rather deliberately not Turing-complete, as that has proved an 'attractive nuisance' that causes more problems than it solves.
The TAL syntax is most strongly associated with Python frameworks (I would guess that Chameleon[1] is the most popular implementation), but there are implementations for most prominent languages[2].
> You know what's a robust API for building HTML that you already know, that is already supported by virtually everything? The DOM.
How popular is SSR in JS using the DOM directly, rather than a template language of some sort (eg. Handlebars, Jade, Nunjucks)?
Thymeleaf templates are also valid HTML when not rendered. Of course you still have to put some thought into them to make them believable, by e.g. providing placeholders for elements that would be rendered in cycles.
Yeah, I find Thymeleaf to be nice, especially when coupled with Spring. I'm always happy when we decide to use it instead of bloating everything up with a separate Angular application.
If you have some other way of being able to view an unrendered template in a browser and have it display sanely, I'd be very interested to know about it.
> ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful.
Hard disagree.
Lisp family of languages have tree templates that are easy to lint, test and get right. They also scale as well as- or better than React.
Lisp has had 50 years to catch on, and unfortunately, it has not had the uptake a lot of its proponents would like. I think part of this is the different mental model you need to build around programming when you use these family of languages.
To extend your point, I think the linked article suffers from a common trend in web dev editorialism, which is over-generalisation of problems, and reducing the domain into simple binary thinking.
A lot of these arguments talk about the dangers of SPAs, but don't talk to the reason why first class interactivity/reactivity exists on the web. It's because for average users, they want to see feedback to their actions immediately. Articles like this talk to SPAs as if they are unnecessary or overused. I disagree, I think SPAs are mostly appropriate for most SaaS, social media, or business tooling. Sure, the poorly implemented version of an SPA is harder to debug than a poorly implemented template generated site, but that's like comparing the complexity of a car built in 2021 to a car built in 1980. And cars from 2021 sell better than cars from 1980.
A lot of these articles strike me as opinion pieces decrying the direction of modern web development, and seem to point to the past as a more 'gilded age' of internet browsing. But this was back when users sat at a desk, and scrolled pages using a analog mouse, viewing it on a CRT monitor. Users today want to browse on their phones, want to share and upload, to take live videos, to see when their message was sent, delivered and read. We need SPAs and libraries like React just like we need cars that can do lane assist. It's because it's a feature users want, and on the whole, it is much easier to build using React and SPAs.
But in the wild, on end user machines, many times the SPAs perform worse/slower than SSR ¯\_(ツ)_/¯
And users don't actually want SPAs, users don't care how it's implemented. But users want performance and reliability, and want their pages to feel natural and work fully with all the features other sites have. Anecdotally SPAs often load slowly, break subtly standard web features, and often are slow to use.
Not all SPAs, but a significant amount of them.
As someone who's fluent with SSR and SPAs (react/vue), who consults in the enterprise space, I reach for SSR solutions, about 2/3+ of the time as the appropriate architecture. Of course ymmv but you need to be fluent with all the options to be in position to pick the best tool for the job!
> Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible.
Whaaat. Async/await/promises is trivial. JS is still single-threaded so you don't have any of those annoying threading issues.
Where it gets a bit wonky is when you apply it to the UI because you have this extra state you need to worry about. After the user clicks something, but before you get the results back from your server. You have a loading or saving state to deal with. But React mostly makes that trivial too.
SPAs get hard because of all the reasons listed in that blog post. They're incredibly hard to optimize properly.
And for that reason, I don't disagree with your first sentence. If all you're doing is worrying about 1 page at a time and shipping some HTML, you're golden.
Perhaps you've been luckier than I have in your experience with Rails and Django codebases! I have seen a tremendous amount of "not doing it right" and "architecting things in such a way that it makes it nearly impossible to 'do it right' when adding or changing any behavior."
With any of the popular React server-side rendering frameworks, getting up and running with a basic web site with some pages and HTML content is not significantly harder (and in fact not that different at all) than doing the same in Django or Rails.
I have to agree. I'm a OG Rails dev looking and constantly compare the productivity of old school SSR sites compared to current complex SPA frameworks. People how tie themselves in knots, the UI interactions are tricky to get right, more places to code, then second guess the frameworks, then try it again. SSR Rails apps just had 3, maybe 4 places to write code - controllers, models, view folders - you can flip back and forth in blinding pace, and get your app up and running really, really quickly. Yes agree there's some places SPA's are really applicable. But watching an app get built that you see no distinct advantage for either end user or dev team makes you wonder.
In the critical path many things can matter that ordinarily don't. When working on perf improvements for Storm 1.0 release, profiling revealed hotspots in Clojure code. Adding type hints to avoid dynamic typing fixed some of these hotspots. In other places, Clojure primitives showed up as a bottleneck. These required rewriting some code in Java and invoking it from Clojure.
The Clojure based core has served the community well for some time. It was still powered by Disruptor (a fast Java messaging library). So there was always some back and forth between Java and Clojure.
For Storm 2.0, the Java rewrite happened first. The re-architecture work might have not happened without it (at least for the foreseeable near future)... primarily due to Java expertise being more easily available.
While it is true that Java is statically typed and Clojure is dynamically typed it is perhaps one of the less important differences between the two languages. If you in fact would like to add a static type system on top of Clojure there is a way to do that: Typed Clojure.
I'm not going to downvote the comment, but I think the "statically typed" argument is fantastically overrated. I spent years of my life coding in Java and C# and other years of my life writing Clojure, Python, Ruby, and Elixir code. I've never once thought to myself of the latter, "Damn! This would be so much better if I could have static types." It has literally never, not once, ever been an issue for me.
I really don’t see how this keeps coming up as an excuse. East coast corridor is at least as dense and is not far off in purchase power per capita. Plus you could as well compate to China, another huge country with low density of purchase power, and look how they‘re charging ahead in infrastructure. It‘s the political system - not to say that the US should adopt China‘s of course, just that it‘s a better explanation of what goes wrong.
I think the commenter was referring to the fact purchasing power is not dense (ie, dense areas don't have as high a purchasing power)? A little confused by this too.
I like looking at purchase power in general, rather than GDP - the absolute numbers don't matter so much as long as your domestic market is large enough to produce most things people need.
Secondly, the density of savings and taxes per square kilometer is giving you an idea about how much potential for development a current settlement has. That's the capital that can be drawn from directly. Density of spendings (train tickets, consumer goods etc.) is the driver for outside capital to come in trying to get a dividend. Taken all together (savings + spendings) you get the density of PPP adjusted GDP per square kilometer as a figure that matters. As you can see in [1], US and China is actually quite similar in this metric, and it's probably also still similar if you just take its coastal regions. I also think that this metric is very similar for the population belt between London and Rome, and the East Coast corridor in the US.
Switzerland has a population density of 206 per km^2. NJ, RI, MA, CT, and MD have higher density. After all, nobody's expecting an express rail across Montana anytime soon: we're talking about the more populous part of the US.
It's hard to use "they are different" argument when your country is objectively worse than Switzerland and China.
Effective density in Switzerland is much higher, because that headline number aggregates a bunch of dense towns and cities (mostly located in valleys) with a whole lot of steep mountainsides with an approximate density of ~0.
It also helps that the topography forces development into mostly linear shapes (following the valleys), rather than radiating in all directions as normally happens in flatter terrain. Linear corridors are much easier to serve via public transit, because everything is "on the way".
Well, I'm sure having a linear string of cities helps, but effective density is higher everywhere: Switzerland is the norm instead of the outlier.
E.g., San Mateo and Santa Clara counties, at the center of Silicon Valley, have population density of 663 and 580 per km^2. And of course San Francisco has a whopping 7249 per km^2. They also have a string of connected cities, thanks to being constrained by the pacific and the SF bay from either side.
I don't think I have to repeat on HN what the infrastructure looks like in the Silicon Valley.
* Besides, your argument can be paraphrased as "Of course it's easier in Switzerland, because it's filled with mountains!" Think about it.
Yeah I feel like comparisons to Europe often fall flat for this reason. There are plenty of small, wealthy enclaves in the U.S. where the infrastructure is perfectly fine, but the U.S. is so big that telling someone in say, Bellevue, WA that the infrastructure in the Midwest is crumbling is the same as telling someone in Zurich that the infrastructure in Bulgaria or Turkey is crumbling.
Obviously that analogy is far from perfect, as Seattle has its own set of infrastructure problems, but extrapolating from most European countries doesn't seem particularly useful.
> There are plenty of small, wealthy enclaves in the U.S. where the infrastructure is perfectly fine
Is it though? I would assume NYC falls in that category and the subway is crumbling. The cars are old, and some of its subway stations have not only not been remodeled in years, they haven't been painted or cleaned recently either [1].
Manhattan is an incredibly rich and dense area, I'd say in theory the city is just as, or better setup for success in terms of public transport than Tokyio, Paris, or Mexico City. Yet, public transport in these cities seems to overall be of better quality than New York's.
Reading a bit into it, it seems clear that it's a matter of corruption, inefficiency and lack of will to fix things [2], not just "the way things have to be" due to external forces.
Public transit is in better shape even in poor republics of the USSR. I rode public transit in Kazakhstan and Uzbekistan and both were better than the NYC public transit. I am not even talking about CTA and SEPTA.
I completely agree that it’s not an inevitable state of affairs.
And I don’t think your point about Manhattan necessarily refutes my point. Just because a place is wealthy doesn’t mean it will have great infrastructure, but there are wealthy places in the US with good infrastrcture.
I also don’t dispute that it’s not a priority in most of the U.S. I just take issue with the idea that it’s easy to figure out what to do and we just need to look at a place like Zurich.
The U.S. is huge. It’s certainly more homogenous than Europe, but it’s big enough and variable enough that a lot of people deign to call the middle 2,000! miles fly-over country. Zurich and Istanbul are only like 1,400 miles apart, and are such drastically different places, but people expect the whole U.S. to have it’s infrastructure together when 1,500 miles gets you just halfway across the U.S.
>but there are wealthy places in the US with good infrastrcture
You're going to have to tell me what those are, because I've been all over the US and I have absolutely no idea what places these might be. All the wealthy places I've seen in the US either have crumbling infrastructure (northeast), terrible public transit, or no real public transit at all and expect everyone to get around in cars (e.g., suburban DC area).
>but people expect the whole U.S. to have it’s infrastructure together when 1,500 miles gets you just halfway across the U.S.
No, people expect the US's major metro areas to have their infrastructure together (i.e., subways), and they just don't.
And our insanely expensive higher education system. And the total absence of civil protections against surveillance-based capitalism. And the lack of oversight on speculator-driven excess in the mortgage industry and stock markets.
I used this technique in my previous startup. I even had shell scripts that generated my LESS files.
One of the driving philosophies was that when one saw a CSS class, they should easily be able to find it's definition in the source. Another driving philosophy was that one should easily be able to determine what the class is doing.
This lead to classes like `u-centered`. The `u` tells me it's in the utils.less file. Classes starting with `l-` were layout classes, `t-` text classes, etc..
I had classes like this:
u-{max,min}-width-{xxs,xs,s,m,l,xl,xxl}
t-white
u-bg-red (red background)
t-h3
l-container-{xxs,xs,s,m,l,xl,xxl}
You get the picture.
(The nice thing about xl and xs is that you can keep adding x's as you need.)
I found it to be very effective. I understand the arguments that it kind of defeats the purpose of CSS, but I think CSS is pretty easy to mess up, and this give you a solid, consistent structure to work with.
Of course, I didn't follow this style 100%. There were some cases where it just made sense to use a more semantic style, but I found those case to be few and far between.
Seems like a waste of time when you can just do style="background: red;". You're not adding anything to CSS you're just renaming and enumerating all the style attributes and values.
I think it makes sense in small doses but I think once you're using shell scripts to generate all these combinations you've lost the plot.
There's a big difference between class="u-bg-red" and style="background: red;". The big difference being that the class make it so that it is first-class application idea.
And I think that may be one of the larger points here. CSS can be simple, and using techniques like this forces it to stay that way. You have to take a step back and understand what we're trying to do as engineers. I would argue that being able to quickly understand code (e.g. the context to understand a line of code is small) should be a top priority of most software project.
"u-bg-red" vs. "backround:red" is just the same thing aliased. If you were to introduce an actual concept like "warning" or "error" that was red that would be different.
You are correct from one point of view. But, the point I was making was that the class definitions for bg color can be contained within a single file in your application. Using `style` is completely different in that anything is possible. This is a big deal, as cutting down on possibilities/simplifying is a very important process in software engineering.
> But, the point I was making was that the class definitions for bg color can be contained within a single file in your application.
But that doesn't matter because it's not an abstraction. If you have 10 HTML files and 1 CSS file, you can make a class called "warning" and have it be a background color red you've simplified those HTML files because you have less style information in the HTML.
But if you are using classes like "bg-red" or "pt-10" then you're not actually reducing the style content of your 10 HTML files. You've just renamed a style to a class. Sure you've reduced some possibilities but you've actually made the situation worse because now you have 11 files with style information. You've added new names for basic styles which adds even more complexity.
If you take that idea of reducing style possibilities to the logic extreme then you wouldn't be using classes like "bg-red" and "pt-10" anyway. You'd just do what everyone already does with CSS and abstract your styles appropriately.
I don't have a problem with future-proofing. I do have a problem with half-solutions (which is mainly what I see in the industry). E.g. if you need to run some code before or after a transaction, make a generic way to make this happen.
The problem is that devs do not create enough leverage in their solutions, so they're never that useful in the future. And, devs tend to over estimate what is actually re-usable. The second point may be the most important. Too often, I see solutions that are half-way reusable, which means they're not re-usable at all.
In the end, building out a solid foundation is key. The problem is, this is pretty hard and takes a lot of experience to know how to do well.
