> 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.<p>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.<p>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.<p>And I could probably get to where I'm going with just a bicycle.
JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month.<p>This is why universities teach <i>computer science</i> rather than just programming. Learn about programming language <i>paradigms</i> - 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.<p>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.<p>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.<p>As far as front-end web development is concerned, all you <i>really</i> need to know is JavaScript, HTML, CSS, and the DOM. Pick an abstraction layer on top of that <i>if you feel it helps you</i>, 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.<p>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.
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.<p>These days everyone is using javascript. In the last year I've done countless javascript projects and <i>one</i> 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.
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!"<p>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.
> Nobody is ever going to know everything there is to know about modern web architecture<p>I think this is the root of the sentiment that is expressed as "JS fatigue" and bullet train rides etc.<p>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!<p>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_.<p>But I can't imagine trying to construct a course to teach "modern web architecture" in a single semester.<p>On the flip side, a lone developer who can chose their <i>battles</i> wisely has more leverage to produce something of value today than was ever freaking possible, ever!<p>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).<p>But by it's nature this world is redundant, competitive, multi-vendor, fractal-specialized and I only see that trend increasing.<p>So yes, one person will never know everything there is to know, the <i>new</i> 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.<p>Essentially, the <i>new</i> skill will be to optimize for laziness :)
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.
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.<p>My advice to the teams I mentor is choose <i>at most</i> 1-2 risky areas and reduce/eliminate risk everywhere else.<p>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.<p>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.
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.<p>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).
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.<p>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.<p>It's causing horrid fragmentations probably won't go away until js is replaced maybe 5 years down the road.<p>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
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.<p>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.<p>Use your tools for what they are useful for, stick close to the metal. You'll save yourself tons of grief.
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.
> gifts<p>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
> and every other exciting, scary, new, hipster Haskell thing that exists in the web dev world today.<p>Ha ha! A fatigued JS developer complaining about hipster Haskell things!
> 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.<p>What does that mean for security, given that two secure systems combined can result in an insecure system?
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.<p>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 <i>curating</i>: 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 <i>those curated lists first, every time</i> before you build anything else.
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.<p>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.
> 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.<p>IMHO a good strategy to reduce the cognitive load (and limit dependencies).
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?").<p>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).
> "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"<p>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.
I picked EmberJS because of javascript fatigue - it makes most choices for me and gives me some guarantee that it will work together.<p>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)
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?
JS fatigue is not a fake problem, it's real and different from other forms of fatigue.<p>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.<p>If any one of those languages were to have the same degree of evolution as JS ... then 'fatigue' would also be an issue.<p>JS has a pernicious problem for a few reasons:<p>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.<p>2) Runtimes, particularly browser - are highly fragmented, and there's scant documentation. Safari docs for Mac/iOS are literally empty in some spots.<p>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.<p>4) Due to the limitations of the browser, we see a lot of churn in frameworks.<p>Though there is some advantage to 'community participation' - the pernicious problem is <i>most of the churn is not fully forward</i>. It's 3 steps forward, 2 steps back, and a step sideways.<p>There's a lot of time and investment in learning something new that won't exist in the future - that's costly.<p>Learning Lambda's for Java 8 is probably worth investing in for Java programmers ... because Java 9 will surely use them as well.<p>Taken as a whole - there is an enormous amount of inherent 'reducible complexity' in the JS ecosystem, which any JS developer intuitively senses.<p>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.<p>It is what it is ... but JS fatigue is a real thing.
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.<p>Before React and Redux and Gulp and whatever else, understand how the language works. Pretty please.