12 ms·

Why I’m thankful for JavaScript fatigue

201 points by callumlocke 10y ago

dy 10y ago
One benefit often overlooked is that during high periods of churn in an industry (let's specify JavaScript fatigue as a symptom of rapid churn in Software Engineering for Web Applications). There are more opportunities to quickly speed up your career. Fresh problems call for new solutions and fresh eyes to work on those problems. The opposite of JS Fatigue is climbing the J2EE certification ladder - if we were all still building Struts/JSP apps then there would be no room for new ideas to flourish. I felt very similarly about Ruby on Rails in 2004, there was 4-6 years where someone early in their software development career to learn a stack, find work doing that tech and manage a team (exactly what me and several of my good friends did).
finchisko 10y ago
I wish I fully understand what people mean by javascript fatigue. I can translate fatigue to my language, but it still doesn't make sense.
- cwbrandsma 10y ago
  Fatigue can be translated to "feeling worn out and overwhelmed". Basically, so much change you feel obligated to keep up with that you want to quit. I feel this a bit, there was a time when I could keep up with the changes going on in Javascript, but was overwhelmed by the changes happening in C# and Java (which for a time were going fast and furious). Now I'm ok with C# and Java...but Javascript is going berserk. It comes and goes.
- Qwertystop 10y ago
  New frameworks keep being made, becoming extremely popular, and then being dropped for the next new framework despite that they often do basically the same thing in roughly the same way. Some people are getting tired of this.
- finchisko 10y ago
  Thank you guys for explanation. I had feeling that it must be the thing you've described, but was not sure. I was missing js fatigue of what (context). To give example: js fatigue of new frameworks, js fatigue of constant changes... Anyway now I understand. PS: I don't feel js fatigue of any kind and actually like the pace js is progressing. I just don't jump on hype train anymore. Rather wait till things settle and prove their existence.
- dexwiz 10y ago
  The fatigue comes from having to constantly keep up with JavaScript and everything new. 5 years ago building JavaScript page was straight forward. Most of the time you would include JQuery from a CDN, and code in a server side template. If you were really serious, you used something like Backbone Or Ember (both very new). But the options were limited. JavaScript was often limited to AJAX requests, a modal or two, and some JQuery plugins. Very few people were "JavaScript Developers." They wrote JS for their webpages and Ruby/Python/Java/Whatever for everything else. But NodeJS and ES5 broke open the floodgates for JavaScript Development by elevating Javascript from something only seen in a <script> tag to a fullstack language. With that came a surge of new libraries, frameworks, methodologies, and opinions. It's exciting when a community grows so fast and puts out so much. Many old Javascript patterns and styless were declare obsolete and new ones were created. A new framework and stack seemed to come out every month. Suddenly Javascript needed build scripts and a pipeline. Grunt came along to solve that problem. Which was replaced by Gulp. Which was replaced by npm scripts. And now yarn? This rapid iteration of technologies appeared all across the Javascript ecosystem. Backbone, Angular, React, Vue, Angular 2. Flux, MobX, Redux. But these switches are as much a change in fashion than real improvements. But either way, the change takes effort to learn and implement. It turns out learning a new framework, library, pattern every 6 months is tiring. Its fun to learn something new. But having to constantly be learning, and at such a high rate, takes a lot of effort. That is the fatigue. The fatigue of every time you open up HN, there is some new JS library that will replace whatever you are using now. And if you don't switch, you are an idiot using old technology. Or at least the community makes you feel that way.
  - duderific 10y ago
    That was a really great writeup of the issue, thanks for that.
- dceddia 10y ago
  The term "JavaScript Fatigue" came out of this post from about a year ago: https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4 https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...
wnevets 10y ago
Precisely my feelings about the fake problem of JavaScript fatigue, glad to see it finally make the front page of HN.
- samtho 10y ago
  > fake problem of JavaScript fatigue Can you elaborate why you called the problem fake? Not disagreeing, genuinely curious as to why you called it that.
  - wnevets 10y ago
    Its really just an excuse for people who don't like JS to complain about JS being popular. They honestly hate the fact that JS is one of the most popular languages in the world right now. You don't see a-lot of post making the frontpage of HN complaining about programing language fatigue, car fatigue or anything else with a lot of choice fatigue.
    - marcosdumay 10y ago
      Javascript is in the unique position where a lot of people (well, nearly everybody) that don't like it are forced to use it.
    - CaptSpify 10y ago
      I don't hate it because it's popular. I hate that it's encouraging sprawling, insecure, fragile design. It slows my computer to a crawl, and all just to make the web-page render worse than if it wasn't used. Sure, there are exceptions where JS is amazing, and absolutely necessary. But that's extremely rare, yet everyone thinks their news-site absolutely must have it.
  - deleted 10y ago
    [deleted]
karmajunkie 10y ago
I definitely appreciate the sentiment. Its true, the JS ecosystem has exploded and there's been a lot of shrapnel flying around for quite a while. It feels like the smoke is starting to clear and some different groups of consensus are starting to form about some generally reliable patterns and tools which makes things easier. For me, having learned web development in a time when it really was the smallest part of what could be considered development, the tooling and techniques are at once awesome and horrifying. :) The browser's transition from a much more useful version of Gopher to a platform in and of itself has created a lot of opportunities and challenges, and while JS still isn't my favorite language by a long shot, its gratifying to see its progress.
amelius 10y ago
> From this point going forward, no single human being is ever going to have a completely full grasp of every corner of JavaScript, CSS, and Web APIs. What does that mean for security, given that two secure systems combined can result in an insecure system?
- dennisnedry 10y ago
  Security is it's own separate issue. There are best practices that must be observed in all frameworks (preventing xss, sanitizing user data). Of course sometimes there are bugs, but the OSS community resolves those rather quickly.
- CalChris 10y ago
  In general, if I don't use something, if it's outside of my focus, that shouldn't harm security. As an example, given your two secure systems which can combine into an insecure system, if I don't use that second system I should be good. If I do, I better know their interactions. This argues for a small reliable toolset rather than having every contrivance in the HomeDepot center aisle on my belt. Not full stack, definitely not fool stack, just stack.
  - deleted 10y ago
    [deleted]
- bzbarsky 10y ago
  It means security is hard. And yes, we keep finding security issues (in web specs, not just in implementations) due to two different people designing two subsystems and not considering their interactions, or not even knowing about the existence of the other subsystem. Finding a sane solution to this problem would be wonderful; I haven't thought of one yet.
dennisnedry 10y ago
Agree with the author 100%. We want tons of new JS tools and frameworks out there so we can learn and evolve newer and faster ways of developing. I still remember when jQuery first came out and how earth-shattering that was. This inspired so many more devs to create better and easier to use tools.
- edblarney 10y ago
  Were JS and browsers to have been designed 'properly' (or better) with hindsight, 'jQuery' would have never needed to come into existence. JS evolution is perniciously different than the evolution of most other languages.
  - CoryG89 10y ago
    In hindsight of course it's obvious. jQuery should just have been built-in from the beginning! And all browsers should have always behaved the same and should never break compatibility with never versions. Then jQuery would never have needed to exist in the first place. Problem avoided.
fatbird 10y ago
I agree with his point, but I think he mischaracterizes JS fatigue. He's right that it's exhausting trying to keep up with all of it, and that's part of JS fatigue, but the other side is the endless hype machine that's internal to the tech community, where our media is an endless stream of "look at my new framework!" and "you're doing react wrong!" and "why functional is making a comeback!" We do it to ourselves not just by continually stuffing the buffet with every possible option, but also by making our community dialogue an endless infomercial, which has a big influence on trying to keep up with it all. We have conflicting desires to contribute and to self-promote, and the result is an aggressive bazaar in which you need to consciously filter out 90% of the noise so you don't get overwhelmed.
- finchisko 10y ago
  I agree with you. IMHO I see it as good thing. Maybe 6 projects bring so little innovation comparing to project they're trying to replace. But then somebody will take the good parts of all those projects and create something that is significantly better. Innovation does not grow on trees, there is slow and bumpy road to it. :-)
edblarney 10y ago
JS fatigue is not a fake problem, it's real and different from other forms of fatigue. The metaphor used in the article i.e. 'learning another language every 6 months' is not apt - because those are not 'new languages' and they are not 'new and critical parts of the landscape' for any specific vertical. If any one of those languages were to have the same degree of evolution as JS ... then 'fatigue' would also be an issue. JS has a pernicious problem for a few reasons: 1) The language is quirky, fragmented, there are still no 'agreed upon' approaches to do many things even outside the context of libraries. There are really no analogues to 'prototype' based languages, which possibly makes it great for some things, but it's not great for those wanting to use more classical ways of thinking about information organization. 2) Runtimes, particularly browser - are highly fragmented, and there's scant documentation. Safari docs for Mac/iOS are literally empty in some spots. 3) JS doesn't come with a lot of things 'baked in' to the language that most others support, so discovering those 'standard libs' has been a painful process. 4) Due to the limitations of the browser, we see a lot of churn in frameworks. Though there is some advantage to 'community participation' - the pernicious problem is most of the churn is not fully forward. It's 3 steps forward, 2 steps back, and a step sideways. There's a lot of time and investment in learning something new that won't exist in the future - that's costly. Learning Lambda's for Java 8 is probably worth investing in for Java programmers ... because Java 9 will surely use them as well. Taken as a whole - there is an enormous amount of inherent 'reducible complexity' in the JS ecosystem, which any JS developer intuitively senses. If someone were to have made up their mind about JS right from the start, and had come up with some good standard libs ... and the evolution of the language were to have been more 'version' and less 'pick and chose' (Es6 means something different in each environment) ... then the complaint would be valid. It is what it is ... but JS fatigue is a real thing.
- z3t4 10y ago
  one reason why JS is so popular is because there are no standard lib. There would be no nodejs etc.
  - cocktailpeanuts 10y ago
    node.js was built from scratch, in C, to resemble javascript syntax intentionally.
