4 ms·

"Popularity contest" describes the front-end community in a nutshell. I've been in software development since before the web was a big deal. Never have I seen a

"Popularity contest" describes the front-end community in a nutshell. I've been in software development since before the web was a big deal. Never have I seen any language have more "high school popularity" style personalities hawking whatever the "best" library is... without any knowledge or wisdom. Any attempt to point out why some of these technologies or approaches are a "bad idea" leads to massive downvote trains. The saddest part is, I could be accused of "gatekeeping" when I say, "maybe we can learn from the past?". Nope. Yet somehow, folks with absolutely no pedigree are out there deciding what a "best practice" is... and immediately the "community" hops on board. It's almost cultish in that way. Don't you dare ask "who decided this was best?". What qualifications does that person have to decide a "best practice". You'll be met with the name of the company where that person works... as if that means something. Even still, THIS is the state of the JavaScript. None of that has to do with the language.

rob74 5y ago
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...
- smrtinsert 5y ago
  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.
  - MonaroVXR 5y ago
    Is it that bad? I'm kinda new to web development.
    - nobleach 5y ago
      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 https://www.youtube.com/c/JackHerrington I've found him to be very level-headed in his approach.
- pjmlp 5y ago
  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.
  - MonaroVXR 5y ago
    >Guess what is my approach when having side gigs Webpack?
    - pjmlp 5y ago
      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.
  - manigandham 5y ago
    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.
- marcosdumay 5y ago
  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.
- nobleach 5y ago
  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.
- eyelidlessness 5y ago
  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 https://github.com/BuilderIO/qwik
  - manigandham 5y ago
    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.
- adevx 5y ago
  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.
- derrikcurran 5y ago
  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.
MonaroVXR 5y ago
As a person new to web development, I feel the same as what you have described. Since I'm not that long in I.T. I would ask... What could we learn from the past?

rob74 5y ago

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...

smrtinsert 5y ago
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.
- MonaroVXR 5y ago
  Is it that bad? I'm kinda new to web development.
  - nobleach 5y ago
    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 https://www.youtube.com/c/JackHerrington I've found him to be very level-headed in his approach.
pjmlp 5y ago
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.
- MonaroVXR 5y ago
  >Guess what is my approach when having side gigs Webpack?
  - pjmlp 5y ago
    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.
- manigandham 5y ago
  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.
marcosdumay 5y ago
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.
nobleach 5y ago
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.
eyelidlessness 5y ago
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 https://github.com/BuilderIO/qwik
- manigandham 5y ago
  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.
adevx 5y ago
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.
derrikcurran 5y ago
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.

MonaroVXR 5y ago

As a person new to web development, I feel the same as what you have described. Since I'm not that long in I.T. I would ask... What could we learn from the past?