Hacker News Reader

Comment by rob74 | Hacker News Reader

Well, if developers would approach their task with knowledge and wisdom, then the abomination that is Node.js would never have been unleashed on the developer community. But here we are: "yay, Google has written a blazingly fast JS engine, so now we can use JS in the backend!" - never once stopping to question if this is really a good idea...

View on HN

Server-side JS is an exceedingly useful tool for certain use cases. Specifically, sharing server and client logic. I know everyone here likes to hate on JS frameworks, but the productivity of being able to build one thing in one language instead of the same thing twice in two languages is hard to overstate.

Sure, that has some trade offs like page bloat. But almost all of the JS framework universe is focused now on reducing or eliminating those trade offs: partial hydration, build time code elimination, server components, etc. There’s still a long way to go before the DX and UX reach parity, but it’s inevitable, and closer than one might think (see Qwik[1]).

1: https://github.com/BuilderIO/qwik

There's no reason to use two languages. All the major server-side frameworks still exist and many have been upgraded with the modern component style templating for the frontend too.

Nothing is new with JS frameworks. Hydration and fancy "resumable" state has been done over a decade ago with serialized viewstate and AJAX controls. The JS world is just discovering how powerful server-side stuff can be after all this time.

I don't know, maybe I'm dumber than I think I am, but I've been building software for 10+ years with a lot of different tools in a lot of different environments and I really like Node. Like with all tools, it depends on the use case and the players, but I've used it with great success for BE web services (yes, at scale), CLI tools, and automation. Some of the worst and some of the best code I've ever read has been JS. It requires discipline, but that doesn't make it inherently bad.

I think it was a brilliant idea. I don't know any ecosystem where I can be as productive as with Node.js+Typescript+React. Having everything typed from frontend to backend, even the email templates (tsx + ReactDOMServer) makes refactoring a breeze and work across the entire project.

I almost spit out my coffee. I had completely forgotten that's how we got here. It developed like pretty much everyone thought it would.

Is it that bad? I'm kinda new to web development.

Bad? I don't think I'd use that term. Fragmented? Full of "bike-shedding"? Fanboi-ism? Definitely those things apply. There are some tools that seem to dominate the market currently. And as often is the case, you may form a love/hate relationship with them. Web dev in 2008 was simple. You had your markup, your CSS, and your scripts that progressively enhanced that markup/styling. There are subsets of people that never wanted it to move beyond that. There's another subset that's been pushing the boundaries of what the web can do. Both are right, and both could stand to learn a few things.

If you find yourself working alone/contracting, you have absolute freedom to try out anything you want. Find what works for you. Do NOT use something simply because "the cool kids on Twitter are hyping it". Find out if those tools actually make your dev experience, and your user's experience better.

If you find yourself on a team at a larger org, learn to be comfortable with the tools they've chosen - until you reach a point where you get to have a say.

Web development can be an awfully fun career but I'd urge you as you get a bit deeper into the programming side of it, to really learn some fundamental concepts. Maybe start with Jack Herrington videos on Youtube: https://www.youtube.com/c/JackHerrington

I've found him to be very level-headed in his approach.

I don't blame the language for what the community does though. I mean, I've suffered through VBScript. I know how bad a utility/glue language can really be. Netscape did have it running on the server way back in the 90s too. Should we create services with it? I dunno. For some things, I really don't care. Should we be tossing it CPU intensive, multiple db query traffic? No. No it doesn't do well at all in those scenarios. I've done enough PHP (really bad PHP) to realize that any time we lower the bar of entry, we're going to get a lot of folks with no programming background. That's actually pretty cool! What's not cool is getting folks who have no background, and refuse to listen to anyone who does.

I miss the days when bundling was just dumping a couple of JS scripts into the scripts/lib directory and that was it.

Guess what is my approach when having side gigs.

>Guess what is my approach when having side gigs

Webpack?

Nope, my first sentence, pack the JavaScript stuff on the scripts lib and let Java/.NET build take care of the rest, as it belongs on a proper full stack SSR framework.

Those days are still here, and now getting better. All these server-side frameworks have figured out their own component-based UI frontends. Now you can get all the same design advantages without the JS overhead and nonsense.

Hum... Creating node was a good idea. Using it like people use nowadays that wasn't.

There are plenty of reasons why you may want a standalone JS interpreter.

Reply on news.ycombinator.com