hackcrafter 10y ago
> Nobody is ever going to know everything there is to know about modern web architecture I think this is the root of the sentiment that is expressed as "JS fatigue" and bullet train rides etc. I'm torn though. On one hand, this is equivalent to saying: Nobody is ever going to know everything about an operating system and how a machine performs the operations we expression a high level language like, you know, C! The thing is, we still were able to teach the abstraction of the single-machine computation model that C is abstracting in a single semester to the point of making new coders _operational_. But I can't imagine trying to construct a course to teach "modern web architecture" in a single semester. On the flip side, a lone developer who can chose their battles wisely has more leverage to produce something of value today than was ever freaking possible, ever! I'm betting on the the new "OS" abstraction as cloud-native services (DB as a service, event streams as a service, mobile syncing as a service, heck, everything but your core logic as a service). But by it's nature this world is redundant, competitive, multi-vendor, fractal-specialized and I only see that trend increasing. So yes, one person will never know everything there is to know, the new skill will not be learning every framework, platform or service, but being able to grok the core nature and characteristics of your problem so you can apply the closest matching tool with the maximum leverage. Essentially, the new skill will be to optimize for laziness :)
- CoryG89 10y ago
  I am not sure I agree that optimizing for laziness will ever be a skill. But indeed, I am not sure it's possible to know everything there is to know about just about anything. How can you ever be sure there isn't still something left to discover? I am reminded of something I used to hear all the time: you learn something new every day.
  - hackcrafter 10y ago
    Ha! Yes, my shorted argument of "optimizing for laziness" doesn't sit right, but the core of it how much your choices matter in what you are _not_ building. - Cloud-based apps used to mean managing VMs, keeping kernels up to date, setting security settings on server configs. It doesn't have to[0] - Mobile dev used to mean compiling platform-specific code and shipping it to app-store review. It doesn't have to[1] - Storing state server-side used to mean running your own DBs and worrying about their persistence and multi-host-scaling. Don't even need a reference here since there a so many choices. [0] https://www.ibm.com/developerworks/cloud/library/cl-bluemixfoundry/ https://www.ibm.com/developerworks/cloud/library/cl-bluemixf... [1] https://getexponent.com/ https://getexponent.com/
