Hacker News new | past | comments | ask | show | jobs | submit login
JavaScript Fatigue: Realities of Our Industry (lucasfcosta.com)
132 points by lucasfcosta on July 27, 2017 | hide | past | favorite | 101 comments



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.


> Software's purpose, if it has any, is to be an extension of our minds.

Someone said: "A computer is like a bicycle for the mind."

- There is a variety of bicycles at various price points, quality, styles and for varying terrains. If at all possible choose the one you like as much as the one that fits your problem.

- You can enjoy a bicycle by itself and not just for moving your body from point A to B

- I believe fatigue (in general) comes from everyone and their dog reinventing a variety of bicycles, each one a million times, and most of them are half-assed enough they can only roll around a circus pit, if at all, and abandoned the next day they're published (spoiler: maintaining is hard!). Even the high profile ones get through the let's do this again, only different, and we promise, we got it wrong the first time but now it's ok! But it's not helpful for the mind to endlessly learn a new way to ride for the umpteenth time only to pedal in circle. And I believe JS fatigue because of its tyrannic omnipresence in browsers as well as the limitations of the platform lends itself to (almost coerces people into) solving the same problems again and again.


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


Webpack, sourcemaps, chrome developer tools, flow, and webstorm could meet your needs for these things.


>Software exists for whatever reason we want it to exist.

Yes, the author stated this from a very narrow point of view. Software exists for whatever reason we want it to, but business pays people to build it to solve their problems.

>almost always look at automating existing workflows.

I've always justified it in my mind as making existing workers more productive. As long as the company I was working for was constantly hiring, growing and in a competitive market, it was ok.

The paragraph about no one cares what language you use, etc is obviously false. Write a PHP app in a C# shop is an easy way to disprove that theory.

Also, what the author fails to take into account is scalability. As the business grows, the software needs to grow with it, or all those marketing dollars they threw in to grow the company will be wasted and growth will be halted. That's where the business would need to defer technical decisions to technical people.

An acquaintance of mine currently works for a company who is about to hit a hard wall where they will no longer be able to take any more orders due to scalability of the software they chose. They aren't doing much about it, not realizing that by the time this happens, it will be too late. The CEO probably read an article just like this.

But I will agree with the author that JS, and web front end in general, is way more complicated than it needs to be.


Well you can't make a silk purse out of a sow's ear. Don't expect quality js tools to emerge from an ecosystem which is rotting at its core.


What did I miss? How is "the JS ecosystem" rotting at its core?

Unless you're arguing _all_ programming language ecosystems are rotting (or too young and niche to have an actual ecosystem), I have no idea how you're arriving at that conclusion.

