10 ms·

JavaScript Fatigue: Realities of Our Industry

132 points by lucasfcosta 9y ago

quanticle 9y ago
Original site appears to be down, but Internet Archive has a mirror: https://web.archive.org/web/20170727012317/http://lucasfcosta.com/2017/07/17/The-Ultimate-Guide-to-JavaScript-Fatigue.html https://web.archive.org/web/20170727012317/http://lucasfcost...
lisa_henderson 9y ago
You won't find anything in any set of economic statistics that can offer the slightest justification for this statement: "The JavaScript ecosystem nowadays is responsible for the global revolution the same way steam engines were responsible for the first industrial revolution" That is ridiculous. Here is reality: 1.) Labor productivity has been in long-term decline, though computers did cause a temporary surge in the 1990s. See the charts in this post: http://www.bradford-delong.com/2017/07/monday-smackdown-republican-economists-burn-yet-more-of-their-reputations-department.html http://www.bradford-delong.com/2017/07/monday-smackdown-repu... 2.) Economic growth remains sluggish, especially compared to the post war boom of 1945-1973. 3.) The railroads sparked a massive investment boom. The only time computer technologies came close to triggering a similar boom was during the 1990s.
- lucasfcosta 9y ago
  Hi, Lisa, Thanks for your feedback and for providing such interesting facts. I really exaggerated in that hyperbole. Thanks again for pointing this out.
- lsh123 9y ago
  "Labor productivity has been in long-term decline" If I read the graphs from the link correctly, they show that % productivity growth is declining. Still it is positive thus the productivity by itself continues to grow. Hard to say from the graphs, but it looks like absolute productivity growth per year is bigger (or at least the same) as in the 50's: avg 2.5% growth over 60-70 years means ~5x increase of absolute value, thus 4% / year growth in the 50's is the same absolute value as ~0.8% growth today.
le-mark 9y ago
There are a lot of questionable ideas in this piece. > Nobody cares about which programming language you are using, nobody cares about which frameworks your team has chosen, nobody cares about how elegant your data structures are and nobody cares about how good is your code. The only thing that somebody cares about is how much does your software cost and how much revenue it generates I agree with this to a point. The business cares about code quality so far as it effects the ability to deliver new features and maintenance, which in reality means they care quite a lot. They don't understand, and they can't express it, but they do. I work on a legacy app now that is so brittle the team takes months to deliver features, and they're buggy and error prone. This team is competent for the most part too. > JS Fatigue happens when people use tools they don't need to solve problems they don't have. I think the concept the author is going for is best elucidated by Fred Brooks in "No Silver Bullet"[1] when talks about accidental and essential complexity. The idea that there's the complexity of the domain/problem and the complexity we introduce as part of the solution, such as build systems, cross compilers, mvc frameworks etc... > The JavaScript ecosystem nowadays is responsible for the global revolution the same way steam engines were responsible for the first industrial revolution I really can't imagine a scenario where this is true. I'd prefer to see some clarification what revolution the author is referring to exactly. [1] http://www.itu.dk/people/hesj/BSUP/artikler/no-silver-bullit.pdf http://www.itu.dk/people/hesj/BSUP/artikler/no-silver-bullit...
- lucasfcosta 9y ago
  Hi le-mark, Thanks for the feedback. I realize you're right about your last point about the industrial revolution. That was totally my fault, I didn't intend for people to take that literally but I wrote it in a way that made it sound literal. Since that was only an introductory statement I decided on removing that based on the facts shown here later in other to avoid deviating from the post's main subject. Thank you very much for sharing your thoughts!
  - le-mark 9y ago
    Ah ok, hyperbole can be an effective oratorical device, I use it myself from time to time. It's tricky though.
weq 9y ago
I totally agree with the article, but i also find it ironic because this guy got his platform speaking at conferences which IMO as the root of JS fatigue. If we didnt have JS conferences we wouldnt have the level of hype that goes into the next-new-shiney-thing. We wouldnt have a platform for companies to sell ideas and platforms to programmers that they dont need, and we wouldnt have the blog posts and opinions of people who go off to create new solutions to old problems etc etc I totally agree JS fatigue is just another facet of capitialism. You are a programmer, and just like in the gold mining days, the people who got rich were the people spruiking wares to the miners. Just like how Apple tells u, u need an iphone to be cool, the JS conference tells u, u need a framework to be cool. And the key thing to remmeber is - dont beleive the hype. read the code, and make an informed choice. Every dependency in your project should be treated like a matter of life and death.
vlunkr 9y ago
I think what this doesn't address is why fatigue is more of a problem is JS than in other languages. You rarely hear about Ruby fatigue, Python fatigue, etc. Is the insane turnover rate of JS tools really essential to writing great software? I finally started to feel the fatigue with the React and Webpack takeover. I was really into them at first, but I realized that while I was constantly learning new tools, my software wasn't really improving, in fact all the constant changes with upgrading tools was causing a lot of headaches and bugs. And at the end of the day, a good dev can create the same app with react and webpack, or coffeescript and ember, or plain old JS and jquery. In short, JS fatigue game me premature "get off my lawn" syndrome and I actively avoid front end work now.
- white-flame 9y ago
  I'm quite happily and non-fatiguely doing a lot of JS front-end development for my own projects... without any frameworks except a bit of jQuery for DOM manipulation. Now, my needs don't quite fit the common interface models anyway, and as I'm doing stuff for technical users, I don't bother with any browser backwards-compatibility. But as far as managing data, behavior, socket communications, and CSS-styled DOM manipulation goes, I have zero desire to enter the morass of heavyweight framework churn. JavaScript is a pretty reasonable language that you can be quite productive with even in the browser for front-end tasks.
  - mythrwy 9y ago
    It's all fun and games until that little bit of jQuery turns into a lot of jQuery. Sometimes you don't have much of a say into how big things eventually get and sometimes things get a whole lot bigger than you initially imagined. Good organization helps but still, as a jQuery fan myself who has gone through this a few times recently I've started to realize there may just be a better way. Particularly throwing more than one dev in the mix. Going through someone else's tangled box of electrical cords is no fun at all.
    - vlunkr 9y ago
      I hear this sentiment a lot: that jquery projects inevitably become spaghetti, and I can relate, because I've seen it happen, but I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely. At a certain size you should look into frameworks, but it's not always necessary.
carapace 9y ago
> Software solves business problems. This is it. Software does not exist to please us as programmers and let us write beautiful code. Code is a machine, and elegance will always be important -- bottom-line important -- to making good machinery. I see programming as a divine pursuit of truth that, as a side-effect, will automate the solution of all our problems (except for over-population. That one's on us.) At this point the total amount of code in the world should be contracting.
FLUX-YOU 9y ago
>which is why it is extremely important to know the problem domain we are working on To a point. Time spent learning the business domain can't be spent on finding new tech products. If you don't explore new tech products, you are potentially missing out on something that would further allow you to maximize revenue and minimize cost or generate new revenue streams or offer some new service that the business wants. While learning the business domain from people, you're taxing people who could otherwise be working on business problems. There is communication overhead you can't get rid of. You can fatigue someone with domain questions as well. I can't go bother a surgeon any time I feel like it for surgery software feedback -- the guy's likely busy saving lives. If you're lucky enough to get a mentor who's willing to spend time to teach you the field from an entry level, great, but realize that person could be addressing problems with their expertise and are paying an opportunity cost to teach you, which could translate to revenue or reduced costs. If you're going to teach yourself to be good at two entire fields, programming and your problem domain, then you're spending a lot of time on that. There might be jobs to tide you over, but again, what else could you be doing with this invested time?
danso 9y ago
> Reusable space rockets, self-driving cars, robots, artificial intelligence: these things do not exist just because someone thought it would be cool to create them. They exist because there are business interests behind them. And I’m not saying the people behind them just want money, I’m sure they think that stuff is also cool, but the truth is that if they were not economically viable or had any potential to become so, they would not exist. This feels like an overly reductive assessment of why people write software. Is the author completely unaware of software projects or technology in which profit motive was not the goal? Are all the engineers at the Internet Archive just using IA as a stepping stone to joining a VC-funded firm? Is ESR just a big fake? And Woz, too? While it's possible that everything we do in life -- from joining Tinder to hook up, or building Tinder's phone app with React Native and getting paid a high salary -- has no higher purpose than increasing the survivability and propagation of our genes -- there are folks who program and derive joy from building. This includes the early days of Sergey and Larry and Mark Z. In any case, I'm not sure why this is a useful or interesting lens to view JavaScript churn with. The assertions in this article are just all over the place. In one line, the author writes: > Optimize when you need, otherwise you will probably be adding unnecessary complexity to your software, which increases cost, and not generating enough revenue to justify that. And then later on (by "later", I mean the very next line): > This is why I think we should apply Test Driven Development principles to everything we do in our job. And by saying this I’m not just talking about testing. I’m talking about waiting for problems to appear before solving them. OK. Maybe the author seems to have worked on projects in which problems reveal themselves, and do so in convenient serial order. But I imagine many people who end up in frustrating technical debt don't get in that situation willingly, but because life and work and problem solving are messy and chaotic. > Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours I think basic income is a serious issue that we have to consider in the coming years, but I never understand why programmers can't think past their own jobs. When I write programs to automate work in my life, I don't think of it as writing software that puts myself out of a job, but writing software to enhance and augment my intelligence and productivity. Sometimes that helps my financial bottom line. And other times it let's me tackle even greater, more satisfying challenges.
tanilama 9y ago
> Technology is not a goal. Nobody cares about which programming language you are using, nobody cares about which frameworks your team has chosen, nobody cares about how elegant your data structures are and nobody cares about how good is your code. The only thing that somebody cares about is how much does your software cost and how much revenue it generates. This. Technology doesn't matter, if your code doesn't fulfill a mission.
- Xoros 9y ago
  And it may brings back a little bit of humility in our field. There's often no need for a hammer, as shiny as it is, to crack an egg open. Sometimes quick and dirty makes clients happy, and sometimes this is all that matters.
  - mythrwy 9y ago
    While this is certainly true it's also our responsibility to consider the long term well being of a client rather than just their temporary placation with a bit of sugar. Picking apart what people actually need from what they claim to need is an underrated skill.
    - unclebucknasty 9y ago
      >our responsibility to consider the long term well being of a client True, but I don't think the answer is just "framework" either. A more thorough analysis of many of these scenarios would likely yield a surprising number of cases wherein the answer is not framework, if all tradeoffs were earnestly considered. For instance, a couple of short years ago it would have been seen as responsible to build on Angular 1.x. Today, those clients are stuck with an obsolete, underperforming stack that has been deprecated with no reasonable upgrade path. In some ways, knowing what we do about the ever-changing framework landscape, a reasonable argument could be made that it's almost irresponsible to recommend dependency on these ever-heavier, more intrusive, monolithic behemoths.
- celim307 9y ago
  One of the biggest lessons I learned early in my career.
jack9 9y ago
JS doesn't have a reasonable patch and release cycle, so it's always going to be a chore to try to keep up with discoveries and best practices. The noticeable uptick in releases for other languages are why it's such a joy to work with living languages, instead of the twisted JS world of half-measures and fallen-behind code.
- RobertKerans 9y ago
  Yearly releases combined with a transparent process track for new features and fixes would be nice.
  - lambdadmitry 9y ago
    There is a (somewhat) transparent process! (see [1]) I can't see no design process or vision in there, however, it's just a ton of extra features. It seems that between chaotic feature addition and backward compatibility requirements JS becomes a new C++. [1]: https://github.com/tc39/ https://github.com/tc39/
- digi_owl 9y ago
  Half and half. Yes JS is a chore to keep up with because everyone can just push crap online willy nilly. But the uptick in other languages is likely more because they are new and therefore there they have a virgin land advantage. Thus everyone and their dog jumps in to play with and stake their claim on fame and fortune. Soon enough those languages will again be bogged down in half measures and fallen behind code. This because while developers wants to play with new ideas and new code, users value stability and predictability.
  - jack9 9y ago
    > But the uptick in other languages is likely more because they are new and therefore there they have a virgin land advantage. That is incorrect. The languages in production that interact with javascript, might be a better way to think about it. They are all generally older than javascript (as opposed to dead, like ALGOL). The MS ecosystems and Java might have a bogged down problem in the future, but when even Lua is updated more frequently than JS, you might want to question the wisdom of the current processes.
juststeve 9y ago
Everyone wants to make developer tools for street cred, and the github 'social coding' culture is just a vehicle for self promotion. I agree that in the blogs and conferences there's not enough focus on solving business issues, but people should care about languages, because it also is a business issue as others have pointed out. An example: if I worked in a AAA game studio and I decided to write a critical feature in haskell and then quit, will my boss and coworkers care? Maintainability of code, documentation quality and testing are not prioritized enough in the community and conferences which is why i feel there is so much churn, and we get a new programming language every second friday. ie the new tools are the symptom, not the cause of the problem.
spankalee 9y ago
The progression from AMD to CommonJS and all the additional tooling that required is one of the worse things to happen to JS, but it's treated here like just a natural progression from worse to better. AMD actually works in browsers given the features they have. CommonJS requires tooling to function and IMO started the avalanche of tools we need today. JS modules cannot come soon enough. I only hope Node doesn't screw things up for browsers too badly with its modules support.
- model_m_warrior 9y ago
  There was nothing wrong with AMD loading, but the Js developers really wanted to use their bloated frameworks. We're several years in. Everyone getting their advanced Js applications faster? Exactly. I like Js.
anoplus 9y ago
The writer has nailed it for me. > Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours, and this is why basic income will become much more important in the next few years, but that’s a whole other subject.
- progx 9y ago
  Ingeneers does not exist to please us as ingeneers and let us create beautiful constructions. Neither it exists to create jobs for people in any industry. Actually, it exists to kill as many jobs as possible, including our....
  - majewsky 9y ago
    Not generally. Machine engineering, maybe, but e.g. civil engineering creates a ton of jobs in construction.
- progx 9y ago
  Ingeneers does not exist to please us as ingeneers and let us create beautiful constructions. Neither it exists to create jobs for people in any industry. Actually, it exists to kill as many jobs as possible, including our....
- didibus 9y ago
  I dunno about this. Automation of tasks that used to be manual is real, but software goes beyond this. A lot of software allows new or better technologies which can be used to transform the human experience. Such as video games, flight control systems, video conferencing, etc. Other can save lives, such as radio therapy controllers, alarm systems, pace makers, etc. Some can take it away more effectively, like guided missiles, self manned aircrafts, etc. Just wanted to point out it exists for more then just that. Also, in the current market, a company who wants to retain good talent has to allow them some fun, amd giving them the choice of tools or language can be a good recruiting tool, or mechanism to keep good talent.
shusson 9y ago
Please stop calling it JavaScript Fatigue. The complaints are web development related(specifically the browser) not language specific. The distinction is important because people keep trying to compare the issues with other languages.
- nzjrs 9y ago
  Are you saying framework proliferation and the "million modules problem" are not a pain in a non-web application?
  - shusson 9y ago
    Sort of, I would say that the "million modules problem" is caused by the ever changing but backwards compatible web standards. So even if you don't target the web, but use web tech, you'll suffer similar issues.
- pluma 9y ago
  I am what the cool kids call a fullstack developer these days. I use JavaScript in the browser and on the server. My build tools are written in JavaScript. I also write JavaScript for the database (in fact, I am a contributor to a database that is partially implemented in JavaScript). It's absolutely a JavaScript "problem", not one that's specific to web development. Web development is certainly where it's the most prominent but the problem itself isn't at all related to the web. JavaScript fatigue describes FOMO (Fear of Missing Out) as experienced by developers trying to keep up with rapid developments in tooling/libraries. It's not even really about the language, thanks to Elm, Reason and other new languages that joined the ecosystem. You're right that it has little to do with the language, but it also has little to do with the niche. Anyone interested in DevOps experienced some degree of FOMO when suddenly Puppet, Chef and Ansible became a thing (being fundamentally different but also mostly doing the same job). If you just started out with Linux before Ubuntu pretty much became the mainstream starting point, "distro fatigue" was almost certainly a thing. It's just plain old FOMO, but with a tweetable buzzword attached to it.
  - shusson 9y ago
rv77ax 9y ago
I bet the author use space instead of tab.
- pluma 9y ago
  If you write JavaScript and don't use two spaces for indentation you're being intentionally obtuse.
  - scottmf 9y ago
    What why?
    - pluma 9y ago
      Because you don't exist in a vacuum and two spaces is the most popular form of indentation in the ecosystem. But these days I recommend using an intelligent autoformatter like `prettier` when writing JS exactly to avoid any such discussions.
rv77ax 9y ago
I bet the author use space instead of tab.
bad_user 9y ago
These statements are false: > "Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours" Software exists for whatever reason we want it to exist. I started programming when I was 12 and that was 23 years ago. I sure as hell didn't start programming to solve business needs or to kill jobs. In fact this mentality is what I find most upsetting about the industry. Tell a software developer to pick a problem and solve it and he'll almost always look at automating existing workflows. There's this saying that most business software is about automating an Excel spreadsheet shared by email and it's true. But it doesn't have to be that way. Software could also empower people to do things they wouldn't have dreamed of doing before. Just like with musical instruments, which are empowering people that don't have a voice to produce music. And we don't have to look far for such examples. Just the other day I was reading about a nice app by Microsoft helping the blind to see. Software's purpose, if it has any, is to be an extension of our minds. As for the fatigue, that happens because it's 2017 and we are forced to use tools that can be worse than those available in 1980. Of course, such tools wouldn't be successful if many of us weren't guilty of anti-intellectualism. Just look at how many six figures professionals bitch and moan about having to understand what a Monoid is, even though it's part of standard high-school curriculum in some countries, like Romania.
- verinus 9y ago
  I heartily agree with your points and want to add: programmers want to automate tedious, repetitive, manual work so that we can spend our time in a more pleasant way solving more interesting puzzles. @tools: just in the WebDev world. I am still battling to start developing web apps, coming from a java/C# now mostly F# world where we can actually debug effortlessly, use static typing (or the superior type inference in the case of F#) and so on
  - davidjnelson 9y ago
    Webpack, sourcemaps, chrome developer tools, flow, and webstorm could meet your needs for these things.
- 9y ago
progx 9y ago
"JS Fatigue happens when people use tools they don't need to solve problems they don't have" Why JS only? This statement applies to everything, not only development.
- bryanrasmussen 9y ago
  Yes - the specific JS Fatigue is thus an instance of a more general type of fatigue. As it is often the case that specific things turn out to be instances of more general things.
- digi_owl 9y ago
  Because JS drives the cloud, and cloud is the hype.
drinchev 9y ago
> Nowadays something I see very often is people looking for boilerplates when they’re trying to learn a new technology, but, in my opinion, you should avoid boilerplates when you’re starting out. The top of the top JS Fatigue I've seen, for a while, is Electron React Boilerplate [1]. Just take a look at dev dependencies [2]. I totally agree with the author with not starting with a boilerplate, but as far as I can see, the community thinks the other way around. 1: https://github.com/chentsulin/electron-react-boilerplate https://github.com/chentsulin/electron-react-boilerplate 2: https://github.com/chentsulin/electron-react-boilerplate/blob/4fbc20253374bd2b378ef8dfbff37566eb83cc45/package.json#L118 https://github.com/chentsulin/electron-react-boilerplate/blo...
andrewstuart 9y ago
Actually I think that in many cases the technology is the goal. Much of programming is driven by love for the art and the craft and much programming is done primarily because its what people to choose to do because they love it. Reducing all programming to meeting some business case defined by a business person is well.... not right.
- digi_owl 9y ago
  And yet some of the biggest commercial software successes are just that, to hell with everything but the business case(s). While at the same time massive elegant pieces of code get stuck in limbo because the people in charge keep chasing programming perfection.
edem 9y ago
This article fails to address the main problem: the javascript ecosystem is like a cancer: it spreads at an alarming rate and you just can't keep up and the quality of the tools converges to zero. Even the numerous [hiccups](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) don't make js devs realize that there are big problems at the heart of the javascript world. They are either blinded by the Blub paradox or just do it for the money. Most js devs don't even know what big O is and how do you expect someone to write a graph library (or anything involving the simplest of algorithms) without that knowledge? At least there are languages which can be compiled/transpiled to js and WebAssembly is coming so I don't have to touch this abomination.
jondubois 9y ago
I think that a problem in the JavaScript community is that some projects and people rise to the top extremely quickly and this creates undue hype - Then developers just pile onto the latest shiniest ideas and abstract concepts without actually doing the due diligence for themselves in a real-world practical setting. Eventually, developers realize that while the over-hyped tool or framework that they're using does add a form of theoretical elegance to their project, it also carries crippling non-obvious overheads which slow down real-world development overall. I think it's important not to buy into hype. When evaluating and selecting a framework or library for a project, if it has had a lot of hype then instead of marking that as a positive on your checklist, it should be marked as a neutral or sometimes even as a negative.
dennykane 9y ago
> My first advice for anyone suffering from JS Fatigue would definitely be to stay aware that you don’t need to know everything. The reason why I created "Linux on the Web" (https://linuxontheweb.org https://linuxontheweb.org) is so that I wouldn't have to know any of that mind-numbing framework-y stuff. Plain old JS plus a whole lotta *nix/CLI client side statefulness. The mission is simple: bring general computation back to the client! Viva la client!
sAbakumoff 9y ago
I always thought of programming as the art. it needs you to be creative, it may give you moments of enlightening and desperation and happiness and depression. the article tries to persuade me that actually all that I do is reducing cost. sad.
- sAbakumoff 9y ago
  Downvoters, do u care to elaborate?
specialist 9y ago
From the article: "Complaining about JS Fatigue is just like complaining about the fact that humanity has created too many tools to solve the problems we have..." Um. No. (Full stop.) JavaScript et al is evidence that the cone of ignorance expands faster, further than the cone of experience. Wisdom can never overtake, vanquish the chaos. Many geeks thought rationality would win. Like a natural law. Alas. Complaining is just stage 2 in the bereavement cycle. With respect to JavaScript, I'm now in stage 3. Because I have to make rent. As for the creators, champions, defenders of JavaScript, I relish the certainty that in a few years they'll be complaining about whatever garbage succeeds them. Payback. I hope it sucks. https://psychcentral.com/lib/the-5-stages-of-loss-and-grief/ https://psychcentral.com/lib/the-5-stages-of-loss-and-grief/
- RandyRanderson 9y ago
  I laughed out loud at this. There's two types of these guys: 1 the ones who don't know what they did was awful and are thinking about how great they are 2 The ones who know what they did was terrible and are imagining how their shit tastes in our collective mouths Alas, both types are happily retired from book sales and conference speaking fees, so...
mpg515 9y ago
It would be very nice if browsers were not so bad, and included more than just Javascript rendering engines. Like, I don't know, maybe Python? I am personally very tired of being tied into JS. I don't even like it as a language very much but since I'm a FED, I have to use it, or something that transpiles to it. This is not a very good paradigm.

132 points by lucasfcosta 9y ago

Original site appears to be down, but Internet Archive has a mirror: https://web.archive.org/web/20170727012317/http://lucasfcosta.com/2017/07/17/The-Ultimate-Guide-to-JavaScript-Fatigue.html https://web.archive.org/web/20170727012317/http://lucasfcost...

lisa_henderson 9y ago

You won't find anything in any set of economic statistics that can offer the slightest justification for this statement: "The JavaScript ecosystem nowadays is responsible for the global revolution the same way steam engines were responsible for the first industrial revolution" That is ridiculous. Here is reality: 1.) Labor productivity has been in long-term decline, though computers did cause a temporary surge in the 1990s. See the charts in this post: http://www.bradford-delong.com/2017/07/monday-smackdown-republican-economists-burn-yet-more-of-their-reputations-department.html http://www.bradford-delong.com/2017/07/monday-smackdown-repu... 2.) Economic growth remains sluggish, especially compared to the post war boom of 1945-1973. 3.) The railroads sparked a massive investment boom. The only time computer technologies came close to triggering a similar boom was during the 1990s.

lucasfcosta 9y ago
Hi, Lisa, Thanks for your feedback and for providing such interesting facts. I really exaggerated in that hyperbole. Thanks again for pointing this out.
lsh123 9y ago
"Labor productivity has been in long-term decline" If I read the graphs from the link correctly, they show that % productivity growth is declining. Still it is positive thus the productivity by itself continues to grow. Hard to say from the graphs, but it looks like absolute productivity growth per year is bigger (or at least the same) as in the 50's: avg 2.5% growth over 60-70 years means ~5x increase of absolute value, thus 4% / year growth in the 50's is the same absolute value as ~0.8% growth today.

le-mark 9y ago

There are a lot of questionable ideas in this piece. > Nobody cares about which programming language you are using, nobody cares about which frameworks your team has chosen, nobody cares about how elegant your data structures are and nobody cares about how good is your code. The only thing that somebody cares about is how much does your software cost and how much revenue it generates I agree with this to a point. The business cares about code quality so far as it effects the ability to deliver new features and maintenance, which in reality means they care quite a lot. They don't understand, and they can't express it, but they do. I work on a legacy app now that is so brittle the team takes months to deliver features, and they're buggy and error prone. This team is competent for the most part too. > JS Fatigue happens when people use tools they don't need to solve problems they don't have. I think the concept the author is going for is best elucidated by Fred Brooks in "No Silver Bullet"[1] when talks about accidental and essential complexity. The idea that there's the complexity of the domain/problem and the complexity we introduce as part of the solution, such as build systems, cross compilers, mvc frameworks etc... > The JavaScript ecosystem nowadays is responsible for the global revolution the same way steam engines were responsible for the first industrial revolution I really can't imagine a scenario where this is true. I'd prefer to see some clarification what revolution the author is referring to exactly. [1] http://www.itu.dk/people/hesj/BSUP/artikler/no-silver-bullit.pdf http://www.itu.dk/people/hesj/BSUP/artikler/no-silver-bullit...

lucasfcosta 9y ago
Hi le-mark, Thanks for the feedback. I realize you're right about your last point about the industrial revolution. That was totally my fault, I didn't intend for people to take that literally but I wrote it in a way that made it sound literal. Since that was only an introductory statement I decided on removing that based on the facts shown here later in other to avoid deviating from the post's main subject. Thank you very much for sharing your thoughts!
- le-mark 9y ago
  Ah ok, hyperbole can be an effective oratorical device, I use it myself from time to time. It's tricky though.

weq 9y ago

I totally agree with the article, but i also find it ironic because this guy got his platform speaking at conferences which IMO as the root of JS fatigue. If we didnt have JS conferences we wouldnt have the level of hype that goes into the next-new-shiney-thing. We wouldnt have a platform for companies to sell ideas and platforms to programmers that they dont need, and we wouldnt have the blog posts and opinions of people who go off to create new solutions to old problems etc etc I totally agree JS fatigue is just another facet of capitialism. You are a programmer, and just like in the gold mining days, the people who got rich were the people spruiking wares to the miners. Just like how Apple tells u, u need an iphone to be cool, the JS conference tells u, u need a framework to be cool. And the key thing to remmeber is - dont beleive the hype. read the code, and make an informed choice. Every dependency in your project should be treated like a matter of life and death.

vlunkr 9y ago

I think what this doesn't address is why fatigue is more of a problem is JS than in other languages. You rarely hear about Ruby fatigue, Python fatigue, etc. Is the insane turnover rate of JS tools really essential to writing great software? I finally started to feel the fatigue with the React and Webpack takeover. I was really into them at first, but I realized that while I was constantly learning new tools, my software wasn't really improving, in fact all the constant changes with upgrading tools was causing a lot of headaches and bugs. And at the end of the day, a good dev can create the same app with react and webpack, or coffeescript and ember, or plain old JS and jquery. In short, JS fatigue game me premature "get off my lawn" syndrome and I actively avoid front end work now.

white-flame 9y ago
I'm quite happily and non-fatiguely doing a lot of JS front-end development for my own projects... without any frameworks except a bit of jQuery for DOM manipulation. Now, my needs don't quite fit the common interface models anyway, and as I'm doing stuff for technical users, I don't bother with any browser backwards-compatibility. But as far as managing data, behavior, socket communications, and CSS-styled DOM manipulation goes, I have zero desire to enter the morass of heavyweight framework churn. JavaScript is a pretty reasonable language that you can be quite productive with even in the browser for front-end tasks.
- mythrwy 9y ago
  It's all fun and games until that little bit of jQuery turns into a lot of jQuery. Sometimes you don't have much of a say into how big things eventually get and sometimes things get a whole lot bigger than you initially imagined. Good organization helps but still, as a jQuery fan myself who has gone through this a few times recently I've started to realize there may just be a better way. Particularly throwing more than one dev in the mix. Going through someone else's tangled box of electrical cords is no fun at all.
  - vlunkr 9y ago
    I hear this sentiment a lot: that jquery projects inevitably become spaghetti, and I can relate, because I've seen it happen, but I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely. At a certain size you should look into frameworks, but it's not always necessary.

carapace 9y ago

> Software solves business problems. This is it. Software does not exist to please us as programmers and let us write beautiful code. Code is a machine, and elegance will always be important -- bottom-line important -- to making good machinery. I see programming as a divine pursuit of truth that, as a side-effect, will automate the solution of all our problems (except for over-population. That one's on us.) At this point the total amount of code in the world should be contracting.

FLUX-YOU 9y ago

>which is why it is extremely important to know the problem domain we are working on To a point. Time spent learning the business domain can't be spent on finding new tech products. If you don't explore new tech products, you are potentially missing out on something that would further allow you to maximize revenue and minimize cost or generate new revenue streams or offer some new service that the business wants. While learning the business domain from people, you're taxing people who could otherwise be working on business problems. There is communication overhead you can't get rid of. You can fatigue someone with domain questions as well. I can't go bother a surgeon any time I feel like it for surgery software feedback -- the guy's likely busy saving lives. If you're lucky enough to get a mentor who's willing to spend time to teach you the field from an entry level, great, but realize that person could be addressing problems with their expertise and are paying an opportunity cost to teach you, which could translate to revenue or reduced costs. If you're going to teach yourself to be good at two entire fields, programming and your problem domain, then you're spending a lot of time on that. There might be jobs to tide you over, but again, what else could you be doing with this invested time?

danso 9y ago

> Reusable space rockets, self-driving cars, robots, artificial intelligence: these things do not exist just because someone thought it would be cool to create them. They exist because there are business interests behind them. And I’m not saying the people behind them just want money, I’m sure they think that stuff is also cool, but the truth is that if they were not economically viable or had any potential to become so, they would not exist. This feels like an overly reductive assessment of why people write software. Is the author completely unaware of software projects or technology in which profit motive was not the goal? Are all the engineers at the Internet Archive just using IA as a stepping stone to joining a VC-funded firm? Is ESR just a big fake? And Woz, too? While it's possible that everything we do in life -- from joining Tinder to hook up, or building Tinder's phone app with React Native and getting paid a high salary -- has no higher purpose than increasing the survivability and propagation of our genes -- there are folks who program and derive joy from building. This includes the early days of Sergey and Larry and Mark Z. In any case, I'm not sure why this is a useful or interesting lens to view JavaScript churn with. The assertions in this article are just all over the place. In one line, the author writes: > Optimize when you need, otherwise you will probably be adding unnecessary complexity to your software, which increases cost, and not generating enough revenue to justify that. And then later on (by "later", I mean the very next line): > This is why I think we should apply Test Driven Development principles to everything we do in our job. And by saying this I’m not just talking about testing. I’m talking about waiting for problems to appear before solving them. OK. Maybe the author seems to have worked on projects in which problems reveal themselves, and do so in convenient serial order. But I imagine many people who end up in frustrating technical debt don't get in that situation willingly, but because life and work and problem solving are messy and chaotic. > Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours I think basic income is a serious issue that we have to consider in the coming years, but I never understand why programmers can't think past their own jobs. When I write programs to automate work in my life, I don't think of it as writing software that puts myself out of a job, but writing software to enhance and augment my intelligence and productivity. Sometimes that helps my financial bottom line. And other times it let's me tackle even greater, more satisfying challenges.

tanilama 9y ago

> Technology is not a goal. Nobody cares about which programming language you are using, nobody cares about which frameworks your team has chosen, nobody cares about how elegant your data structures are and nobody cares about how good is your code. The only thing that somebody cares about is how much does your software cost and how much revenue it generates. This. Technology doesn't matter, if your code doesn't fulfill a mission.

Xoros 9y ago
And it may brings back a little bit of humility in our field. There's often no need for a hammer, as shiny as it is, to crack an egg open. Sometimes quick and dirty makes clients happy, and sometimes this is all that matters.
- mythrwy 9y ago
  While this is certainly true it's also our responsibility to consider the long term well being of a client rather than just their temporary placation with a bit of sugar. Picking apart what people actually need from what they claim to need is an underrated skill.
  - unclebucknasty 9y ago
    >our responsibility to consider the long term well being of a client True, but I don't think the answer is just "framework" either. A more thorough analysis of many of these scenarios would likely yield a surprising number of cases wherein the answer is not framework, if all tradeoffs were earnestly considered. For instance, a couple of short years ago it would have been seen as responsible to build on Angular 1.x. Today, those clients are stuck with an obsolete, underperforming stack that has been deprecated with no reasonable upgrade path. In some ways, knowing what we do about the ever-changing framework landscape, a reasonable argument could be made that it's almost irresponsible to recommend dependency on these ever-heavier, more intrusive, monolithic behemoths.
celim307 9y ago
One of the biggest lessons I learned early in my career.

jack9 9y ago

JS doesn't have a reasonable patch and release cycle, so it's always going to be a chore to try to keep up with discoveries and best practices. The noticeable uptick in releases for other languages are why it's such a joy to work with living languages, instead of the twisted JS world of half-measures and fallen-behind code.

RobertKerans 9y ago
Yearly releases combined with a transparent process track for new features and fixes would be nice.
- lambdadmitry 9y ago
  There is a (somewhat) transparent process! (see [1]) I can't see no design process or vision in there, however, it's just a ton of extra features. It seems that between chaotic feature addition and backward compatibility requirements JS becomes a new C++. [1]: https://github.com/tc39/ https://github.com/tc39/
digi_owl 9y ago
Half and half. Yes JS is a chore to keep up with because everyone can just push crap online willy nilly. But the uptick in other languages is likely more because they are new and therefore there they have a virgin land advantage. Thus everyone and their dog jumps in to play with and stake their claim on fame and fortune. Soon enough those languages will again be bogged down in half measures and fallen behind code. This because while developers wants to play with new ideas and new code, users value stability and predictability.
- jack9 9y ago
  > But the uptick in other languages is likely more because they are new and therefore there they have a virgin land advantage. That is incorrect. The languages in production that interact with javascript, might be a better way to think about it. They are all generally older than javascript (as opposed to dead, like ALGOL). The MS ecosystems and Java might have a bogged down problem in the future, but when even Lua is updated more frequently than JS, you might want to question the wisdom of the current processes.

juststeve 9y ago

Everyone wants to make developer tools for street cred, and the github 'social coding' culture is just a vehicle for self promotion. I agree that in the blogs and conferences there's not enough focus on solving business issues, but people should care about languages, because it also is a business issue as others have pointed out. An example: if I worked in a AAA game studio and I decided to write a critical feature in haskell and then quit, will my boss and coworkers care? Maintainability of code, documentation quality and testing are not prioritized enough in the community and conferences which is why i feel there is so much churn, and we get a new programming language every second friday. ie the new tools are the symptom, not the cause of the problem.

spankalee 9y ago

The progression from AMD to CommonJS and all the additional tooling that required is one of the worse things to happen to JS, but it's treated here like just a natural progression from worse to better. AMD actually works in browsers given the features they have. CommonJS requires tooling to function and IMO started the avalanche of tools we need today. JS modules cannot come soon enough. I only hope Node doesn't screw things up for browsers too badly with its modules support.

model_m_warrior 9y ago
There was nothing wrong with AMD loading, but the Js developers really wanted to use their bloated frameworks. We're several years in. Everyone getting their advanced Js applications faster? Exactly. I like Js.

anoplus 9y ago

The writer has nailed it for me. > Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours, and this is why basic income will become much more important in the next few years, but that’s a whole other subject.

progx 9y ago
Ingeneers does not exist to please us as ingeneers and let us create beautiful constructions. Neither it exists to create jobs for people in any industry. Actually, it exists to kill as many jobs as possible, including our....
- majewsky 9y ago
  Not generally. Machine engineering, maybe, but e.g. civil engineering creates a ton of jobs in construction.
progx 9y ago
Ingeneers does not exist to please us as ingeneers and let us create beautiful constructions. Neither it exists to create jobs for people in any industry. Actually, it exists to kill as many jobs as possible, including our....
didibus 9y ago
I dunno about this. Automation of tasks that used to be manual is real, but software goes beyond this. A lot of software allows new or better technologies which can be used to transform the human experience. Such as video games, flight control systems, video conferencing, etc. Other can save lives, such as radio therapy controllers, alarm systems, pace makers, etc. Some can take it away more effectively, like guided missiles, self manned aircrafts, etc. Just wanted to point out it exists for more then just that. Also, in the current market, a company who wants to retain good talent has to allow them some fun, amd giving them the choice of tools or language can be a good recruiting tool, or mechanism to keep good talent.

shusson 9y ago

Please stop calling it JavaScript Fatigue. The complaints are web development related(specifically the browser) not language specific. The distinction is important because people keep trying to compare the issues with other languages.

nzjrs 9y ago
Are you saying framework proliferation and the "million modules problem" are not a pain in a non-web application?
- shusson 9y ago
  Sort of, I would say that the "million modules problem" is caused by the ever changing but backwards compatible web standards. So even if you don't target the web, but use web tech, you'll suffer similar issues.
pluma 9y ago
I am what the cool kids call a fullstack developer these days. I use JavaScript in the browser and on the server. My build tools are written in JavaScript. I also write JavaScript for the database (in fact, I am a contributor to a database that is partially implemented in JavaScript). It's absolutely a JavaScript "problem", not one that's specific to web development. Web development is certainly where it's the most prominent but the problem itself isn't at all related to the web. JavaScript fatigue describes FOMO (Fear of Missing Out) as experienced by developers trying to keep up with rapid developments in tooling/libraries. It's not even really about the language, thanks to Elm, Reason and other new languages that joined the ecosystem. You're right that it has little to do with the language, but it also has little to do with the niche. Anyone interested in DevOps experienced some degree of FOMO when suddenly Puppet, Chef and Ansible became a thing (being fundamentally different but also mostly doing the same job). If you just started out with Linux before Ubuntu pretty much became the mainstream starting point, "distro fatigue" was almost certainly a thing. It's just plain old FOMO, but with a tweetable buzzword attached to it.
- shusson 9y ago

rv77ax 9y ago

I bet the author use space instead of tab.

pluma 9y ago
If you write JavaScript and don't use two spaces for indentation you're being intentionally obtuse.
- scottmf 9y ago
  What why?
  - pluma 9y ago
    Because you don't exist in a vacuum and two spaces is the most popular form of indentation in the ecosystem. But these days I recommend using an intelligent autoformatter like `prettier` when writing JS exactly to avoid any such discussions.

rv77ax 9y ago

I bet the author use space instead of tab.

bad_user 9y ago

These statements are false: > "Software does not exist to please us as programmers and let us write beautiful code. Neither it exists to create jobs for people in the tech industry. Actually, it exists to kill as many jobs as possible, including ours" Software exists for whatever reason we want it to exist. I started programming when I was 12 and that was 23 years ago. I sure as hell didn't start programming to solve business needs or to kill jobs. In fact this mentality is what I find most upsetting about the industry. Tell a software developer to pick a problem and solve it and he'll almost always look at automating existing workflows. There's this saying that most business software is about automating an Excel spreadsheet shared by email and it's true. But it doesn't have to be that way. Software could also empower people to do things they wouldn't have dreamed of doing before. Just like with musical instruments, which are empowering people that don't have a voice to produce music. And we don't have to look far for such examples. Just the other day I was reading about a nice app by Microsoft helping the blind to see. Software's purpose, if it has any, is to be an extension of our minds. As for the fatigue, that happens because it's 2017 and we are forced to use tools that can be worse than those available in 1980. Of course, such tools wouldn't be successful if many of us weren't guilty of anti-intellectualism. Just look at how many six figures professionals bitch and moan about having to understand what a Monoid is, even though it's part of standard high-school curriculum in some countries, like Romania.

verinus 9y ago
I heartily agree with your points and want to add: programmers want to automate tedious, repetitive, manual work so that we can spend our time in a more pleasant way solving more interesting puzzles. @tools: just in the WebDev world. I am still battling to start developing web apps, coming from a java/C# now mostly F# world where we can actually debug effortlessly, use static typing (or the superior type inference in the case of F#) and so on
- davidjnelson 9y ago
  Webpack, sourcemaps, chrome developer tools, flow, and webstorm could meet your needs for these things.
9y ago

progx 9y ago

"JS Fatigue happens when people use tools they don't need to solve problems they don't have" Why JS only? This statement applies to everything, not only development.

bryanrasmussen 9y ago
Yes - the specific JS Fatigue is thus an instance of a more general type of fatigue. As it is often the case that specific things turn out to be instances of more general things.
digi_owl 9y ago
Because JS drives the cloud, and cloud is the hype.

drinchev 9y ago

> Nowadays something I see very often is people looking for boilerplates when they’re trying to learn a new technology, but, in my opinion, you should avoid boilerplates when you’re starting out. The top of the top JS Fatigue I've seen, for a while, is Electron React Boilerplate [1]. Just take a look at dev dependencies [2]. I totally agree with the author with not starting with a boilerplate, but as far as I can see, the community thinks the other way around. 1: https://github.com/chentsulin/electron-react-boilerplate https://github.com/chentsulin/electron-react-boilerplate 2: https://github.com/chentsulin/electron-react-boilerplate/blob/4fbc20253374bd2b378ef8dfbff37566eb83cc45/package.json#L118 https://github.com/chentsulin/electron-react-boilerplate/blo...

andrewstuart 9y ago

Actually I think that in many cases the technology is the goal. Much of programming is driven by love for the art and the craft and much programming is done primarily because its what people to choose to do because they love it. Reducing all programming to meeting some business case defined by a business person is well.... not right.

digi_owl 9y ago
And yet some of the biggest commercial software successes are just that, to hell with everything but the business case(s). While at the same time massive elegant pieces of code get stuck in limbo because the people in charge keep chasing programming perfection.

edem 9y ago

This article fails to address the main problem: the javascript ecosystem is like a cancer: it spreads at an alarming rate and you just can't keep up and the quality of the tools converges to zero. Even the numerous [hiccups](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/ https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/) don't make js devs realize that there are big problems at the heart of the javascript world. They are either blinded by the Blub paradox or just do it for the money. Most js devs don't even know what big O is and how do you expect someone to write a graph library (or anything involving the simplest of algorithms) without that knowledge? At least there are languages which can be compiled/transpiled to js and WebAssembly is coming so I don't have to touch this abomination.

jondubois 9y ago

I think that a problem in the JavaScript community is that some projects and people rise to the top extremely quickly and this creates undue hype - Then developers just pile onto the latest shiniest ideas and abstract concepts without actually doing the due diligence for themselves in a real-world practical setting. Eventually, developers realize that while the over-hyped tool or framework that they're using does add a form of theoretical elegance to their project, it also carries crippling non-obvious overheads which slow down real-world development overall. I think it's important not to buy into hype. When evaluating and selecting a framework or library for a project, if it has had a lot of hype then instead of marking that as a positive on your checklist, it should be marked as a neutral or sometimes even as a negative.

dennykane 9y ago

> My first advice for anyone suffering from JS Fatigue would definitely be to stay aware that you don’t need to know everything. The reason why I created "Linux on the Web" (https://linuxontheweb.org https://linuxontheweb.org) is so that I wouldn't have to know any of that mind-numbing framework-y stuff. Plain old JS plus a whole lotta *nix/CLI client side statefulness. The mission is simple: bring general computation back to the client! Viva la client!

sAbakumoff 9y ago

I always thought of programming as the art. it needs you to be creative, it may give you moments of enlightening and desperation and happiness and depression. the article tries to persuade me that actually all that I do is reducing cost. sad.

sAbakumoff 9y ago
Downvoters, do u care to elaborate?

specialist 9y ago

From the article: "Complaining about JS Fatigue is just like complaining about the fact that humanity has created too many tools to solve the problems we have..." Um. No. (Full stop.) JavaScript et al is evidence that the cone of ignorance expands faster, further than the cone of experience. Wisdom can never overtake, vanquish the chaos. Many geeks thought rationality would win. Like a natural law. Alas. Complaining is just stage 2 in the bereavement cycle. With respect to JavaScript, I'm now in stage 3. Because I have to make rent. As for the creators, champions, defenders of JavaScript, I relish the certainty that in a few years they'll be complaining about whatever garbage succeeds them. Payback. I hope it sucks. https://psychcentral.com/lib/the-5-stages-of-loss-and-grief/ https://psychcentral.com/lib/the-5-stages-of-loss-and-grief/

RandyRanderson 9y ago
I laughed out loud at this. There's two types of these guys: 1 the ones who don't know what they did was awful and are thinking about how great they are 2 The ones who know what they did was terrible and are imagining how their shit tastes in our collective mouths Alas, both types are happily retired from book sales and conference speaking fees, so...

mpg515 9y ago

It would be very nice if browsers were not so bad, and included more than just Javascript rendering engines. Like, I don't know, maybe Python? I am personally very tired of being tied into JS. I don't even like it as a language very much but since I'm a FED, I have to use it, or something that transpiles to it. This is not a very good paradigm.