ysavir 10y ago
> It’s like walking into a restaurant and finding out that they have all your favorite dishes and every one of them is free and complaining about how long it’s going to take you to read over the menu and make up your mind about it. I suppose it's a matter of perspective. For me, it's more like walking into used car lot. Most of the cars have lost (or voided) their warranties. Some are certified pre-owned. That one in the corner looks nice, but I don't know how to drive stick, and am not really interested in learning. At least it's not a custom gear box, like this other one. I can look at the new car lot across the street, but I'm not sure I want to be the first to use one of those self-driving electric smart cars. It's neat, but I'd rather stick to proven standards, and gas stations are more common than charge stations, anyway. And I could probably get to where I'm going with just a bicycle.
- Touche 10y ago
  Also, the problem with big chain restaurants with a thousand things on the menu is not reading the menu, it's that none of it is very good. Much rather eat at a small restaurant with 5 things on the menu that are all excellent.
  - ksherlock 10y ago
    And the other problem is there are 23 kinds of bespoke artisanal ravioli and maybe it was handmade by a Michelin chef or maybe it's from a bootcamp graduate that spent two weeks learning how to blog, star things on pinterest, and require('can-of-chef-boyardee')
    - strictnein 10y ago
      You gave me false hope. npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/can-of-chef-boyardee
  - bobbytherobot 10y ago
    I don't think comparing an over abundance of JavaScript libraries with a big chain restaurant. It would be more like going to a huge open air market with hundreds of stalls each serving a few dishes. The dishes range from amazing to simply mediocre. You have simple three ingredient dishes to dishes that require weeks of preparation. Some are served modestly while other are delivered on a spinning plate by a server on roller skates singing the latest pop songs.
jjcm 10y ago
I'm a prototyper, so people often come to me first to vet new ideas. Often times this means implementing a feature on an existing product platform. When I started doing this 5 years ago, I was working with a new language every month. It was ruby one day, C# the next, and I'd go to sleep every night praying next week wouldn't be PHP. These days everyone is using javascript. In the last year I've done countless javascript projects and one project in java. I can't tell you how refreshing it is to not have to brush up on syntax and install a suite of tools every time I want to work on a new product. Nowadays it's just clone the repo, do a npm install, and you're up and running for the most part. It's lovely.
indubitably 10y ago
Pretty rich coming from the complainer-in-chief of JS, the guy who advises not employing people who don't happen to agree with his personal take on how JS should be written.
peterkelly 10y ago
JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month. This is why universities teach computer science rather than just programming. Learn about programming language paradigms - procedural, object-oriented, functional, etc; the language itself doesn't matter. Learn about relational databases. Distributed systems. Computer architecture. State machines. Formal grammars. Language translators/compilers. Data structures. Algorithms. Computational complexity/big O notation. That's the theory side of things. Understand Unix, version control systems, and how to log into and administer remote systems. Learn about what TCP/IP is and how higher-level protocols like HTTP relate to it. Ensure you're able to write a program in at least one language that can talk to at least one type of database, and present at least some sort of user interface. That's the practice side of things. These things will pretty much set you up for life. By themselves they're only a start, but you can pick up the rest as you go along, lazy evaluating any expertise you need with specific technologies as you go along. As far as front-end web development is concerned, all you really need to know is JavaScript, HTML, CSS, and the DOM. Pick an abstraction layer on top of that if you feel it helps you, but don't feel that you need to know about every framework out there, because new ones are being generated faster than you can learn about them. And yes, becoming good at this takes many years. But ensure that whenever you're investing time to learn, it's something that will last.
- traverseda 10y ago
  I feel I've done that. Started as a sys-admin, moved to programming, all that. The problem is that more and more my clients are looking for live data, push notifications, video-streaming, etc. Sure, I can throw together really solid "classic" websites all day long, with facebook integrations and payment processing and whatever else. But more of my stuff is requiring reliable well-documented javascript. And since I've got to install at least 3 different tools to get imports working well, that's always going to be a pain. I shouldn't have to run my code through 3 different preprosessors to get common language features. I hope asm.js solves some of these problems.
- mrec 10y ago
  The whole tone of this post feels a bit sketchy to me. Not everyone gets 100% control over what they have to learn. > JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month. Or those who work for (or with) those whose priorities are poorly chosen, and who don't have a veto. I've largely avoided having to deal with JS in its recent pathological era, and I'm very very thankful for that. My attitude toward those less fortunate in this regard is sympathy, not contempt.
holydude 10y ago
The fatigue is not with what to pick and what to learn / master. The problem is when you go for an interview and other not-so-brilliant people start asking very concrete questions related to whatever-hipster-framework-component they heavily rely upon. You might say that you would not work with such people but in reality you can't really choose. 95% companies / people are like that.
caseysoftware 10y ago
I think the bigger problem is that we, as developers, don't appreciate risk and how to mitigate it. We always want to play with the latest and greatest tools, technology, approaches, etc, etc. My advice to the teams I mentor is choose at most 1-2 risky areas and reduce/eliminate risk everywhere else. If you have a new idea with a new team, stick with established tools. If you have a well-gelled team with understanding of the space, experiment with tools or approaches. When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, success is unlikely at best.
- jaredsohn 10y ago
  >When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, failure is unlikely at best. Should this be success is unlikely at best?
  - caseysoftware 10y ago
    Ha, thanks & corrected. :)