EcmaScript, HTML and CSS are standards that are continuously being developed and seeing updates. Browsers are now evergreen or quickly becoming irrelevant (even old IE will eventually be replaced by the evergreen Edge). My build tools are mostly Webpack and Babel, two actively maintained projects with highly active communities. My applications are mostly built around React, which is also in active development and has the full weight of numerous major companies behind it (not to mention it's being sponsored by Facebook).

So I ask you, how is "the ecosystem" rotting at "its core"? Are you talking about jQuery which today can mostly be replaced by native browser APIs but is still getting updates? Are you talking about Backbone, which everyone has been moving away from for years? Are you talking about Grunt and Gulp and all the other task runners which merrily chug along on myriads of development machines?

The JS ecosystem isn't rotting at its core. The JS ecosystem has no core. And it's not rot, it's compost, obsolete refuse disintegrating to give way to new development, feeding the ecosystem by releasing developers who would otherwise be stuck maintaining outdated technology.


The language itself is the problem. JS doesn't even have a standard library. If you look at the documentation you can't even tell what the complexity of the `shift` operation is in an `Array`. Java on the other hand has a very well documented stdlib with all the concurrent and non concurrent data structures and utilities you can think of.

Javascript is a crude tool and the fact that [it was created in 10 days](https://www.w3.org/community/webed/wiki/A_Short_History_of_J...) does not help it.

This language has a lot of compost as you say but one can't differentiate between refuse and pristine tools (the latter might theoretically exist) just by looking at it and no one has the time to analyze all the tools he might end up using since there are so many. So you take one which has the most stars on github (like I did with [graphlib](https://github.com/cpettitt/graphlib)) then you realize that it is crap and you end up writing one from scratch.


Entropy.


Es6 has some nice moderate changes that can trickle up.. An infinite number of bad tools and frameworks doesn't really stop a good one from coming along anymore than all the low quality OSes and environs that had a libc and compiler stopped C.


Honestly this entire argument sounds like "Linux is terrible because there are so many useless and terrible distros". Just use Ubuntu because that's what everybody uses. Or spend some effort looking into it and see if you end up with Debian or maybe CentOS or Arch.


He meant Software jobs, not software.


*Monad?


This is a beautiful post


Also are you kidding about Monoids? No way category is part of any General Education curriculum.


Sure is, I can confirm for Romania. We studied it as part of 12th grade algebra (last year of highschool, in Romania).

If you don't believe my personal anecdote, here: http://www.meditatiionline.ro/44100-122-411-0-0-Formule_Mate...

(site is -- obviously :-) -- in Romanian, but it's pretty clear)

It's material specifically targeted at 12th grade students, in normal highschools.


Why is it so unbelievable to you that some countries have more extensive high school math curricula?

I don't know this particular case, but it's well known that countries from the ex-USSR teach math at much more intensive level. I personally know multiple parents who have immigrated to my Western European country and who complain that their child is being taught concepts they've learned years ago, so much that the parents end up having to home teach them after school.


Went to math-oriented high school in Russia, curriculum had some of category theory in it. Also, I'm constantly amazed at how basic high school math education in states seems to be.


There's a story about a carpenter who walked into a library, picked up a copy of Serge Lang's book "Algebra", skimmed through the first page where he proves uniqueness of the identity in a monoid, was surprised at how ironclad the argument was, and became a mathematician to study it more.

I forget his name, or where I heard it.


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...


> 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 completely elides one of the biggest issues (at least in my job)

-Who is going to maintain the code and how much is that support going to cost.

Maintenance can include troubleshooting and bug fixes/enhancements and sometimes it's just pure support (i.e who does the user contact if their app is crashing).

I don't know about the web which is what I usually associate Javascript with but for in house business applications delivering a well supported application is critical.

I've found (as someone who occasionally has to commission contract work) that unless I am upfront (and dare I say confrontational) about support and maintenance expectations during the design phase I will end up with a complete mess at the end and support costs will end up ballooning out.


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!


Ah ok, hyperbole can be an effective oratorical device, I use it myself from time to time. It's tricky though.


Side note - this type of exchange is why I love HN. It's like Reddit for mature adults.


>It's like Reddit for mature adults.

The immaturity has simply been replaced with smugness and elitism.


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.


I think JS has this problem because of constantly high inflow of new developers who easily get on new boats. They cannot differentiate between old and new tools (except for hype and cv-driveness), and new tools don't kill their productivity as much. Personally I never made it into frontend because learning basics makes me sick of html/css/js trinity, and learning advanced tools is a neverending war. Advanced js programmers feel that and try to create more tools, shorting the circuit.

(Otoh, programming has changed since our youth time. Back then we programmed for one local, now we do it for thousand remotes. Latency penalties turned upside down literally, storage is faster than SIMM, ui is slower than FDD.)

Since web 1.98a* we stopped to look at program as a whole and separated it into frontend and backend. That was a key point that allowed so much divergence and frustration. It may sound crazy, but we need new, more low-level browser (don't even call it browser, it is a network layer) that could seamlessly connect single heterogenous app on two network endpoints, since no one really cares about underlying protocols anymore. Leave www rot in browser and make internet apps great again. All good tools from '95 are still here.

* you cannot call something 2.0 until it has at most 2-3 generic and mature ways to do everything.


> It may sound crazy, but we need new, more low-level browser (don't even call it browser, it is a network layer) that could seamlessly connect single heterogenous app on two network endpoints

XWindows (https://en.wikipedia.org/wiki/X_Window_System)?



Why do we need new stuff? What's wrong with the existing ways of connecting processes over the network?


the effort required to write boilerplate code over and over again with no standard way I would guess...


Why do we even need to connect processes over a network? What's wrong with dumb terminals?


I've written JS every day for nearly 10 years now. I do not have an answer.


You can frankly do front end the way you've always done. We still use razor with a little jquery and a lot of our older projects still use asp forms.

We've used angular on a few projects, but it took time to educate our staff and their time to market as well as the required support increased significantly, and then angular 2 arrived...

Honestly it seems like the JS exists to sell a lot of education and a lot of books. Maybe we did it wrong, but as a clean business case angular was a terrible for us.


Javascript community has evolved in just a few years from script kiddies to adult architects.

Frankly, JS is now much more sophisticated, and definitely requires code design skills.

I will probably have to deal in the following years with a Typescript/Purescript + IntelliJ envrionment.

And that makes me much happier than having to deal with JS spaghetti code from the Web2.0 era.


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.


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.


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.


>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

I hear this a lot--the idea that jQuery or vanilla JS can work for smaller projects if well-organized, but larger projects require frameworks--however, I honestly have no idea how it makes sense.

Seems to me that if you have a good pattern and foundation, then it should scale up to larger projects; else, what we're really saying is that it's still a mess, but a small mess that's manageable because the project is small and there isn't that much code.

But, the framework dogma these days is such that we dare not even suggest undertaking a large project without committing to an "acceptable" framework du juor.

I say this as someone who sees some value in frameworks, but also doesn't believe that the ROI is always there, or that it is absolutely necessary to use a framework on even larger projects. After all, frameworks aren't magical. They are just code. More specifically, they are reusable libraries attached to pattern enforcement. Why can't I choose a couple of libs, come up with reusable code, and implement my own patterns without all of the added cruft, opinion, politics, and risk of jumping on someone else's framework?

Plus, many frameworks have just gotten way too big and complex, and we too infrequently emphasize the cost of using a framework vs. simply championinig the benefits. I want one-way data binding, but I have to change languages, introduce copious build steps, and generally follow all of your opinionated patterns, introducing layers of cruft and structure? Then, after all of this, you may change course with no upgrade path or the framework may simply become unpopular? No thanks.


I agree with the general argument here. Frameworks have pros and cons, but they aren’t magic, and they certainly aren’t the only way to get good results.

Often the challenge in scaling up UI code isn’t the amount of data, it’s the increasing complexity of the relationships between different parts of the data. The more dependencies, the more you have to take into account when you’re updating one part of the UI in response to a change somewhere else.

In another comment, le-mark mentioned Brooks’ distinction between essential and accidental complexity, and that applies here as well. A UI needs enough logic to represent the essential complexity in the underlying data, which might be complicated in itself. However, sometimes the UI also introduces accidental complexity to handle transitioning from one state to another.

This is why I find the modern rendering libraries like React to be a genuine improvement in the state of the art. They allow rendering based on the absolute state of your system, instead of changing the DOM selectively relative to whatever was already there, which in general may be an exponentially more complicated situation. Adopting this approach can directly and sometimes dramatically reduce the complexity of the UI code, compared to manually changing the DOM in response to changes in the underlying state.

The heavyweight frameworks I’ve seen don’t offer that same sort of qualitative improvement. They do provide a systematic architecture, which can certainly be helpful as software grows. On the other hand, we’ve been building much larger software than any web app using good software design principles for decades, without necessarily needing the help of these pervasive frameworks. The trade-off with frameworks usually seems to be a quicker start time as the big advantage against potentially being less flexible if the project’s needs change later as the big disadvantage, but since neither of these issues is unique to frameworks this feels like a quantitative question more than a qualitative one.


Well, that's a refreshingly reasonable approach to frameworks!

I agree 100% that the biggest challenge solved by many of these frameworks is state management and, more specifically, capturing and reflecting state changes in the UI. Just seems that most frameworks start addressing this single issue, then get greedy; metastasizing their way up and down the stack. Suddenly, you're completely hooked in, using npm or similar to generate tons of boilerplate with framework-specific templating and a mini language, on top of a custom build process.

So, simplicity is kind of an amorphous concept here. Maybe you pick up the binding, but you've traded away a lot for it. I haven't had much experience with React, and maybe it does a better job of confining its intrusions to view state management. But, with Angular and others, I have seen and experienced these huge learning curves that make sound developers' heads explode. Like anything, we eventually get it and it becomes second nature, so the perceived complexity is hidden to some extent. So, we tend to say, "hey, look at this neat binding that simplifies my code". Meanwhile, we're completely overlooking the learning curve, boilerplate, build process, and MB-denominated framework file sizes.

>potentially being less flexible if the project’s needs change later as the big disadvantage

Interesting take, as it's usually the reverse you hear: that is, without a framework everything will devolve into utter chaos as the project grows and takes on new requirements.

My take is that, framework or no, at the end of the day nothing can take the place of good design. And, I guess that's really my larger point here. People tend to offer up "framework" as the one word answer to Web development these days, and I don't think that's a healthy state.


Scalling up means more people,new people, and people with different opinions about what is good. It is easier when framework itself encourages common patterns. Own solution tend to be tailored to first use case and work nor as well in general.


>It is easier when framework itself encourages common patterns

It's like developers don't want to design anything these days.

Frameworks are generally overkill and, increasingly, insert too much opinionated cruft into a project. How can it possibly always be more efficient to wedge in this singularly opinionated way to implement every app just because the team exceeds n members?

There are ways to enforce discipline on larger teams without relying on someone else's ideas.


Can you explain that a bit more? I've been building various web UIs for quite a few years, and the jQuery parts are generally just simple calls whenever the DOM needs to be updated, or when an action needs to recollect some UI state to carry out actions. Most state is held in the JS data structures, and the UI simply reflects it through pretty basic transformations.

I don't quite understand the model of writing that would lead to massively tangled jQuery code. Obviously, I'm building internal use and personal projects, but I also design my UI elements based on what HTML/CSS already offers, instead of trying to force foreign designs & models on it.

Of course, JS & front-end development isn't my primary domain. Backend distributed non-web servers, data analysis, and software automation is more my thing. Front ends are just a side requirement of completing the loop sometimes, but software manageability issues at scale aren't unfamiliar to me. I just don't see how people can tangle themselves up as much as they have across the board in the web front end domains.


LOL. I remember saying almost exactly the same things and not long ago!

It's not necessarily a matter of "tangled up" (although that happens also with size if one isn't careful). It's more a matter of very unwieldy to work with and a lot of cognitive overhead. The few "updating DOM" things turn into hundreds, the callbacks multiply, "what function was it that did this? What file was that in?", the bindings start tripping over each other, it quickly turns into another level of problem at size and when it gets to the point it does it's big enough to be real work to refactor.

At the scale you are talking about sure, raw HTML, a handful of global functions doing this and that and a few arrays and objects holding data, no problem. If you have (or work with) something of a different scale using jQuery I'm pretty sure you'll see for yourself and come to the realization I have. There's a reason for the rise of these frameworks and it isn't all fancy hipster nonsense. Well not all of it anyway :)


True, a good framework serves to standardize the parts of the code that are generic and makes the project easier for new developers to pick up.

I think that without frameworks, software developers would not have been able to move between companies so easily and salaries would not have gone up so much.


> I actively avoid front end work now.

My solution was to move back to native front end.

Still do web, but try to avoid it.


I think a lot of people find developing applications using things like WPF and QT (and probably JavaFX, too) to be more enjoyable than the modern web stack.

But those same people also probably worry when they see that a huge percentage of job postings involve front-end web development.

The sense I get,though, is that while there are many web-focused jobs available there's also a ton of competition for those jobs. Whereas with native front end development, there's less demand but also far fewer developers qualified for/interested in the work.


It can be misleading too. Desktop frameworks date from a time when there was no distinction between backend and frontend developers. There were just software developers, and they were expected to be able to write algorithms and UI and whatever else was necessary to ship the app.

This led to a lot of ugly UI, but also pretty tight low latency UI (compared to the web).

It also impacted job descriptions and the way people think about hiring.

I am the lead developer at a firm with about 25 software developers, we do JavaFX GUIs when we can. We do not mention this in job specs. We do not hire for "frontend" guys specifically. Writing JavaFX code (or WPF or Qt) is just too easy to bother doing a specific candidate search for them - any competent dev can learn these frameworks quickly (and they do). The primary reason to search for UI specific skills in the desktop world is to find people who truly understand usability and graphics design, which is a separate skillset to what the modern kids call "frontend development". There are lots of web UIs out there that look superficially attractive as they just imported a stock CSS theme but which are actually confusing, nonsensical or simply can't scale to the addition of more features. UX design is as much about figuring out your user stories and workflows as it is making nice graphics.

In the case where developers need to do their own UI design, I prefer to just train them and push them to consider appearances when doing the work. It's easier to train someone how to make an attractive-enough UI than to train them in great software engineering. So ideally you'd have two specialists tag-teaming but when that isn't possible, desktop UI + some training is the way to go.


I don't worry that much, because iOS and Android are also native for any application that actually cares about UI/UX, so there are lots of opportunities, specially for applications that aren't yet another CRUD app.


and let's not even talk about NPM which is apparently dead and "you should use yarn" https://github.com/electron-userland/electron-builder/issues...


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.


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/


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...


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.


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.


It's a rather narrow take.

Software exists to solve user problems (for varying definitions of 'user' and 'problems').

Some problems are time/cost related, and software can automate some of those things to solve that problem.

But then some problems are preventative (or rather, the time and costs prevent things) so software can actually enable new things to happen, like letting the blind use cameras, or enabling more restaurants to do deliveries.


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....


Not generally. Machine engineering, maybe, but e.g. civil engineering creates a ton of jobs in construction.


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.


I agree that software does not just have to be about destroying jobs, but people are often working on projects that will kill jobs and won't acknowledge it.


In my experience people have always acknowledged it. Now did they care is another question.


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/) 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.


> 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

2: https://github.com/chentsulin/electron-react-boilerplate/blo...


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.


> 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.


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.


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.


>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.


One of the biggest lessons I learned early in my career.


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.


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.


>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?


"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.


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.


Because JS drives the cloud, and cloud is the hype.


Original site appears to be down, but Internet Archive has a mirror: https://web.archive.org/web/20170727012317/http://lucasfcost...


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.


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.


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.


> 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.


Yearly releases combined with a transparent process track for new features and fixes would be nice.


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/


> 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.


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-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.


"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.


Hi, Lisa,

Thanks for your feedback and for providing such interesting facts.

I really exaggerated in that hyperbole. Thanks again for pointing this out.


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.


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.


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.


Downvoters, do u care to elaborate?


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.


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.


Languages usually have a technology that drives their popularity. Javascript has the browser, and in my opinion the browser is the reason for most of the fatigue. Sure call it FOMO, and of course it happens in other domains, but web development has it particularly bad.

For example compare iOS development vs web development.


Are you saying framework proliferation and the "million modules problem" are not a pain in a non-web application?


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.


I bet the author use space instead of tab.


If you write JavaScript and don't use two spaces for indentation you're being intentionally obtuse.


What why?


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.


> 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.




Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: