6 ms·

Sorry, but this is a rant. I am deeply saddened by the current state of affairs in the web today. in Javascript right now there are so many layers upon layers

by fb03 5y ago

Sorry, but this is a rant. I am deeply saddened by the current state of affairs in the web today. in Javascript right now there are so many layers upon layers upon layers of DSLs and mannerisms on top of questionable language features which 'must be used' because the former language features are not cool anymore since a few days ago. The whole ecosystem is turning into a meme of itself. In a few months someone will reinvent another part of the big clusterfuck again and publish it in a shiny new website and we'll have another 3 month old Javascript framework being touted as the next earth-shattering thing that will revolutionize all things. And again. And again. We have nice things. We have nice abstractions already. We should be working on toning down and optimizing the good stuff, the good bits that get stuff done, not ramping up on new shiny buttons for each and every edge case out there just because we need to stay on the loop (whatever this loop is).

c0balt 5y ago
The amount of reinvention in the JS space is mind boggling. While this works to drive the whole thing forward it would be nice to see more LTS support rather than yet another templating library. Not that most their languages are inherently better but some have a way of mitigating the problem slightly, like e.g. python's extensive std lib collection.
- fb03 5y ago
  I am a backend engineer by trade, and I have been trying to learn me a little React because I decided I should learn new tech (not the stuff I use on a daily basis, which is Python) on side projects. So the backend is being done in Rust, and frontend is using React. I had this moment where I thought "well, I need Typescript, because I want nicely typed interfaces and contracts, and I need React". Turns out it's not easy like that. To cobble everything together you need a proper template for webpack. and there's Babel and that also needs to be caressed in the right React-y way. You can't just "hop in". You have to use cookiecutter-styled tools to bootstrap because the whole thing just got so complex so that even a Hello World styled project needs a mindboggling amount of tools all orchestrated and plugged into each other in the right way or it all blows up in your face. Also, there are more than one cookiecutter-styled tools and you have to choose the right one. "But don't fret you can always run eject to see the whole machinery inside". It's saddening and tiring.
  - lsalvatore 5y ago
    You didn't need TypeScript. That was your first mistake. If you had chosen Create-react-app (the official boilerplate) - that's all you need. Hello world right out of the box. Nothing blows up in your face. Nothing mind-boggling. I've never had to ever run eject. Nothing saddening, nothing tiring. In fact- just the opposite. Happiness, joy, energizing React productivity.
    - tclancy 5y ago
      You can literally pass a flag to that command to get all the same stuff in Typescript. Don’t yuck someone else’s yum.
    - dragonwriter 5y ago
      Creat-React-App has a TS option (and, IIRC, it's not that hard to use TS on a CRA app that wasn't created with that option, but it's been a while since I did that.) Manually setting up React (with or without TS) isn't all that hard, either.
  - RedShift1 5y ago
    Same experience here, I wouldn't be able to get off the ground without those templates. Plus updating can be a nightmare, if you regularly update and the build breaks then it's easy to find out what caused it, however a few months down the line be prepared to spend significant time figuring out what broke again and how to fix it.
  - deleted 5y ago
    [deleted]
  - iamleppert 5y ago
    Why do you need types to learn React? You really need a compiler to tell you when you have made a mistake that bad? Your first mistake is trying to add typing on a dynamic language that works just fine without types. You won’t really learn the underlying language that well that way, and you therefore won’t have a good understanding of it. TypeScript makes sense in large projects, with many developers where you need to catch a class of problems that compile time type checking can catch. It doesn’t offer a lot or add much in the way of actually learning the fundamentals of frontend development and is a distraction when viewed through that lens. Are you sure you weren’t actually avoiding the scary unknowns of actual learning and doing a bunch of busy work to bring familiarity into an otherwise unfamiliar space? I catch myself doing that a lot, especially if I need to learn a completely new language to learn something. I wasted a lot of time trying to make OpenCV work with native JavaScript when I should have just learned enough C++ to get by.
- mysterydip 5y ago
  While driving it forward, it also fragments it: look up a tutorial for any given thing you might want to learn to do and it's done six different ways. Trying to integrate code written at different times can be an exercise in frustration.
filterfish 5y ago
Don't mistake being effusive with ranting.
lsalvatore 5y ago
JavaScript framework churn (on the frontend) ended 6 years ago. The only thing keeping this meme going is commenters on HN.
- smolder 5y ago
  What framework did you end with? What state management approach? What styling strategy? I think the churn stops whenever you stop adopting new things to replace functionally equivalent things, but new things still come along and get hyped.
  - lsalvatore 5y ago
    Software engineers that replace things with functionally equivalent things don't get a lot of actual work done and typically aren't employed for very long either. So, the churn had to stop long ago from inside the average high performing company (and professional engineer's mindset). Only when things are really bad (as they were 6 years ago) is it worth rewriting everything. We've done that and it's not happening again. You can follow my work here: react.school
  - bern4444 5y ago
    Library: React State Management (if needed): Redux via Redux Tool Kit. Maybe Redux Toolkit Query too if necessary. Style Strategy: SCSS or Styled Components (if I have to) Framework: Remix[0] This is honestly a very easy set of questions to answer today. [0] remix.run
- mdoms 5y ago
  So because there's no churn and everything is standardized I assume you can tell me which state management library is the correct choice for a React app without causing any controversy?
  - lsalvatore 5y ago
    Sure, book a free call with me here: react.school/call
throwaway984393 5y ago
The tech industry is completely dependent on throwing away anything that is finally half-stable, so they can convince VCs to shovel out more cash to rebuild everything in a new language, framework, system, protocol, app, etc. If you look at what we actually do with the web, it's the same thing we were doing 20 years ago. Click on links, look at pictures of cats, chat with your friends on message boards and instant messenger, send e-mail, buy the occasional thing online, read the news, play games. If you changed none of the software, the result would be the same, but we would have saved a couple trillion dollars (or, alternately, not caused people to fork out a couple trillion dollars). The only functional change today is much more streaming video, and instead of writing blogs, everyone's recording podcasts (which we had back then as "streaming audio" using IceCast).
nawgz 5y ago
I don't understand this view. JS is the most accessible and distributable code someone can write. It is accompanied for free by a portable, OS-independent UI library with application-tier capabilities that requires no user friction to download. OF COURSE this construct comes with a ton of bullshit and noob reinventions. But you, as a software engineer, should have the skillset to pick some strong set of libraries and stand behind it. For me, I use React, React-Router-Dom v5, MobX, TypeScript, and roll my own for everything else. It works well, my code from 2017 that runs without updates is easy to port if I want to because it uses the same underlying libraries, and the browser platform is fairly stable overall. How does it upset you that you can also do some things in a lower friction way capitalizing on new language features? The old ones didn't go anywhere. The old libraries didn't stop working. Nothing fundamentally changed, some idiots just bolted on some new stuff and some geniuses carefully architected some other new stuff. Why is velocity something to rail against in and of itself? It impacts you exactly how much you let it.
ryan_lane 5y ago
As someone who's always been somewhat mediocre at JS and html/css programming, but finds himself needing to build something new every few years. I'm constantly amazed at how much easier it's become to build something that I would have wanted to build before, but didn't have the experience or time to build. I recently built a dashboard/reporting site for Neo4j that's completely config driven (delivered from the backend), which can refetch the config (with a gmail style "Settings have changed - Refresh" notification) and have only changed parts of the site update. It has tables with resizeable columns, filtering, search, ordering, virtualization, server side fetch, etc. It has progress charts, bar charts, counts, markdown rendering, json schema rendering. It has inputs that autocomplete, with single or multi-select. It's fully responsive, and works perfectly on desktops, tablets and phones. If I would have tried to build this three years ago, I wouldn't have been able to do a fraction of these things. So, rant away, but the frontend community is amazing and they deserve way more credit than they get.
authed 5y ago
Just don't switch to those new shiny useless/bad frameworks? Or do you mean that you have to suffer like when you visit websites, like cnn.com: https://i.imgur.com/VAZMUx8.png https://i.imgur.com/VAZMUx8.png

by fb03 5y ago

c0balt 5y ago

The amount of reinvention in the JS space is mind boggling. While this works to drive the whole thing forward it would be nice to see more LTS support rather than yet another templating library. Not that most their languages are inherently better but some have a way of mitigating the problem slightly, like e.g. python's extensive std lib collection.

fb03 5y ago
I am a backend engineer by trade, and I have been trying to learn me a little React because I decided I should learn new tech (not the stuff I use on a daily basis, which is Python) on side projects. So the backend is being done in Rust, and frontend is using React. I had this moment where I thought "well, I need Typescript, because I want nicely typed interfaces and contracts, and I need React". Turns out it's not easy like that. To cobble everything together you need a proper template for webpack. and there's Babel and that also needs to be caressed in the right React-y way. You can't just "hop in". You have to use cookiecutter-styled tools to bootstrap because the whole thing just got so complex so that even a Hello World styled project needs a mindboggling amount of tools all orchestrated and plugged into each other in the right way or it all blows up in your face. Also, there are more than one cookiecutter-styled tools and you have to choose the right one. "But don't fret you can always run eject to see the whole machinery inside". It's saddening and tiring.
- lsalvatore 5y ago
  You didn't need TypeScript. That was your first mistake. If you had chosen Create-react-app (the official boilerplate) - that's all you need. Hello world right out of the box. Nothing blows up in your face. Nothing mind-boggling. I've never had to ever run eject. Nothing saddening, nothing tiring. In fact- just the opposite. Happiness, joy, energizing React productivity.
  - tclancy 5y ago
    You can literally pass a flag to that command to get all the same stuff in Typescript. Don’t yuck someone else’s yum.
  - dragonwriter 5y ago
    Creat-React-App has a TS option (and, IIRC, it's not that hard to use TS on a CRA app that wasn't created with that option, but it's been a while since I did that.) Manually setting up React (with or without TS) isn't all that hard, either.
- RedShift1 5y ago
  Same experience here, I wouldn't be able to get off the ground without those templates. Plus updating can be a nightmare, if you regularly update and the build breaks then it's easy to find out what caused it, however a few months down the line be prepared to spend significant time figuring out what broke again and how to fix it.
- deleted 5y ago
  [deleted]
- iamleppert 5y ago
  Why do you need types to learn React? You really need a compiler to tell you when you have made a mistake that bad? Your first mistake is trying to add typing on a dynamic language that works just fine without types. You won’t really learn the underlying language that well that way, and you therefore won’t have a good understanding of it. TypeScript makes sense in large projects, with many developers where you need to catch a class of problems that compile time type checking can catch. It doesn’t offer a lot or add much in the way of actually learning the fundamentals of frontend development and is a distraction when viewed through that lens. Are you sure you weren’t actually avoiding the scary unknowns of actual learning and doing a bunch of busy work to bring familiarity into an otherwise unfamiliar space? I catch myself doing that a lot, especially if I need to learn a completely new language to learn something. I wasted a lot of time trying to make OpenCV work with native JavaScript when I should have just learned enough C++ to get by.
mysterydip 5y ago
While driving it forward, it also fragments it: look up a tutorial for any given thing you might want to learn to do and it's done six different ways. Trying to integrate code written at different times can be an exercise in frustration.

filterfish 5y ago

Don't mistake being effusive with ranting.

lsalvatore 5y ago

JavaScript framework churn (on the frontend) ended 6 years ago. The only thing keeping this meme going is commenters on HN.

smolder 5y ago
What framework did you end with? What state management approach? What styling strategy? I think the churn stops whenever you stop adopting new things to replace functionally equivalent things, but new things still come along and get hyped.
- lsalvatore 5y ago
  Software engineers that replace things with functionally equivalent things don't get a lot of actual work done and typically aren't employed for very long either. So, the churn had to stop long ago from inside the average high performing company (and professional engineer's mindset). Only when things are really bad (as they were 6 years ago) is it worth rewriting everything. We've done that and it's not happening again. You can follow my work here: react.school
- bern4444 5y ago
  Library: React State Management (if needed): Redux via Redux Tool Kit. Maybe Redux Toolkit Query too if necessary. Style Strategy: SCSS or Styled Components (if I have to) Framework: Remix[0] This is honestly a very easy set of questions to answer today. [0] remix.run
mdoms 5y ago
So because there's no churn and everything is standardized I assume you can tell me which state management library is the correct choice for a React app without causing any controversy?
- lsalvatore 5y ago
  Sure, book a free call with me here: react.school/call

throwaway984393 5y ago

The tech industry is completely dependent on throwing away anything that is finally half-stable, so they can convince VCs to shovel out more cash to rebuild everything in a new language, framework, system, protocol, app, etc. If you look at what we actually do with the web, it's the same thing we were doing 20 years ago. Click on links, look at pictures of cats, chat with your friends on message boards and instant messenger, send e-mail, buy the occasional thing online, read the news, play games. If you changed none of the software, the result would be the same, but we would have saved a couple trillion dollars (or, alternately, not caused people to fork out a couple trillion dollars). The only functional change today is much more streaming video, and instead of writing blogs, everyone's recording podcasts (which we had back then as "streaming audio" using IceCast).

nawgz 5y ago

I don't understand this view. JS is the most accessible and distributable code someone can write. It is accompanied for free by a portable, OS-independent UI library with application-tier capabilities that requires no user friction to download. OF COURSE this construct comes with a ton of bullshit and noob reinventions. But you, as a software engineer, should have the skillset to pick some strong set of libraries and stand behind it. For me, I use React, React-Router-Dom v5, MobX, TypeScript, and roll my own for everything else. It works well, my code from 2017 that runs without updates is easy to port if I want to because it uses the same underlying libraries, and the browser platform is fairly stable overall. How does it upset you that you can also do some things in a lower friction way capitalizing on new language features? The old ones didn't go anywhere. The old libraries didn't stop working. Nothing fundamentally changed, some idiots just bolted on some new stuff and some geniuses carefully architected some other new stuff. Why is velocity something to rail against in and of itself? It impacts you exactly how much you let it.

ryan_lane 5y ago

As someone who's always been somewhat mediocre at JS and html/css programming, but finds himself needing to build something new every few years. I'm constantly amazed at how much easier it's become to build something that I would have wanted to build before, but didn't have the experience or time to build. I recently built a dashboard/reporting site for Neo4j that's completely config driven (delivered from the backend), which can refetch the config (with a gmail style "Settings have changed - Refresh" notification) and have only changed parts of the site update. It has tables with resizeable columns, filtering, search, ordering, virtualization, server side fetch, etc. It has progress charts, bar charts, counts, markdown rendering, json schema rendering. It has inputs that autocomplete, with single or multi-select. It's fully responsive, and works perfectly on desktops, tablets and phones. If I would have tried to build this three years ago, I wouldn't have been able to do a fraction of these things. So, rant away, but the frontend community is amazing and they deserve way more credit than they get.

authed 5y ago

Just don't switch to those new shiny useless/bad frameworks? Or do you mean that you have to suffer like when you visit websites, like cnn.com: https://i.imgur.com/VAZMUx8.png https://i.imgur.com/VAZMUx8.png