draw_down 10y ago
You can't learn every library or every tool but you can learn how the language actually works. For example, if you think JS has floats and integers, you have some reading to do. If you think "array" is a type, take heart, because you can learn why that's not correct. If you can't decide whether to use Ember or Angular, maybe you can grasp how closures work. Before React and Redux and Gulp and whatever else, understand how the language works. Pretty please.
amelius 10y ago
I think I'm having a case of "JavaScript fatigue fatigue".
- paulddraper 10y ago
  The next step is not far away.
rootlocus 10y ago
> and every other exciting, scary, new, hipster Haskell thing that exists in the web dev world today. Ha ha! A fatigued JS developer complaining about hipster Haskell things!
strictnein 10y ago
> "From this point going forward, no single human being is ever going to have a completely full grasp of every corner of JavaScript, CSS, and Web APIs" This. Reading the comments at HN and other places gives you the impression that there are people who do know everything, but that's not the case. There's just lots of technical people here who are experts in various fields, so there's always experts to comment on things.
throwaway23421 10y ago
> gifts fuck this dude. typical contractor that doesn't have to maintain unsupported backbone.js based applications. just shits something out using the latest technology then fucks off
Kequc 10y ago
The problem is very accurately described as people trying to use every framework and every library all at once. Too many developers are neglecting their knowledge of the base language. JavaScript has become incredible in recent years, but you'll still find new projects being built incorporating jquery. I have tried react redux and seriously people, after all your badgering and all of your carrying on. I still prefer vanilla es2015+ with typescript. I can do everything you can do sans MBs of extraneous client side code. I also have more control. Use your tools for what they are useful for, stick close to the metal. You'll save yourself tons of grief.
- bjacobel 10y ago
  React + ReactDOM + Redux is a little over 50kb minified and gzipped. I'm not saying that's nothing, but "MBs" is a strawman.
- jyriand 10y ago
  Using vanilla js becomes a problem once you start building something bigger than a simple web page. Eventually you will end up with your own framework and new developers still have to understand how it works etc. It's totally fine if you are expert js developer and now how to structure and design your code for maintainability. But few hacks here and there, and you might end up with a mess.
curried_haskell 10y ago
Haskell programmers are hipsters now?
- Finnucane 10y ago
  Well, they're the ones juggling while riding backwards on a unicycle.
- paulddraper 10y ago
  Hipsters for decades...they must have been the original hipsters.
vmorgulis 10y ago
> I recently built an app prototype in a couple days using nothing but vanilla JS and the DOM. I was literally two days in before I installed a single non-dev dependency. Guess what? It was fine. IMHO a good strategy to reduce the cognitive load (and limit dependencies).
- nkkar 10y ago
  I loved this admission. There is a lot of awesome, powerful, fancy stuff out there today, but you can get a lot done with the vanilla approach. I was introduced to JS back when AJAX was 'blowing up', and today still prefer to hack quick ideas w/ at most a jQuery import
makecheck 10y ago
In some respects the problem of “too many libraries” is the same issue we have with news headlines, etc.: too much going on, and not enough value placed on curating. Right now everyone just wants to build things full-time. As an industry, it would make a lot of sense to have expert developers who spend some non-trivial amount of their time just on curating: writing down what actually works, what doesn’t, etc. Maybe a “stack overflow” for software packages. And after awhile, it should become expected that you consult those curated lists first, every time before you build anything else.
throwbsidbdk 10y ago
I see the proliferation of JavaScript tools as a massive failure of the vanilla js standard library and ECMA. Most of the stuff out there just rebuilds basic language features that would be standard in other languages. We wouldn't need node, npm, typescript, angular, react, web pack, or most of the bazillions of libraries out there if vanilla js had reasonable defaults. It's causing horrid fragmentations probably won't go away until js is replaced maybe 5 years down the road. The best we can hope for is a c++ style solution. A new language that's basically a massive preprocessor on top of the original that fixes as much as possible. My hope is in typescript for now
- nickthemagicman 10y ago
  Man so much this. Hope Web Assembly is good!
- throwbsidbdk 10y ago
  I think node is the funniest example. "Yay we can run js on the server now! This is the future!" But wait, what other language can't you run on the server? I can't think of a popular language in existence before js to take so damn long just to have a web interface. It took js ten years! Even rust has a web server and it just hit 1.0. Oh and node is still single threaded, something horrific for servers that usually have 16+ cores.
  - icedchai 10y ago
    You could run Javascript on the server back in 1996. Netscape Enterprise Server supported Javascript as a server-side language, similar to VBScript or PHP. They called it Livewire.
  - loftyal 10y ago
    Complete lack of understanding of Node
MrBra 10y ago
This article seems to me a self reassuring post written by the author after he suffered himself the JS fatigue.
kazinator 10y ago
It's very hard to know everything. I made a programming language and I'd be screwed without the manual to refer to. Recently I was utterly surprised by something that was implemented ("you can do that?"). What was it ... aha, I remember: introspection over exception handling sites. The ability to just get a list of the frames through an API, and then directly pick one and jump to it (regardless of whether it catches the type of exception being passed to it that way).
vldr 10y ago
I picked EmberJS because of javascript fatigue - it makes most choices for me and gives me some guarantee that it will work together. But even that fails in practice: sourcemaps don't work properly so you don't get to debug your original ES6 code and more issues like that. Meanwhile there's no clear focus on where the framework is really going (routable components? working pods in ember-cli?, etc)
somecallitblues 10y ago
Could some of this fatigue be due to to JS being so damn hard to troubleshoot? I'm still struggling with troubleshooting JS after years of using it on and off. I still console log everything and keep refreshing the page. Is there a more sane way of doing it?
somecallitblues 10y ago
Could some of this fatigue be due to to JS being so damn hard to troubleshoot? I'm still struggling with troubleshooting JS after years of using it on and off. I still console log everything and keep refreshing the page. Is there a more sane way of doing it?

