4 ms·

I think the title is referring to the ecosystem and not the technology. • How many frameworks for Java, Python, Bash, etc did you have to learn? • Did you swi

I think the title is referring to the ecosystem and not the technology. • How many frameworks for Java, Python, Bash, etc did you have to learn? • Did you switch from Redis to X because the former was deprecated N months later? • Are OVH, Heroku, AWS updates getting in the way of your development process? Learning a technology by itself like Node.js is not a problem, the problem is that front-end development nowadays requires so many small and fragile tools just to build a web application compared to the number of tools that you would need in another language like C# where the most recognized libraries are several times more stable and change with much less frequency. Mentioning things like database engines, cloud platforms and version control tools is out of the scope of the discussion because they are encapsulated tools, and at least the ones that you mentioned (before you updated your comment) have a very low release rate, and to my opinion are very-very stable in comparison with the JavaScript ecosystem. > Having to learn a new library every 3-4 years (usually when starting a new job) is it really a big deal? Yes, it is. > In my career I also had to learn … Not for the same project and/or development cycle, but surprise me if I that's the case. > And according to HN, what's really hype right now is Rust, Go, FoundationDB, Kubernetes, and so on People stick to them and that's it, I don't know any serious company changing their tech stack every N months just because they are trendy on HN. Several years later they may switch to a new tech stack because the project requirements have changed but not because the author of one of the thousand libraries that you are importing decided to carelessly modify a feature that another dozen libraries use, consequently breaking not just your code but also many others. Or, in another scenario, your package manager doesn't betray you by destroying all your file system during a careless upgrade [1]. > Learn REST and GraphQL, SVN and Git, Linux and Windows Server, Vagrant and Docker You are missing the point entirely… We are talking about how "unstable" front-end development is, not how many tools you have to learn. If I could learn 10-20 tools for front-end development and be certain that they will not drastically change in a year or so, or at least get deprecated, then — and only then — I would not have to worry so much about available updates via the main and (unfortunately) only package manager that the JavaScript community have. [1] https://github.com/npm/npm/issues/19883 https://github.com/npm/npm/issues/19883

tracker1 8y ago
I've only seen one issue in React that affected me.. when they started requiring PascalCase for component names with JSX. Everything else has been really nice. I glommed onto Redux and thunks pretty early on, and have been wrapping around fetch about as long. I used Bootstrap for a long time, and progressed to material-ui with very little disconnect. Those have been my personal preferences for several years, and they haven't changed THAT much in terms of usage. Now that's nothing like I've seen with say Angular, Angular2-6 (including the long, painful Angular 2 beta cycle). I've also seen tooling evolve, and some of that painful... Webpack and Babel have changed a lot. create-react-app doesn't solve it all, but helps abstract some of it. Node has had growing pains and is finally fairly stable for those developing/adapting native code to run in node. I haven't really had to re-learn anything for a project as it's progressed any more than I did 15 years ago on the backend.
- acemarke 8y ago
  The JSX transform has, as far as I know, _always_ required PascalCase for component names. That's how it distinguishes between "this tag name is actually a variable pointing to a component" and "this tag name should be turned into a string".
  - tracker1 8y ago
    Nope.. early on, you could use any local variable... there was a whitelist of html elements... they did a cleanup that required the PascalCase and defaulted to html element render for anything else. It was around 0.10 or so, iirc.

tracker1 8y ago

I've only seen one issue in React that affected me.. when they started requiring PascalCase for component names with JSX. Everything else has been really nice. I glommed onto Redux and thunks pretty early on, and have been wrapping around fetch about as long. I used Bootstrap for a long time, and progressed to material-ui with very little disconnect. Those have been my personal preferences for several years, and they haven't changed THAT much in terms of usage. Now that's nothing like I've seen with say Angular, Angular2-6 (including the long, painful Angular 2 beta cycle). I've also seen tooling evolve, and some of that painful... Webpack and Babel have changed a lot. create-react-app doesn't solve it all, but helps abstract some of it. Node has had growing pains and is finally fairly stable for those developing/adapting native code to run in node. I haven't really had to re-learn anything for a project as it's progressed any more than I did 15 years ago on the backend.

acemarke 8y ago
The JSX transform has, as far as I know, _always_ required PascalCase for component names. That's how it distinguishes between "this tag name is actually a variable pointing to a component" and "this tag name should be turned into a string".
- tracker1 8y ago
  Nope.. early on, you could use any local variable... there was a whitelist of html elements... they did a cleanup that required the PascalCase and defaulted to html element render for anything else. It was around 0.10 or so, iirc.