11 ms·

> at the peak of Javascript fatigue Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse. You just mentioned webpack is go

> at the peak of Javascript fatigue Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse. You just mentioned webpack is going to be replaced?? That's unfortunately very typical for the JS eco system. 7 years ago we had Grunt, then about two years later Gulp, then about a year later Webpack, now apparently Bazel? Interesting, never heard of it, but I still feel fatigue. I spent quite some time to master Webpack, and again I'll have to start all over for the 4th time now learning the next bundler.. I just started with React Hooks some months ago. First we had mixins(about 5 years ago), that was replaced with Higher Order Components, then we had to start writing React in the brand new ES6 classes, then we saw the Render Props, the Pure Functions, etc.. and now ES6 classes and all the rest are deprecated, because Dan Abramov had another idea for again a new design principle that's just less than a year old: Hooks.. Oh, and we don't do that in JS, that is not sane anymore, every job I get nowadays is Typescript. I mean, think twice before you say the Javascript fatigue is past it's peak.

DCoder 7y ago
TypeScript was and still is a very necessary addition over plain JS, but everything else you said is spot on. This ecosystem is very much a Red Queen's race, you have to learn all sorts of tooling that will be deprecated and forgotten in two years or less.
egeozcan 7y ago
None of the tools you mentioned are unsupported as of now, though. I recently updated a browserify based project from years ago to 16.3 in an afternoon and it just worked. I remember the days I was afraid to do npm update the dependencies, I was copy pasting build script configurations for new projects, I used to use code mods every other month to make huge refactors (and badly), packages disappearing, every project inventing how to manage state (not just react)... All of this is past for me. Yeah of course it's just a data point but there's the fact that you can start a complex web app project with one command these days and not care about core dependencies. I expect it'll go only better. Maybe it's me getting experienced but I certainly wasn't a beginner few years ago, not even close. I'd love to hear what kind of difficulties you are having with your projects though, it's very possible that I'm missing something.
- siempreb 7y ago
  > None of the tools you mentioned are unsupported as of now, though. I mean working as a professional, doing my next gig. Do you think I can still use my Grunt or Gulp skills there? The landscape is now again very different than it was a year ago. I cannot even code in ES6 anymore, all the jobs are TS and React Hooks at the moment. When I say I prefer JS over TS my colleagues think I'm not smart and skilled enough to understand the benefits of TS. There is not much choice unfortunately, independent of being supported or unsupported.
  - wilsonrocks 7y ago
    React Hooks doesn't preclude ES6 though? Really, they're just functions that have some weirdness/magic about when you call them. I love them, but that's not really what this thread is about, of course:)
  - egeozcan 7y ago
    It's not like you've been coding with Javascript and now you need to learn Haskell though. Companies love to sprinkle newest trends in their job ads with the technologies they used in their last 100 LOC pilot project and you discover in your first day that there are many big projects which use gulp, grunt and others with ES3, some without async support etc. I got a friend in Silicon Valley (I'm in Germany and here the attitude is more towards reliability and stability) and even there he got many interviews and a new job without listing many of the newest libraries/languages in professional capacity. Plus, I'd suggest you try Typescript with an open mind. It's amazing.
  - reggieband 7y ago
    I happen to be in the interview gauntlet at the moment for full-stack JS type jobs so I hear what you are saying but it seems to cut both ways. Most places using React are expecting me to be familiar with hooks and everyone using Javascript is asking about familiarity with Typescript. But at the same time they genuinely seem impressed/surprised that I have been using async/await for over a year on my latest professional projects. I want to say this in a nice way but it is difficult. I feel Javascript developers suffer from an inferiority complex. It's like they need to feel what they are doing is "real code" or something. That seems to translate in this crazy pace of replacement of technologies. I think it gives the impression of innovation. To me it feels like an unsteady eco-system still trying to find its footing. The vacillation from OOP to functional and back again feels like uncertainty. From DIY systems like gulp to all-in-one systems like webpack. It's a sector full of people desperate to look like they know what they are doing while they act like they are still trying to figure it all out. All that being said, working in JS in 2018/2019 is significantly more pleasant than it ever was in the past. I find creating back-end Node.js services to be quick and easy and writing front-end systems using React bearable. Despite high volatility there is definite progress.
azangru 7y ago
> and now ES6 classes and all the rest are deprecated, because Dan Abramov had another idea for again a new design principle that's just less than a year old: Hooks. This is so off the mark it’s not even funny. - Dan did not develop the hooks api - he is also on record saying that people don’t need to re-write their components with hooks - class components have not been deprecated in React
- siempreb 7y ago
  It is indeed not funny, and you're off the mark as well: > Dan did not develop the hooks api I didn't say he developed it > he is also on record saying that people don’t need to re-write their components with hooks So? In my daily work I see it all the time. You think I have a say in that when I have a gig at company X? > class components have not been deprecated in React You've got a point there, indeed not officially deprecated, but in practice(again) at company X, you cannot do classes anymore.
  - abacadaba 7y ago
    Annoying, but sometimes a better idea comes along. I think me and many others initial reaction to the hooks presentation was 'yeeaaaassss'. Still in mostly es6 class codebase of course, so haven't had a chance to do too much with them yet, but as long as they're not gonna break backwards compatibility, yes please.
  - fourthark 7y ago
    If people won't even listen to the developers of the tools they use, and insist on "out with the old, in with the new" when those developers are pleading with them not to create extra work for themselves... Whose fault is that?
  - vonseel 7y ago
    There are even linting rules to ban use of class components, IiRC. You’re not wrong. Hooks are being pushed HARD for new code.
vfc1 7y ago
The thing is, we don't need to learn Bazel either. We will just keep running the command "ng build", and internally the CLI will be using Bazel instead of Webpack, but that is transparent for us users. We only see the CLI commands on our end, and the Angular CLI internally will use whatever build tool is best for the job at a given time, and will keep evolving over time. It's such a relief that we don't need to learn build tools in the Angular ecosystem anymore and can focus on application development only.
- ericmcer 7y ago
  Sure... I have never heard of Bazel, but it sounds very black boxish (JS goes in bundles come out!). That is basically the same thing webpack promised in comparison to gulp/grunt. A lower config JS build tool, which is always great until it isn’t. At a certain maturity you will need to dig into your projects build tool.
  - tashoecraft 7y ago
    Bazel is the open source version of googles interns build tooling. It’s not new, but using it outside of google is. It’s also not JavaScript specific, it’s completely language agnostic. You define the rules for building, and bazel will execute it. You can run your entire companies build system off of it.
    - joewrong 7y ago
      Sounds like Make
      - wwright 7y ago
        It covers a lot of the same ground, but IMO is much easier to use all around.
  - vfc1 7y ago
    > At a certain maturity you will need to dig into your projects build tool The command "ng build" takes in typescript and produces optimized lazy-loaded bundles, and there won't be the need to customize that, there aren't a thousand ways to produce bundles after all, there is one optimal way for a given ecosystem, and it does not make sense for each project to reinvent a build system that all it does is transpile, concatenate, minify, compress, etc. like every other project. Any additional build steps besides bundling are usually very simple can often be done either via npm scripts, or a simple shell script. Can you give examples of things for which you would absolutely have to customize the build system?
peruvian 7y ago
While the JavaScript ecosystem is on the volatile side, learning new tools and frameworks every few years is just part of our job. Only in very boring tech jobs would you only have to learn new things maybe once every 5 years. I wouldn't really bother wasting time "mastering" something like Webpack or what replaces it - as the other commenter said we just end up using an abstraction over it anyway.
- discreteevent 7y ago
  The problem with changing tools to fend off boredom is that it has a very short lifespan. Pretty quickly your brain realizes that it's not learning anything fundamentally new and it protests. Hence fatigue. If possible, it's better to focus on the problem domain and try to make the best of that for entertainment. If not then maybe just accept that it's better to be a bit bored than fatigued.
- jbverschoor 7y ago
  It’s not learning a new frameworks and tools. It’s the fact that these tools are usually fragile, and quite frankly not very much new is in there. Also, what’s your goal? To learn new tools over and over again? Or to crate something that that people will use? You sound like a music “producer” (read - tech hobbiest) who keeps switching tools, synths, and hardware instead of just creating music.
  - dpau 7y ago
    Yes, I don't even think the most important issue is that we as developers have js fatigue. The biggest issue is that we are developing web applications that are outdated before they are even released. Our software relies on thousands of dependencies that are constantly changing or even dying off. Updating an application that was built two or even just one year ago is often not a trivial task. So while the frameworks and tooling have thankfully improved, in general the cost of developing and maintaining an application seems to be much greater than in the past (e.g. PHP MVC app with some jQuery sprinkled in).
    - 7y ago
vfc1 7y ago
Nothing like that has happened in the Angular ecosystem, the API is stable for 3 years, and a pleasure to work with. I think this obsession with functions and the functional paradigm is counterproductive in the React ecosystem. Sometimes, the best way to represent something is a class. When you have some data and a series of closely related fucntions that modify the data and are highly related to the data, it's better to use a class. This hooks API thing is anything but functional, way too much magic. Its stateful programming diguised as functional.
- csande17 7y ago
  Indeed, hooks are pretty much the furthest thing from functional programming there is. In functional programming, functions can safely be called any number of times from anywhere in the program, and they'll always return the same result for the same arguments. Hooks, on the other hand, crash and burn at runtime if you call them outside a React component function, or in a different order or number from how you called them the first time your component was rendered.
kaycebasques 7y ago
> Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse. No comment regarding the "peak" but 3 years ago is when the very influential How It Feels To Learn JavaScript In 2016 post came out. https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...
tracer4201 7y ago
Honest question - what’s the point of all this change? At the end of the day, people are building web pages with these frameworks? John Carmack has an excellent article on static analysis (unrelated to this topic), but there’s this excellent quote: >It is important to say right up front that quality isn't everything, and acknowledging it isn't some sort of moral failing. Value is what you are trying to produce, and quality is only one aspect of it, intermixed with cost, features, and other factors. These JS frameworks and build tools provide far more than just code quality, but what all benefits are they providing that outweigh the cost of, “here is XYZ that you must now figure out, and before you can figure out XYZ, you need to learn A, B, and C”. Stated differently, what exactly is the value? Junior developers make this mistake and unfortunately so many more tenured developers as well. I can understand you want to use the shiny new thing. How often do you replace your toilet or kitchen sink though? Is it worth it? To me, the JS ecosystem has become to complex. Even if you’re building for Amazon or Google scale, you want to think twice about not only the shelf life of these various frameworks but also what are their dependencies, what are their failure modes, and at the end of the day, how are they giving you an ROI if you use the new X framework of the month or year CS Y.

DCoder 7y ago

TypeScript was and still is a very necessary addition over plain JS, but everything else you said is spot on. This ecosystem is very much a Red Queen's race, you have to learn all sorts of tooling that will be deprecated and forgotten in two years or less.

egeozcan 7y ago

None of the tools you mentioned are unsupported as of now, though. I recently updated a browserify based project from years ago to 16.3 in an afternoon and it just worked. I remember the days I was afraid to do npm update the dependencies, I was copy pasting build script configurations for new projects, I used to use code mods every other month to make huge refactors (and badly), packages disappearing, every project inventing how to manage state (not just react)... All of this is past for me. Yeah of course it's just a data point but there's the fact that you can start a complex web app project with one command these days and not care about core dependencies. I expect it'll go only better. Maybe it's me getting experienced but I certainly wasn't a beginner few years ago, not even close. I'd love to hear what kind of difficulties you are having with your projects though, it's very possible that I'm missing something.

siempreb 7y ago
> None of the tools you mentioned are unsupported as of now, though. I mean working as a professional, doing my next gig. Do you think I can still use my Grunt or Gulp skills there? The landscape is now again very different than it was a year ago. I cannot even code in ES6 anymore, all the jobs are TS and React Hooks at the moment. When I say I prefer JS over TS my colleagues think I'm not smart and skilled enough to understand the benefits of TS. There is not much choice unfortunately, independent of being supported or unsupported.
- wilsonrocks 7y ago
  React Hooks doesn't preclude ES6 though? Really, they're just functions that have some weirdness/magic about when you call them. I love them, but that's not really what this thread is about, of course:)
- egeozcan 7y ago
  It's not like you've been coding with Javascript and now you need to learn Haskell though. Companies love to sprinkle newest trends in their job ads with the technologies they used in their last 100 LOC pilot project and you discover in your first day that there are many big projects which use gulp, grunt and others with ES3, some without async support etc. I got a friend in Silicon Valley (I'm in Germany and here the attitude is more towards reliability and stability) and even there he got many interviews and a new job without listing many of the newest libraries/languages in professional capacity. Plus, I'd suggest you try Typescript with an open mind. It's amazing.
- reggieband 7y ago
  I happen to be in the interview gauntlet at the moment for full-stack JS type jobs so I hear what you are saying but it seems to cut both ways. Most places using React are expecting me to be familiar with hooks and everyone using Javascript is asking about familiarity with Typescript. But at the same time they genuinely seem impressed/surprised that I have been using async/await for over a year on my latest professional projects. I want to say this in a nice way but it is difficult. I feel Javascript developers suffer from an inferiority complex. It's like they need to feel what they are doing is "real code" or something. That seems to translate in this crazy pace of replacement of technologies. I think it gives the impression of innovation. To me it feels like an unsteady eco-system still trying to find its footing. The vacillation from OOP to functional and back again feels like uncertainty. From DIY systems like gulp to all-in-one systems like webpack. It's a sector full of people desperate to look like they know what they are doing while they act like they are still trying to figure it all out. All that being said, working in JS in 2018/2019 is significantly more pleasant than it ever was in the past. I find creating back-end Node.js services to be quick and easy and writing front-end systems using React bearable. Despite high volatility there is definite progress.

azangru 7y ago

> and now ES6 classes and all the rest are deprecated, because Dan Abramov had another idea for again a new design principle that's just less than a year old: Hooks. This is so off the mark it’s not even funny. - Dan did not develop the hooks api - he is also on record saying that people don’t need to re-write their components with hooks - class components have not been deprecated in React

siempreb 7y ago
It is indeed not funny, and you're off the mark as well: > Dan did not develop the hooks api I didn't say he developed it > he is also on record saying that people don’t need to re-write their components with hooks So? In my daily work I see it all the time. You think I have a say in that when I have a gig at company X? > class components have not been deprecated in React You've got a point there, indeed not officially deprecated, but in practice(again) at company X, you cannot do classes anymore.
- abacadaba 7y ago
  Annoying, but sometimes a better idea comes along. I think me and many others initial reaction to the hooks presentation was 'yeeaaaassss'. Still in mostly es6 class codebase of course, so haven't had a chance to do too much with them yet, but as long as they're not gonna break backwards compatibility, yes please.
- fourthark 7y ago
  If people won't even listen to the developers of the tools they use, and insist on "out with the old, in with the new" when those developers are pleading with them not to create extra work for themselves... Whose fault is that?
- vonseel 7y ago
  There are even linting rules to ban use of class components, IiRC. You’re not wrong. Hooks are being pushed HARD for new code.

vfc1 7y ago

The thing is, we don't need to learn Bazel either. We will just keep running the command "ng build", and internally the CLI will be using Bazel instead of Webpack, but that is transparent for us users. We only see the CLI commands on our end, and the Angular CLI internally will use whatever build tool is best for the job at a given time, and will keep evolving over time. It's such a relief that we don't need to learn build tools in the Angular ecosystem anymore and can focus on application development only.

ericmcer 7y ago
Sure... I have never heard of Bazel, but it sounds very black boxish (JS goes in bundles come out!). That is basically the same thing webpack promised in comparison to gulp/grunt. A lower config JS build tool, which is always great until it isn’t. At a certain maturity you will need to dig into your projects build tool.
- tashoecraft 7y ago
  Bazel is the open source version of googles interns build tooling. It’s not new, but using it outside of google is. It’s also not JavaScript specific, it’s completely language agnostic. You define the rules for building, and bazel will execute it. You can run your entire companies build system off of it.
  - joewrong 7y ago
    Sounds like Make
    - wwright 7y ago
      It covers a lot of the same ground, but IMO is much easier to use all around.
- vfc1 7y ago
  > At a certain maturity you will need to dig into your projects build tool The command "ng build" takes in typescript and produces optimized lazy-loaded bundles, and there won't be the need to customize that, there aren't a thousand ways to produce bundles after all, there is one optimal way for a given ecosystem, and it does not make sense for each project to reinvent a build system that all it does is transpile, concatenate, minify, compress, etc. like every other project. Any additional build steps besides bundling are usually very simple can often be done either via npm scripts, or a simple shell script. Can you give examples of things for which you would absolutely have to customize the build system?

peruvian 7y ago

While the JavaScript ecosystem is on the volatile side, learning new tools and frameworks every few years is just part of our job. Only in very boring tech jobs would you only have to learn new things maybe once every 5 years. I wouldn't really bother wasting time "mastering" something like Webpack or what replaces it - as the other commenter said we just end up using an abstraction over it anyway.

discreteevent 7y ago
The problem with changing tools to fend off boredom is that it has a very short lifespan. Pretty quickly your brain realizes that it's not learning anything fundamentally new and it protests. Hence fatigue. If possible, it's better to focus on the problem domain and try to make the best of that for entertainment. If not then maybe just accept that it's better to be a bit bored than fatigued.
jbverschoor 7y ago
It’s not learning a new frameworks and tools. It’s the fact that these tools are usually fragile, and quite frankly not very much new is in there. Also, what’s your goal? To learn new tools over and over again? Or to crate something that that people will use? You sound like a music “producer” (read - tech hobbiest) who keeps switching tools, synths, and hardware instead of just creating music.
- dpau 7y ago
  Yes, I don't even think the most important issue is that we as developers have js fatigue. The biggest issue is that we are developing web applications that are outdated before they are even released. Our software relies on thousands of dependencies that are constantly changing or even dying off. Updating an application that was built two or even just one year ago is often not a trivial task. So while the frameworks and tooling have thankfully improved, in general the cost of developing and maintaining an application seems to be much greater than in the past (e.g. PHP MVC app with some jQuery sprinkled in).
  - 7y ago

vfc1 7y ago

Nothing like that has happened in the Angular ecosystem, the API is stable for 3 years, and a pleasure to work with. I think this obsession with functions and the functional paradigm is counterproductive in the React ecosystem. Sometimes, the best way to represent something is a class. When you have some data and a series of closely related fucntions that modify the data and are highly related to the data, it's better to use a class. This hooks API thing is anything but functional, way too much magic. Its stateful programming diguised as functional.

csande17 7y ago
Indeed, hooks are pretty much the furthest thing from functional programming there is. In functional programming, functions can safely be called any number of times from anywhere in the program, and they'll always return the same result for the same arguments. Hooks, on the other hand, crash and burn at runtime if you call them outside a React component function, or in a different order or number from how you called them the first time your component was rendered.

kaycebasques 7y ago

> Are you very sure the peak was 3 years ago? Based on what? IMAO the mess only gets worse. No comment regarding the "peak" but 3 years ago is when the very influential How It Feels To Learn JavaScript In 2016 post came out. https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

tracer4201 7y ago

Honest question - what’s the point of all this change? At the end of the day, people are building web pages with these frameworks? John Carmack has an excellent article on static analysis (unrelated to this topic), but there’s this excellent quote: >It is important to say right up front that quality isn't everything, and acknowledging it isn't some sort of moral failing. Value is what you are trying to produce, and quality is only one aspect of it, intermixed with cost, features, and other factors. These JS frameworks and build tools provide far more than just code quality, but what all benefits are they providing that outweigh the cost of, “here is XYZ that you must now figure out, and before you can figure out XYZ, you need to learn A, B, and C”. Stated differently, what exactly is the value? Junior developers make this mistake and unfortunately so many more tenured developers as well. I can understand you want to use the shiny new thing. How often do you replace your toilet or kitchen sink though? Is it worth it? To me, the JS ecosystem has become to complex. Even if you’re building for Amazon or Google scale, you want to think twice about not only the shelf life of these various frameworks but also what are their dependencies, what are their failure modes, and at the end of the day, how are they giving you an ROI if you use the new X framework of the month or year CS Y.