201 points by callumlocke 10y ago

dy 10y ago

One benefit often overlooked is that during high periods of churn in an industry (let's specify JavaScript fatigue as a symptom of rapid churn in Software Engineering for Web Applications). There are more opportunities to quickly speed up your career. Fresh problems call for new solutions and fresh eyes to work on those problems. The opposite of JS Fatigue is climbing the J2EE certification ladder - if we were all still building Struts/JSP apps then there would be no room for new ideas to flourish. I felt very similarly about Ruby on Rails in 2004, there was 4-6 years where someone early in their software development career to learn a stack, find work doing that tech and manage a team (exactly what me and several of my good friends did).

finchisko 10y ago

I wish I fully understand what people mean by javascript fatigue. I can translate fatigue to my language, but it still doesn't make sense.

cwbrandsma 10y ago
Fatigue can be translated to "feeling worn out and overwhelmed". Basically, so much change you feel obligated to keep up with that you want to quit. I feel this a bit, there was a time when I could keep up with the changes going on in Javascript, but was overwhelmed by the changes happening in C# and Java (which for a time were going fast and furious). Now I'm ok with C# and Java...but Javascript is going berserk. It comes and goes.
Qwertystop 10y ago
New frameworks keep being made, becoming extremely popular, and then being dropped for the next new framework despite that they often do basically the same thing in roughly the same way. Some people are getting tired of this.
finchisko 10y ago
Thank you guys for explanation. I had feeling that it must be the thing you've described, but was not sure. I was missing js fatigue of what (context). To give example: js fatigue of new frameworks, js fatigue of constant changes... Anyway now I understand. PS: I don't feel js fatigue of any kind and actually like the pace js is progressing. I just don't jump on hype train anymore. Rather wait till things settle and prove their existence.
dexwiz 10y ago
The fatigue comes from having to constantly keep up with JavaScript and everything new. 5 years ago building JavaScript page was straight forward. Most of the time you would include JQuery from a CDN, and code in a server side template. If you were really serious, you used something like Backbone Or Ember (both very new). But the options were limited. JavaScript was often limited to AJAX requests, a modal or two, and some JQuery plugins. Very few people were "JavaScript Developers." They wrote JS for their webpages and Ruby/Python/Java/Whatever for everything else. But NodeJS and ES5 broke open the floodgates for JavaScript Development by elevating Javascript from something only seen in a <script> tag to a fullstack language. With that came a surge of new libraries, frameworks, methodologies, and opinions. It's exciting when a community grows so fast and puts out so much. Many old Javascript patterns and styless were declare obsolete and new ones were created. A new framework and stack seemed to come out every month. Suddenly Javascript needed build scripts and a pipeline. Grunt came along to solve that problem. Which was replaced by Gulp. Which was replaced by npm scripts. And now yarn? This rapid iteration of technologies appeared all across the Javascript ecosystem. Backbone, Angular, React, Vue, Angular 2. Flux, MobX, Redux. But these switches are as much a change in fashion than real improvements. But either way, the change takes effort to learn and implement. It turns out learning a new framework, library, pattern every 6 months is tiring. Its fun to learn something new. But having to constantly be learning, and at such a high rate, takes a lot of effort. That is the fatigue. The fatigue of every time you open up HN, there is some new JS library that will replace whatever you are using now. And if you don't switch, you are an idiot using old technology. Or at least the community makes you feel that way.
- duderific 10y ago
  That was a really great writeup of the issue, thanks for that.
dceddia 10y ago
The term "JavaScript Fatigue" came out of this post from about a year ago: https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4 https://medium.com/@ericclemmons/javascript-fatigue-48d4011b...

wnevets 10y ago

Precisely my feelings about the fake problem of JavaScript fatigue, glad to see it finally make the front page of HN.

samtho 10y ago
> fake problem of JavaScript fatigue Can you elaborate why you called the problem fake? Not disagreeing, genuinely curious as to why you called it that.
- wnevets 10y ago
  Its really just an excuse for people who don't like JS to complain about JS being popular. They honestly hate the fact that JS is one of the most popular languages in the world right now. You don't see a-lot of post making the frontpage of HN complaining about programing language fatigue, car fatigue or anything else with a lot of choice fatigue.
  - marcosdumay 10y ago
    Javascript is in the unique position where a lot of people (well, nearly everybody) that don't like it are forced to use it.
  - CaptSpify 10y ago
    I don't hate it because it's popular. I hate that it's encouraging sprawling, insecure, fragile design. It slows my computer to a crawl, and all just to make the web-page render worse than if it wasn't used. Sure, there are exceptions where JS is amazing, and absolutely necessary. But that's extremely rare, yet everyone thinks their news-site absolutely must have it.
- deleted 10y ago
  [deleted]

karmajunkie 10y ago

I definitely appreciate the sentiment. Its true, the JS ecosystem has exploded and there's been a lot of shrapnel flying around for quite a while. It feels like the smoke is starting to clear and some different groups of consensus are starting to form about some generally reliable patterns and tools which makes things easier. For me, having learned web development in a time when it really was the smallest part of what could be considered development, the tooling and techniques are at once awesome and horrifying. :) The browser's transition from a much more useful version of Gopher to a platform in and of itself has created a lot of opportunities and challenges, and while JS still isn't my favorite language by a long shot, its gratifying to see its progress.

amelius 10y ago

> From this point going forward, no single human being is ever going to have a completely full grasp of every corner of JavaScript, CSS, and Web APIs. What does that mean for security, given that two secure systems combined can result in an insecure system?

dennisnedry 10y ago
Security is it's own separate issue. There are best practices that must be observed in all frameworks (preventing xss, sanitizing user data). Of course sometimes there are bugs, but the OSS community resolves those rather quickly.
CalChris 10y ago
In general, if I don't use something, if it's outside of my focus, that shouldn't harm security. As an example, given your two secure systems which can combine into an insecure system, if I don't use that second system I should be good. If I do, I better know their interactions. This argues for a small reliable toolset rather than having every contrivance in the HomeDepot center aisle on my belt. Not full stack, definitely not fool stack, just stack.
- deleted 10y ago
  [deleted]
bzbarsky 10y ago
It means security is hard. And yes, we keep finding security issues (in web specs, not just in implementations) due to two different people designing two subsystems and not considering their interactions, or not even knowing about the existence of the other subsystem. Finding a sane solution to this problem would be wonderful; I haven't thought of one yet.

dennisnedry 10y ago

Agree with the author 100%. We want tons of new JS tools and frameworks out there so we can learn and evolve newer and faster ways of developing. I still remember when jQuery first came out and how earth-shattering that was. This inspired so many more devs to create better and easier to use tools.

edblarney 10y ago
Were JS and browsers to have been designed 'properly' (or better) with hindsight, 'jQuery' would have never needed to come into existence. JS evolution is perniciously different than the evolution of most other languages.
- CoryG89 10y ago
  In hindsight of course it's obvious. jQuery should just have been built-in from the beginning! And all browsers should have always behaved the same and should never break compatibility with never versions. Then jQuery would never have needed to exist in the first place. Problem avoided.

fatbird 10y ago

I agree with his point, but I think he mischaracterizes JS fatigue. He's right that it's exhausting trying to keep up with all of it, and that's part of JS fatigue, but the other side is the endless hype machine that's internal to the tech community, where our media is an endless stream of "look at my new framework!" and "you're doing react wrong!" and "why functional is making a comeback!" We do it to ourselves not just by continually stuffing the buffet with every possible option, but also by making our community dialogue an endless infomercial, which has a big influence on trying to keep up with it all. We have conflicting desires to contribute and to self-promote, and the result is an aggressive bazaar in which you need to consciously filter out 90% of the noise so you don't get overwhelmed.

finchisko 10y ago
I agree with you. IMHO I see it as good thing. Maybe 6 projects bring so little innovation comparing to project they're trying to replace. But then somebody will take the good parts of all those projects and create something that is significantly better. Innovation does not grow on trees, there is slow and bumpy road to it. :-)

edblarney 10y ago

JS fatigue is not a fake problem, it's real and different from other forms of fatigue. The metaphor used in the article i.e. 'learning another language every 6 months' is not apt - because those are not 'new languages' and they are not 'new and critical parts of the landscape' for any specific vertical. If any one of those languages were to have the same degree of evolution as JS ... then 'fatigue' would also be an issue. JS has a pernicious problem for a few reasons: 1) The language is quirky, fragmented, there are still no 'agreed upon' approaches to do many things even outside the context of libraries. There are really no analogues to 'prototype' based languages, which possibly makes it great for some things, but it's not great for those wanting to use more classical ways of thinking about information organization. 2) Runtimes, particularly browser - are highly fragmented, and there's scant documentation. Safari docs for Mac/iOS are literally empty in some spots. 3) JS doesn't come with a lot of things 'baked in' to the language that most others support, so discovering those 'standard libs' has been a painful process. 4) Due to the limitations of the browser, we see a lot of churn in frameworks. Though there is some advantage to 'community participation' - the pernicious problem is most of the churn is not fully forward. It's 3 steps forward, 2 steps back, and a step sideways. There's a lot of time and investment in learning something new that won't exist in the future - that's costly. Learning Lambda's for Java 8 is probably worth investing in for Java programmers ... because Java 9 will surely use them as well. Taken as a whole - there is an enormous amount of inherent 'reducible complexity' in the JS ecosystem, which any JS developer intuitively senses. If someone were to have made up their mind about JS right from the start, and had come up with some good standard libs ... and the evolution of the language were to have been more 'version' and less 'pick and chose' (Es6 means something different in each environment) ... then the complaint would be valid. It is what it is ... but JS fatigue is a real thing.

