You should still know a language like Rust or Zig for systems work, and if you want to work in ML or data management you probably can't escape Python, but Typescript with Bun provides a really compelling development experience for most stuff outside that.
As fun side anecdote, if you're doing scientific computing in a variety of fields, Fortran 95 is mostly still fine ;)
I’ve seen undefined make it all the way to the backend and get persisted in the DB. As a string.
JS as a language just isn’t robust enough and it requires a level of defensive programming that’s inconvenient at best and a productivity sink at worst. Much like C++, it’s doable, but things are bound to slip through the cracks. I would actually say overall C++ is much more reasonable.
This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts.
JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement.
You've "seen null make it to the database," but haven't seen the exact same thing in C++? Worse, seen a corrupted heap?
It's like people just talk in memes or something.
This is how a lot of discourse feels these days. People living in very different realities.
Though in this case, seeing the most complex C++ app they've built would illuminate what's going on in theirs.
Opening up a 10K lines JS file is like jumping into the ocean. Nothing is obvious, nothing makes sense. You're allowed to just do whatever the fuck in JS. Bugs where always ephemeral. The behavior of the code was impossible to wrap your head around, and it seemed to change under your feet when you weren't looking.
Now, the backend was written in old C++. And yes, it was easier to understand. At least, I could click and go to definition. At least, I could see what was going in and out of functions. At least, I could read a function and have a decent understanding of what it should be doing, what the author's intention is.
The front end, spread across a good thousand JS files, was nothing of the sort. And it was certainly more buggy. Although, I will concede, bugs in C++ are usually more problematic. In JS usually it would just result in UI jankyness. But not always.
I think that’s a feature not a bug.
But then again, I generally like and use Typescript.
The problem is that the behavior becomes so complex and so much is pushed to runtime that there's no way to know what the code is actually doing. There's paths that are only going to be executed once a year, but you don't know which ones those are. Eventually, editing the code becomes very risky.
At this particular codebase, it was not uncommon to see 3, 4 or 5 functions that do more or less the same thing. Why? Because nobody dared change the behavior of a function, even if it's buggy. Maybe those bugs are the only thing keeping other bugs from cropping up. It's like wack-a-mole. You fix something, and then the downstream effects are completely unpredictable.
It becomes a self-eating snake. Because the codebase is so poor, it ends up growing faster and faster as developers become more risk-averse.
It's clear you've worked on a really bad codebase, but this is totally different from what you were originally suggesting, which was null being a bigger problem in JS than C++.
What you're describing is frontend development with JQuery, not the capabilities of JS. Now, I don't like NextJS for a lot of reasons, but code organization is not one of them. Everything you're complaining about is dead simple in NextJS. Functions are localized, tracking localized state is easy, and even the older React state libraries have lots of support for tracking and visualizing the more global state changes.
I will die on the hill that JQuery, outside of very small interactivity, is fucking bad. People use JQuery terribly and it creates spaghetti code where you can't tell what the execution path is. People don't document QA testing. And JQuery makes you target html attributes to make changes. That's fun if you have to do it once, it's terrible if all of your app interactivity relies on it.
But that's not due to "undefined", and it would be 100x worse in C++. I am assuming the C++ codebase you compared it to was not a DOM manipulating app?
I don't like NextJS for performance and market reasons, but the codebases I've worked on have been very clean.
The horrors I’ve seen. Constructing a custom string based off of user input and then tacking on () and calling it as a function? We can do that? Apparently yes we can. The most cursed type of polymorphism where nothing makes sense and you’d have more success communing with the dead than deducing the control flow.
In C++, there's only one null, nullptr. But most types can never be null. This is actually one area where C++ was ahead of the competition. C# and Java are just now undoing their "everything is nullable" mistakes. JS has that same mistake, but twice.
It's not about complexity, although that matters too. C++ is certainly more complex, I agree, but that doesn't make it a more footgunny language. It's far too easy to make mistakes in JS and propagate them out. It's slightly harder to make mistakes in C++, if you can believe it. From my experience.
> And here you demonstrate one of many problems - there's multiple null types
In JS, null and undefined are not meaningfully different unless you're checking for exactly one or the other. And there's little reason to do that. It has never come up for me that undefined made it through where null wouldn't have. But yes, you need to check if things are defined.
> In C++, there's only one null, nullptr. But most types can never be null
C++ absolutely has undefined, it just doesn't tell you about it. If I make a var with `int myVar;` it's undefined. There's no telling what it points to. But C++ will treat it as `int`. And it can be a lot worse. Vars can be memory represented as the wrong type. They can be truncated memory, dangling pointers, memory freed twice.
But with JS, if I access memory that wasn't explicitly set, it says "that's undefined." That's a good and explicit thing to tell me, and I can actually check for it. And the GC, obviously, avoids a whole class of cases where undefined would come up.
> This is actually one area where C++ was ahead of the competition
For the reasons above, I would say C++ is literally the worst option for null safety. Unless we define safety as "don't tell me this is undefined, even though it is."
> It's far too easy to make mistakes in JS and propagate them out
I'm just not sure why. I would say C++ has absolutely every footgun JS has and more.
Make std::string null. You can’t. Make std::vector null. You can’t. It’s one of the benefits of a value types.
That, alone, eliminates a whole class of bugs that’s JS has. Yes, there’s edge cases in C++ too. The edge cases are the common cases in JS in this regard and that’s why I class them differently. Really, every language can do everything, basically. But how easy is it, and how common is it?
Also, for the record, using an initialized variable will result in a warning or compilation error.
None of this is to say that C++ does not have other glaring problems that JS does not. But, in my experience, it’s slightly more difficult to create logic bugs in C++. I also have worked with PHP - similar situation to JS. Too footgunny that in practice the codebase is riddled with bugs that rarely manifest, but are there. Everything you do has, like, a dozen implications and edge cases you need to consider.
I greatly prefer Java with Spring Boot for larger backend projects.
To answer your question directly - yes, it’s fine, it’s actually expected behavior.
Which is what HN does and it sucks. It's very common for me to vote on a couple things and then after navigating around I come back to see that there are comments that don't have a vote assigned.
Of course the non-JS version would be even more annoying. I would never click those vote buttons if every vote caused a full page refresh.
The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.
I agree with this. Sprinkle in the JS as and when it is needed.
> The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.
I don't agree with this: SPAs don't force "... having to maintain a JS-driven system on every single page..."
SPA frameworks do.
I think it's possible to do reasonably simple SPAs without a written-completely-in-JSX-with-Typescript-and-a-5-step-build-process-that-won't-work-without-25-npm-dependencies.
I'm currently trying out a front-end mechanism to go with my high-velocity back-end mechanism. I think I've got a good story sorted out, but it's early days and while I have used my exploratory prototype in production, I've only recently iterated it into a tiny and neat process that has no build-step, no npm, and no JS requirement for the page author. All it uses is `<script src=...>` in the `<head>`, with no more JS on the rest of the page.
Very limited though, but it's still early days.
That's kinda the goal I'm trying to reach. If you know of any SPA that doesn't come with all the baggage and only uses `<script src=...>`, by all means let me know.
We can sit here all day and think up counterexamples, but in the real world what you're doing 99% of the time is:
1. Presenting a form, custom or static.
2. Filling out that form.
3. Loading a new page based off that form.
When I open my bank app or website, this is 100% of the experience. When I open my insurance company website, this is 100% of the experience. Hell, when I open apartments.com, this is like 98% of the experience. The 2% is that 3D view thingy they let you do.
Notification count in the top right?
Remaining credit on an interactive service (like the ChatGPT web interface)?
So, maybe two(!) business use-cases out of thousands, but it's a pretty critical two use-cases.
I agree with you though - do all normal HTML form submissions, and for those two use-cases use `setInterval` to set them from a `fetch` every $X minutes (where you choose the value for $X).
There's an entire domain of apps where you truly need a front-end. Any desktop-like application. Like Google Sheets, or Figma. Where the user feedback loop is incredibly tight for most operations.
Every form also normally ends up duplicating validation logic both in JS for client-side pre-submit UX and server-side with whatever errors it returns for the JS to then also need to support and show to the user.
Anecdotally, it seems like I encounter a lot more web apps these days where refreshing doesn’t reset the state, so it’s just broken unless I dig into dev tools and start clearing out additional browser state, or removing params from the URL.
Knock it off with all the damn state! Did we forget the most important lesson of functional programming; that state is the root of all evil?
There are times the user experience is just objectively better with more state, and you have to weigh the costs.
If I am filling out a very long form (or even multi-page form) I don’t really want all that state lost if I accidentally refresh the page.
Most companies aren’t international.
For applications that are not highly interactive, you don't quite need a lot of tooling on the BE, and since need to have a BE anyway, a lot of standard tooling is already in there.
React style SPAs are useful in some cases, but most apps can live with HTMX style "SPA"s
“So the backend gave this weird …”
“What backend?”
“The backend for the frontend…”
“So not the backend for the backend for the frontend?”
I jest, but only very slightly.
I'm arguing to just use a single API, not creating one for UI, at least when you want things to be simple for multiple clients.
I think the DX is significantly better as well with fast reload…
It just depends on what you are after. You can completely drop the backend, apis, and have a real time web socketed sync layer that goes direct to the database. There is a row based permissions layer still here for security but you get the idea.
The client experience is important in our app and a backend just slows us down we have found.
That's never the case.
you might be able to drop a web router but pretending this is "completely drop[ping] the backend" is silly. Something is going to have to manage connections to the DB and you're not -- I seriously hope -- literally going to expose your DB socket to the wider Internet. Presumably you will have load balancing, DB replicas, and that sort of thing, as your scale increases.
This is setting aside just how complex managing a DB is. "completely drop the backend" except the most complicated part of it, sure. Minor details.
Which is fine and cool for an app, but if you do something like this for say, a form for a doctor's office, I wish bad things upon you.
Your typical SPA has loads of pointless roundtrips. SSR has no excess roundtrips by definition, but there's probably ways to build a 'SPA' experience that avoids these too. (E.g. the "HTML swap" approach others mentioned ITT tends to work quite well for that.)
The high compute overhead of typical 'vDOM diffing' approaches is also an issue of course, but at least you can pick something like Svelte/Solid JS to do away with that.
Yes, I know that this can be made to work properly, in principle. The problem is that it requires effort that most web devs are apparently unwilling to spend. So in practice things are just broken.
My hypothesis is that they’ve had to deal with so many random web apps breaking the back button so that behaviour is no longer intuitive for them. So I don’t push back against in-app back buttons any more.
I myself am guilty of (about 14 years ago now) giving an SPA a "reload" button, which had it go and fetch clean copies of the current view from the server. It was a social app; new comments and likes would automatically load in for the posts already visible, but NEW posts would NOT be loaded in, as they would cause too much content shift if they were to load in automatically.
Admittedly this is not a great solution, and looking back on it now, I can think of like 10 different better ways to solve that issue… but perhaps some users of that site are seeing my comment here, so yeah, guilt admitted haha.
/)
An auction site I use loads in the list of auctions after the rest of the page loads in, and also doesn't let you open links with middle click or right click>new tab, because the anchor elements don't have href attributes. So that site is a double-dose of having to open auctions in the same tab, then going back to the list page and losing my place in the list of auctions due to the late load-in and failure to save my scroll location.
This is an implementation choice/issue, not an SPA characteristic.
> there's probably ways to build a 'SPA' experience that avoids these too
PWAs/service workers with properly configured caching strategies can offer a better experience than SSR (again, when implemented properly).
> The high compute overhead...
I prefer to do state management/reconciliation on the client whenever it makes sense. It makes apps cheaper to host and can provide a better UX, especially on mobile.
Just how low-spec and/or how much state-data are we talking about here? I ask only because I am downloading an entire dataset and doing all the logic on the client, and my PC is ancient.
I'm on a computer from 2011 (i7 870 @ 2.9GHz with 16MB of RAM), and the client-side filtering I do, even on a few dozens of thousand of records retrieved from the server, still takes under a second.
On my private app, my prospect list containing maybe 4k records, each pretty substantial (as they include history of engagements/interactions with that client) is faster to sort and filter on the client than it is to download the entire list.
I am usually waiting for 10s while the hefty dataset downloads, but the sorting and filtering happens in under a second. I do not consider that a poor UX.
How do you know how large the dataset is? All you know from my post is that a dataset that takes 10s to download (I'm indicating the size of it here!) takes under a second to filter and sort.
My point is that if your client-code is taking long to filter and sort, then your dataset is already so large that the user has been waiting a long time for it already; they already know that this dataset takes time.
FWIW, the data is coming in as CSV, compressed, so it's as small as possible. It's not limited by the server. Having it rendered by the server will increase the payload substantially.
I can't really speak for those sites anyway, or why they are so slow doing things on the client, but like I said, I've written client-side processing and used my 2011 desktop, and there has been no pegging of the CPU or large latencies when filtering/sorting data client-side.
> while absolutely massively complex and large server-rendered HTML loads and renders in an eyeblink.
I've not had that experience - a full page refresh with about 10MB of data does not happen in an eyeblink. It takes about 6 seconds. There's a minimum amount of time for that data to download, regardless of whether it is pre-rendered into `<table>` elements or whether it is sent as JSON. Turning that JSON into a `<table>` on the client takes about 40ms on my 2011 desktop. Sorting it again takes about 5ms.
For this use-case (fairly large amounts of data), doing a full-page refresh each time the user sets a new sort criteria is unarguably a poorer experience than a bit of JS that goes through the table element and re-orders the `<tr>` elements.
In this case, using server-rendered HTML is always going to be 6000ms whenever the user re-sorts the table. Using a client JS function takes 5ms. On a machine purchased in 2011.
Okay, lets assume it is faster by whatever the latency is for a network request.
What sort of use-case are we talking about where a table is displayed on a content or e-commerce side and the user is not allowed to re-sort it?
It's all about the user's experience, not the developer's, and I can't see how a UX that prevents sorting is a better UX. Ditto for a sortable table that refreshes the page each time the user sorts it.
1. Fetch index.html 2. Fetch js, css and other assets 3. Load personalized data (json)
But usually step 1 and 2 are served from a cdn, so very fast. On subsequent requests, 1 and 2 are usually served from the browser cache, so extremely fast.
SSR is usually not faster. Most often slower. You can check yourself in your browser dev tools (network tab):
vs.
Poster child SSR: https://nextjs.org/
So much complexity and effort in the nextjs app, but so much slower.
That's not really SSR though, it's partial SSR but then hydrated into a client-side React app, so a SPA. If you really want to compare try an htmx page.
SSR also has excess round trips by nature. Without Javascript, posting a form or clicking a like button refreshes the whole page even though a single <span> changed from a "12 likes" to "13 likes".
Please forgive the self-promotion but this was exactly the premise of a conference talk I gave ~18 months ago at performance.now() in Amsterdam: https://www.youtube.com/watch?v=f5felHJiACE
Yes, that one. I want that experience please.
I built a lib specifically designed for this strat: https://starfx.bower.sh/learn#data-strategy-preload-then-ref...
If you are curious, my most recent blog post is all about this concept[0] which I wrote because people seem to be misinformed on what RSCs really are. But that post didn't gain any traction here on HN.
Is it more complex? Sure–but it is also more powerful & flexible. It's just a new paradigm, so people are put off by it.
[0] Server Components Give You Optionality https://saewitz.com/server-components-give-you-optionality
Maybe the answer was never in JS eating the entire frontend, and changing the tooling won’t make it better, as it’s always skirting what’s actually good for the web.
I used to agree but these days with Vite things are a lot smoother. To the point that I wouldn't want to work on UI without fine-grained hot reloads.
Even with auto reload in PHP, .NET, etc you will be wasting so much time. Especially if you're working on something that requires interaction with the page that you will be repeating over and over again.
That’s honestly not that many things IRL. If you look at all the things you build only a minority actual demand high interactivity, or highly custom JS. Otherwise existing UI libraries cover the bulk of what people actually need to do on the internet (ie, not just whatever overly fancy original idea the designers think is needed for your special product idea).
It’s mostly just dropdowns and text and tables etc.
Once you try moving away from all of that and questioning if you need it at every step you’ll realize you really don’t.
It should be server driven web by default with a splattering of high functionality islands of JS. That’s what rails figured out after changing the frontend back and forth.
> Even with auto reload in PHP, .NET, etc you will be wasting so much time
Rails has a library that will refresh the page when files change without a full reload, using Turbo/Hotwire. Not quite HMR but it’s not massively different if your page isn’t a giant pile of JS, and loads quickly already.
What if you have a modal opened with some state?
Or a form filled with data?
Or some multi-selection in a list of items that triggers a menu of actions on those items?
Etc.
And it's true Vite can't always do HMR but it's still better than the alternative.
Stimulus controllers can store state.
> Or a form filled with data?
Again, you can either use a Stimulus controller, or you can just render the data into the form response, depending on the situation.
> Or some multi-selection in a list of items that triggers a menu of actions on those items?
So, submenus? Again, you can either do it in a Stimulus controller (you can even trivially do things like provide a new submenu on the fly via Turbo), or you can pre-render the entire menu tree server-side and update just the portion that changes.
None of these are complex examples.
Yes, obviously, but do these maintain state after hot reload?
If you change the JS or the controller itself, obviously, state stored in JS would be lost unless you persisted it locally somehow.
Didn't everybody say the exact same thing about Node, React, jQuery...? There is always a new and shiny frontend JS solution that will make the web dev of old obsolete and everyone loves it because it's new and shiny, and then a fresh crop of devs graduates school, the new shiny solution is now old and boring, and like a developer with untreated ADHD, they set out to fix the situation with a new frontend framework, still written in JavaScript, that will solve it once and for all.
I still build websites now the same as I did when I graduated in 2013. PHP, SQL, and native, boring JavaScript where required. My web apps are snappy and responsive, no loading bars or never-ending-spinning emblems in sight. shrug
I'm quite surprised to hear this is a common thing. Besides myself, I don't know a single person who has ever installed a PWA. For people in tech, despite knowing they exist. For people outside tech, they don't know they exist in the first place.
Does management actually have any PWAs installed themselves?
It definitely makes complete sense in that scenario, but remains a very niche usecase where people have no other option.
>People outside tech just get installation instructions
People outside of tech don't need instructions to install non-PWA, store apps. So all this does to me is reinforce that no one is installing PWAs outside of niche scenarios where 1. people basically have to use the app due to a connection to a physical institution 2. they are explicitly told how to do it 3. the app is not available on the stores for legal reasons.
Depends on age and tech awareness. Many still do, when they cannot rely on a family member to do it for them. Overall installing PWA is no more complicated than getting something from a store.
They should have designed it as a proper native experience.
Yes, the service worker thing is annoying but you possibly don't need it if you have a server backend. It's basically a glirified website with a home screen icon. Most of the native vehicle, asset or fitness tracking apps need a backend anyways and they fail miserably when disconnected from the network.
Better do a mobile Web friendly website and leave it at that.
Most users hardly tell the difference anyway.
And the metrics are saying that people click it?
No -- but you could. And it wouldn't be the end of the world. So I'm just saying, DX doesn't eclipse all other considerations.
'Twas before my time. What was so great about it? I remember needing it installed for Netflix like 15 years ago. Did you ever work with Flash? How was that?
If you ever worked seriously on anything non-SPA you would never, ever claim SPAs “dramatically reduce complexity”. The mountain of shit you have pull in to do anything is astronomical even by PHPs standards and I hate PHP. Those days were clean compared to what I have to endure with React and friends.
The API argument never sat well with me either. Having an API is orthogonal: you can have one or do not have one, you can have one and have a SSR app. In the AI age an API is the easy part anyway.
This. From a security perspective, server side dependencies are way more dangerous than client side.
You write:
<div id="moo" />
<form hx-put="/foo" hx-swap="outerHTML" hx-target="#moo">
<input hidden name="a" value="bar" />
<button name="b" value="thing">Send</button>
</form>
<div id="moo" />
<form>
<input hidden name="a" value="bar" />
<button name="b" value="thing" onclick="handleSubmit(event)" >Send</button>
</form>
<script>
async function handleSubmit(event) {
event.preventDefault();
// the form submit stuff
const form = event.target.form;
const formData = new FormData(form);
const submitter = event.target;
if (submitter && submitter.name) {
formData.append(submitter.name, submitter.value);
}
// hx-put
const response = await fetch('/foo', {
method: 'PUT',
body: formData,
});
/ hx-swap
if (response.ok) {
const html = await response.text();
// hx-target
const target = document.getElementById('moo');
const temp = document.createElement('div');
temp.innerHTML = html;
target.replaceWith(temp.firstElementChild);
}
}
</script>
Going with your example, how would you do proper validation with HTMX? For example, the input element's value cannot be null or empty. If the validation fails, then a message or something is displayed. If the validation is successful, then that HTML is replace with whatever?
I have successfully gotten this to work in HTMX before. However, I had to rely on the JS API for that is outside the realm of plain HTML attribute-based HTMX. At that point, especially when you have many inputs like this, the amount of work one has to do with the HTMX JS API starts to look at lot like the script tag in your example, but I would argue it's actually much more annoying to deal with.
1. Do the validation server side and replace the input (or a label next to the input, see https://htmx.org/examples/inline-validation/)
2. Use the HTML 5 Client Side form validation API, which htmx respects:
https://developer.mozilla.org/en-US/docs/Learn_web_developme...
So, I did end up going with #1 with a slight variation.
You also commented on another comment of mine stating:
> if you are using the htmx javascript API extensively rather than the attributes, you are not using htmx as it was intended
There seems to be some confusion, and I apologize. I extensively used attributes. That wasn't the part of the API I was referring to. Rather, I should have specified that I was heavily relying on a lot of the htmx.on() and html.trigger() methods. My usage of htmx.trigger() was predominately due to something being triggered on page load, but also, it needed to be triggered again if a certain condition was met -- to refetch the html with the new data -- if that makes sense.
I should also preface that I was working on this project about two years ago. It looks like a lot has changed with HTMX since then!
Not sure exactly what you're talking about w.r.t 'the amount of work one has to do with the HTMX JS API', but I've found that form validation with htmx and a backend server works really well with just a tiny bit of JS and a little care crafting the backend's validation error response: https://dev.to/yawaramin/handling-form-errors-in-htmx-3ncg
After enough of the HTMX JS API, I figured, "What is HTMX even buying me at this point?" Even if plain JS is more verbose, that verbosity comes with far less opinions and constraints.
> You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE.
Now you're dealing with 2 sets of tooling instead of 1.
> And just like the specific use cases you mentioned for client routing I can also argue that many sites don’t care about SEO or first paint so those are non features.
There is no app which would not care about first paint. It's literally the first part of any user experience.
> So honestly I would argue for SPA over a server framework as it can dramatically reduce complexity. I think this is especially true when you must have an API because of multiple clients.
So SEO and first paint are not necessary features, but an API for multiple clients is? Most apps I've worked with for over 15 years of web dev never needed to have an API.
> I think the DX is significantly better as well with fast reload where I don’t have to reload the page to see my changes.
With backend apps the reload IS fast. SPA's have to invent tooling like fast reload and optimistic updates to solve problems they created. With server apps, you just don't have these problems in the first place.
You still have to deal with all the tooling you are talking about, right? You’ve just moved the goalpost to the BE.
And just like the specific use cases you mentioned for client routing I can also argue that many sites don’t care about SEO or first paint so those are non features.
So honestly I would argue for SPA over a server framework as it can dramatically reduce complexity. I think this is especially true when you must have an API because of multiple clients.
I think the DX is significantly better as well with fast reload where I don’t have to reload the page to see my changes.
People are jumping into nextjs because react is pushing it hard even tho it’s a worse product and questionable motives.