Hacker News Reader

Comment by troad | Hacker News Reader

I'm very glad I never bought into fullstack JS/TS.

My JS is frontend only, served as a compiled bundle off a server that doesn't even have a JS runtime of its own. Whatever random vulnerabilities the frontend contains are limited in blast radius to the user's own browser, and since all frontends should be untrusted anyway, there is no real security risk to the server or backend. No reason to update more than a few times a year, if that.

Combine with obvious basic security practices like pnpm cooldowns + no build scripts. When you upgrade a few times a year, and frontend vulns don't matter, there's really no limit to the cooldown you can set. 60 days, why not.

View on HN

Also, I feel like a lot of fullstack JS is written by people who started with frontend JS and don't have nearly enough backend experience

JS programmers today are the PHP programmers of 25 years ago. Remember how many SQL injection bugs there was at the time? Little Bobby Tables remembers.

The standards haven't changed; for the vast majority of JS programmers, this is their first programming language and they have no solid foundation of architecture and security.

So what you get are these overly enthusiastic newbies that want to share their latest achievement with the world (say, a function to left pad a string), and why not include a fancy post-install script with emojis that makes adoption even simpler for other complete noobs? And this is the result.

I wrote a little PHP about 25 years ago and hated it, dropped it like a rock as soon as it wasn't my job. Before that basic, assembly, c, and c++. Then scheme, C#, Java, prolog, and others too minor to mention before I started using nodejs. My last company I chose full stack Typescript and it was great. There's a lot to love and a plenty to avoid.

You're not wrong that there's a lot of crap, a massive legacy, and some bad behavior. It is also approachable, flexible, and portable. Even if you sometimes need to say "Wat?!?"

And before PHP it was Visual Basic, and COBOL even further back. I'm convinced trying to teach people to program without them understanding the basics of how computers work will lead to this.

It is not about not teaching them, I am co-graduated with many people who do YOLO JS and AI slop right now. They had to pass the same architecture and microprocessor programming lectures.

Educated or not, there are many programmers who simply don't give a fuck. Unless you make all the IT jobs a regulated profession and enforce significant yearly recertification, the mediocres will dominate. You cannot be nice and inclusive to mediocre programmers and expect good baselines.

> Unless you make all the IT jobs a regulated profession and enforce significant yearly recertification, the mediocres will dominate.

This would merely optimise the industry for people who are good at wiggling through bureaucratic hurdles. It would entrench mediocrity while lopping off the extreme ends of the skill distribution - on both ends.

I came from systems programming, so I think half of what happens in JS is nuts.

A lot of JS is nuts, but most of its basic behaviour that makes it not a good backend language make it an alright scripting language for the web specifically. I wish we would've used something tcl-y instead though, it's much cleaner and the "everything is a string"-ness makes sense for a fundamentally text based medium (the web)

If you drop-in replaced JS today with Lua, you'd have a conceptually similar language with a lot of warts chopped off. Backend devs can just cope with 1-based indexing though.

> compiled bundle

Where does that compilation happen again? Not on the front end and it happens exactly where the exploits have been targeting (dev and build boxes).

Hardly a factor when you're (deliberately) months behind.

It is your development machine's AWS keys they want. The server's keys should be too finly scooped anyway.

Not likely to be a major risk if you update every few months, to some major version that's already over a month old.

I would imagine it's the opposite. Most dev's machines can't query the prod database, for example, whereas a prod server can.

Nope, they've been targeting credentials so they can deploy whatever they like into prod. They prefer the build machine with it's broader rights than the individual dev boxes.

If you serve any third party logic, such as advertisements, your code is just as potentially compromised.

Only the frontend, which is already untrusted. Any risk would be restricted to individual users who used the compromised frontend to communicate something sensitive, and while that's not great, it is significantly better than the backend being compromised. A very significant reduction in blast radius.

Funnily enough, I don't actually think I do serve third party JS, though. Don't serve ads, don't use external telemetry, don't use JS CDNs. I don't think you have to go quite as far as I do, though - I imagine if your ads are Google AdSense or something, you're probably going to be fine.

Reply on news.ycombinator.com