z3t4 10y ago
one reason why JS is so popular is because there are no standard lib. There would be no nodejs etc.
- cocktailpeanuts 10y ago
  node.js was built from scratch, in C, to resemble javascript syntax intentionally.

hackcrafter 10y ago

> Nobody is ever going to know everything there is to know about modern web architecture I think this is the root of the sentiment that is expressed as "JS fatigue" and bullet train rides etc. I'm torn though. On one hand, this is equivalent to saying: Nobody is ever going to know everything about an operating system and how a machine performs the operations we expression a high level language like, you know, C! The thing is, we still were able to teach the abstraction of the single-machine computation model that C is abstracting in a single semester to the point of making new coders _operational_. But I can't imagine trying to construct a course to teach "modern web architecture" in a single semester. On the flip side, a lone developer who can chose their battles wisely has more leverage to produce something of value today than was ever freaking possible, ever! I'm betting on the the new "OS" abstraction as cloud-native services (DB as a service, event streams as a service, mobile syncing as a service, heck, everything but your core logic as a service). But by it's nature this world is redundant, competitive, multi-vendor, fractal-specialized and I only see that trend increasing. So yes, one person will never know everything there is to know, the new skill will not be learning every framework, platform or service, but being able to grok the core nature and characteristics of your problem so you can apply the closest matching tool with the maximum leverage. Essentially, the new skill will be to optimize for laziness :)

CoryG89 10y ago
I am not sure I agree that optimizing for laziness will ever be a skill. But indeed, I am not sure it's possible to know everything there is to know about just about anything. How can you ever be sure there isn't still something left to discover? I am reminded of something I used to hear all the time: you learn something new every day.
- hackcrafter 10y ago
  Ha! Yes, my shorted argument of "optimizing for laziness" doesn't sit right, but the core of it how much your choices matter in what you are _not_ building. - Cloud-based apps used to mean managing VMs, keeping kernels up to date, setting security settings on server configs. It doesn't have to[0] - Mobile dev used to mean compiling platform-specific code and shipping it to app-store review. It doesn't have to[1] - Storing state server-side used to mean running your own DBs and worrying about their persistence and multi-host-scaling. Don't even need a reference here since there a so many choices. [0] https://www.ibm.com/developerworks/cloud/library/cl-bluemixfoundry/ https://www.ibm.com/developerworks/cloud/library/cl-bluemixf... [1] https://getexponent.com/ https://getexponent.com/

ysavir 10y ago

> It’s like walking into a restaurant and finding out that they have all your favorite dishes and every one of them is free and complaining about how long it’s going to take you to read over the menu and make up your mind about it. I suppose it's a matter of perspective. For me, it's more like walking into used car lot. Most of the cars have lost (or voided) their warranties. Some are certified pre-owned. That one in the corner looks nice, but I don't know how to drive stick, and am not really interested in learning. At least it's not a custom gear box, like this other one. I can look at the new car lot across the street, but I'm not sure I want to be the first to use one of those self-driving electric smart cars. It's neat, but I'd rather stick to proven standards, and gas stations are more common than charge stations, anyway. And I could probably get to where I'm going with just a bicycle.

Touche 10y ago
Also, the problem with big chain restaurants with a thousand things on the menu is not reading the menu, it's that none of it is very good. Much rather eat at a small restaurant with 5 things on the menu that are all excellent.
- ksherlock 10y ago
  And the other problem is there are 23 kinds of bespoke artisanal ravioli and maybe it was handmade by a Michelin chef or maybe it's from a bootcamp graduate that spent two weeks learning how to blog, star things on pinterest, and require('can-of-chef-boyardee')
  - strictnein 10y ago
    You gave me false hope. npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/can-of-chef-boyardee
- bobbytherobot 10y ago
  I don't think comparing an over abundance of JavaScript libraries with a big chain restaurant. It would be more like going to a huge open air market with hundreds of stalls each serving a few dishes. The dishes range from amazing to simply mediocre. You have simple three ingredient dishes to dishes that require weeks of preparation. Some are served modestly while other are delivered on a spinning plate by a server on roller skates singing the latest pop songs.

jjcm 10y ago

I'm a prototyper, so people often come to me first to vet new ideas. Often times this means implementing a feature on an existing product platform. When I started doing this 5 years ago, I was working with a new language every month. It was ruby one day, C# the next, and I'd go to sleep every night praying next week wouldn't be PHP. These days everyone is using javascript. In the last year I've done countless javascript projects and one project in java. I can't tell you how refreshing it is to not have to brush up on syntax and install a suite of tools every time I want to work on a new product. Nowadays it's just clone the repo, do a npm install, and you're up and running for the most part. It's lovely.

indubitably 10y ago

Pretty rich coming from the complainer-in-chief of JS, the guy who advises not employing people who don't happen to agree with his personal take on how JS should be written.

peterkelly 10y ago

JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month. This is why universities teach computer science rather than just programming. Learn about programming language paradigms - procedural, object-oriented, functional, etc; the language itself doesn't matter. Learn about relational databases. Distributed systems. Computer architecture. State machines. Formal grammars. Language translators/compilers. Data structures. Algorithms. Computational complexity/big O notation. That's the theory side of things. Understand Unix, version control systems, and how to log into and administer remote systems. Learn about what TCP/IP is and how higher-level protocols like HTTP relate to it. Ensure you're able to write a program in at least one language that can talk to at least one type of database, and present at least some sort of user interface. That's the practice side of things. These things will pretty much set you up for life. By themselves they're only a start, but you can pick up the rest as you go along, lazy evaluating any expertise you need with specific technologies as you go along. As far as front-end web development is concerned, all you really need to know is JavaScript, HTML, CSS, and the DOM. Pick an abstraction layer on top of that if you feel it helps you, but don't feel that you need to know about every framework out there, because new ones are being generated faster than you can learn about them. And yes, becoming good at this takes many years. But ensure that whenever you're investing time to learn, it's something that will last.

traverseda 10y ago
I feel I've done that. Started as a sys-admin, moved to programming, all that. The problem is that more and more my clients are looking for live data, push notifications, video-streaming, etc. Sure, I can throw together really solid "classic" websites all day long, with facebook integrations and payment processing and whatever else. But more of my stuff is requiring reliable well-documented javascript. And since I've got to install at least 3 different tools to get imports working well, that's always going to be a pain. I shouldn't have to run my code through 3 different preprosessors to get common language features. I hope asm.js solves some of these problems.
mrec 10y ago
The whole tone of this post feels a bit sketchy to me. Not everyone gets 100% control over what they have to learn. > JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month. Or those who work for (or with) those whose priorities are poorly chosen, and who don't have a veto. I've largely avoided having to deal with JS in its recent pathological era, and I'm very very thankful for that. My attitude toward those less fortunate in this regard is sympathy, not contempt.

holydude 10y ago

The fatigue is not with what to pick and what to learn / master. The problem is when you go for an interview and other not-so-brilliant people start asking very concrete questions related to whatever-hipster-framework-component they heavily rely upon. You might say that you would not work with such people but in reality you can't really choose. 95% companies / people are like that.

caseysoftware 10y ago

I think the bigger problem is that we, as developers, don't appreciate risk and how to mitigate it. We always want to play with the latest and greatest tools, technology, approaches, etc, etc. My advice to the teams I mentor is choose at most 1-2 risky areas and reduce/eliminate risk everywhere else. If you have a new idea with a new team, stick with established tools. If you have a well-gelled team with understanding of the space, experiment with tools or approaches. When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, success is unlikely at best.

jaredsohn 10y ago
>When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, failure is unlikely at best. Should this be success is unlikely at best?
- caseysoftware 10y ago
  Ha, thanks & corrected. :)

draw_down 10y ago

You can't learn every library or every tool but you can learn how the language actually works. For example, if you think JS has floats and integers, you have some reading to do. If you think "array" is a type, take heart, because you can learn why that's not correct. If you can't decide whether to use Ember or Angular, maybe you can grasp how closures work. Before React and Redux and Gulp and whatever else, understand how the language works. Pretty please.

amelius 10y ago

I think I'm having a case of "JavaScript fatigue fatigue".

paulddraper 10y ago
The next step is not far away.

rootlocus 10y ago

> and every other exciting, scary, new, hipster Haskell thing that exists in the web dev world today. Ha ha! A fatigued JS developer complaining about hipster Haskell things!

strictnein 10y ago

> "From this point going forward, no single human being is ever going to have a completely full grasp of every corner of JavaScript, CSS, and Web APIs" This. Reading the comments at HN and other places gives you the impression that there are people who do know everything, but that's not the case. There's just lots of technical people here who are experts in various fields, so there's always experts to comment on things.

throwaway23421 10y ago

> gifts fuck this dude. typical contractor that doesn't have to maintain unsupported backbone.js based applications. just shits something out using the latest technology then fucks off

Kequc 10y ago

The problem is very accurately described as people trying to use every framework and every library all at once. Too many developers are neglecting their knowledge of the base language. JavaScript has become incredible in recent years, but you'll still find new projects being built incorporating jquery. I have tried react redux and seriously people, after all your badgering and all of your carrying on. I still prefer vanilla es2015+ with typescript. I can do everything you can do sans MBs of extraneous client side code. I also have more control. Use your tools for what they are useful for, stick close to the metal. You'll save yourself tons of grief.

bjacobel 10y ago
React + ReactDOM + Redux is a little over 50kb minified and gzipped. I'm not saying that's nothing, but "MBs" is a strawman.
jyriand 10y ago
Using vanilla js becomes a problem once you start building something bigger than a simple web page. Eventually you will end up with your own framework and new developers still have to understand how it works etc. It's totally fine if you are expert js developer and now how to structure and design your code for maintainability. But few hacks here and there, and you might end up with a mess.

curried_haskell 10y ago

Haskell programmers are hipsters now?

Finnucane 10y ago
Well, they're the ones juggling while riding backwards on a unicycle.
paulddraper 10y ago
Hipsters for decades...they must have been the original hipsters.

vmorgulis 10y ago

> I recently built an app prototype in a couple days using nothing but vanilla JS and the DOM. I was literally two days in before I installed a single non-dev dependency. Guess what? It was fine. IMHO a good strategy to reduce the cognitive load (and limit dependencies).

nkkar 10y ago
I loved this admission. There is a lot of awesome, powerful, fancy stuff out there today, but you can get a lot done with the vanilla approach. I was introduced to JS back when AJAX was 'blowing up', and today still prefer to hack quick ideas w/ at most a jQuery import

makecheck 10y ago

In some respects the problem of “too many libraries” is the same issue we have with news headlines, etc.: too much going on, and not enough value placed on curating. Right now everyone just wants to build things full-time. As an industry, it would make a lot of sense to have expert developers who spend some non-trivial amount of their time just on curating: writing down what actually works, what doesn’t, etc. Maybe a “stack overflow” for software packages. And after awhile, it should become expected that you consult those curated lists first, every time before you build anything else.

throwbsidbdk 10y ago

I see the proliferation of JavaScript tools as a massive failure of the vanilla js standard library and ECMA. Most of the stuff out there just rebuilds basic language features that would be standard in other languages. We wouldn't need node, npm, typescript, angular, react, web pack, or most of the bazillions of libraries out there if vanilla js had reasonable defaults. It's causing horrid fragmentations probably won't go away until js is replaced maybe 5 years down the road. The best we can hope for is a c++ style solution. A new language that's basically a massive preprocessor on top of the original that fixes as much as possible. My hope is in typescript for now

nickthemagicman 10y ago
Man so much this. Hope Web Assembly is good!
throwbsidbdk 10y ago
I think node is the funniest example. "Yay we can run js on the server now! This is the future!" But wait, what other language can't you run on the server? I can't think of a popular language in existence before js to take so damn long just to have a web interface. It took js ten years! Even rust has a web server and it just hit 1.0. Oh and node is still single threaded, something horrific for servers that usually have 16+ cores.
- icedchai 10y ago
  You could run Javascript on the server back in 1996. Netscape Enterprise Server supported Javascript as a server-side language, similar to VBScript or PHP. They called it Livewire.
- loftyal 10y ago
  Complete lack of understanding of Node

MrBra 10y ago

This article seems to me a self reassuring post written by the author after he suffered himself the JS fatigue.

kazinator 10y ago

It's very hard to know everything. I made a programming language and I'd be screwed without the manual to refer to. Recently I was utterly surprised by something that was implemented ("you can do that?"). What was it ... aha, I remember: introspection over exception handling sites. The ability to just get a list of the frames through an API, and then directly pick one and jump to it (regardless of whether it catches the type of exception being passed to it that way).

vldr 10y ago

I picked EmberJS because of javascript fatigue - it makes most choices for me and gives me some guarantee that it will work together. But even that fails in practice: sourcemaps don't work properly so you don't get to debug your original ES6 code and more issues like that. Meanwhile there's no clear focus on where the framework is really going (routable components? working pods in ember-cli?, etc)

somecallitblues 10y ago

Could some of this fatigue be due to to JS being so damn hard to troubleshoot? I'm still struggling with troubleshooting JS after years of using it on and off. I still console log everything and keep refreshing the page. Is there a more sane way of doing it?

somecallitblues 10y ago