> It’s like walking into a restaurant and finding out that they have all your favorite dishes and every one of them is free and complaining about how long it’s going to take you to read over the menu and make up your mind about it.
I suppose it's a matter of perspective. For me, it's more like walking into used car lot. Most of the cars have lost (or voided) their warranties. Some are certified pre-owned. That one in the corner looks nice, but I don't know how to drive stick, and am not really interested in learning. At least it's not a custom gear box, like this other one.
I can look at the new car lot across the street, but I'm not sure I want to be the first to use one of those self-driving electric smart cars. It's neat, but I'd rather stick to proven standards, and gas stations are more common than charge stations, anyway.
And I could probably get to where I'm going with just a bicycle.
Also, the problem with big chain restaurants with a thousand things on the menu is not reading the menu, it's that none of it is very good. Much rather eat at a small restaurant with 5 things on the menu that are all excellent.
And the other problem is there are 23 kinds of bespoke artisanal ravioli and maybe it was handmade by a Michelin chef or maybe it's from a bootcamp graduate that spent two weeks learning how to blog, star things on pinterest, and require('can-of-chef-boyardee')
I don't think comparing an over abundance of JavaScript libraries with a big chain restaurant.
It would be more like going to a huge open air market with hundreds of stalls each serving a few dishes. The dishes range from amazing to simply mediocre. You have simple three ingredient dishes to dishes that require weeks of preparation. Some are served modestly while other are delivered on a spinning plate by a server on roller skates singing the latest pop songs.
The downside is that most of the stalls are serving dishes that depend on dishes from other stalls. So when the maker of 'left-pad-thai' tears down his stall without warning, everybody at the market starves for a while.
And also a real effect in restaurants. Think it was like a study in supermarkets they used as an example where people were much more likely to buy a product from a free sample if there weren't too many different options to choose from.[0]
You're thinking of the 2000 supermarket study by Mark Lepper and Sheena Iyengar[1]. But it turns out that most attempts to replicate the result failed (but some succeed)[2], so there seem to be circumstances where too much choice is paralyzing, but they haven't been identified yet.
Note that there is no reason to think that the first study was flawed (as I mentioned, some careful reproduction attempts do succeed in producing similar results), only that there seems to be an unidentified additional factor that controls whether too many choices results in lower sales.
The mystery factor could be something as simple as whether shoppers routinely bought jams and jellies, or if the purchase of a product in the category would have been unusual for them.
Ya was actually trying to think some of it through. Maybe the 6 jams they narrowed it down to were the most popular so increased likelihood of noticing one they liked? Or does so many choices always cause angst, but if you were planning to buy anyway it won't stop you? Have actually done past work optimizing lineups of consumer goods products, and guys i worked with used to joke that it was a cycle where the product lineup would creep up over a few years, then every so often someone would come in and simplify the lineup down to 3 options, then would start creeping back up again.
Unfortunately, all cars come with a 10.000 page driver's manual since all levers, gadgets and gauges are completely different, and if you look carefully, they probably have spent a lot of time reinventing the wheels for no obvious reason.
The restaurant comparison actually makes total sense. Whether you use web technology or whether you go out for food, it doesn't matter what you get, the end result is going to be shit.
If Javascript is the native implementation, Svelte - The magical disappearing UI framework (https://svelte.technology) bring back all the familiar native Javascript generating at build time, not runtime.
It give you a clear idea how it works like RISC V hardware being open source and allow you to see what going on down to the logic level.
JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month.
This is why universities teach computer science rather than just programming. Learn about programming language paradigms - procedural, object-oriented, functional, etc; the language itself doesn't matter. Learn about relational databases. Distributed systems. Computer architecture. State machines. Formal grammars. Language translators/compilers. Data structures. Algorithms. Computational complexity/big O notation. That's the theory side of things.
Understand Unix, version control systems, and how to log into and administer remote systems. Learn about what TCP/IP is and how higher-level protocols like HTTP relate to it. Ensure you're able to write a program in at least one language that can talk to at least one type of database, and present at least some sort of user interface. That's the practice side of things.
These things will pretty much set you up for life. By themselves they're only a start, but you can pick up the rest as you go along, lazy evaluating any expertise you need with specific technologies as you go along.
As far as front-end web development is concerned, all you really need to know is JavaScript, HTML, CSS, and the DOM. Pick an abstraction layer on top of that if you feel it helps you, but don't feel that you need to know about every framework out there, because new ones are being generated faster than you can learn about them.
And yes, becoming good at this takes many years. But ensure that whenever you're investing time to learn, it's something that will last.
If you are a computer scientist by training, then you will approach front-end development differently - beginning with the technical evaluation of the available frameworks.
And regarding "set you up for life", I think this is a message that should get more attention among young developers. You may believe when you are young that neural plasticity is an infinite resources. You will find as you age that that is a false assumption. Neural plasticity, like beauty, is fleeting. Invest it in things that have some chance of lasting a lifetime. Front-end frameworks are not one of those things. I've been doing front-end work on and off for 25 years, and have used a couple dozen frameworks. The specific skills have a lifetime of perhaps three years.
Now in my case I do have a CS and engineering degree, and I also do a lot of back-end work. And clearly I enjoy the front-end work or I wouldn't keep coming back to it year after year. BUT BE FOREWARNED - it's NOT a good long-term skills investment.
You say you've been doing front end development for 25 years, and also that front end frameworks have a shelf life of 3 years, but of those 25 years, how many were spent working with front end frameworks? At most I'd guess 10 years, but probably much less – the frameworks simply haven't existed long enough. You say the shelf life for front end frameworks is 3 years, but I constantly see companies building software with backbone, knockout, ember, and countless other front end frameworks that have existed for nearly the entire lifetime of front end frameworks. Sure, if you pick the latest fad you'll find a framework that has only been popular for a few years, but that hardly means it'll die off in the next couple years.
I didn't say JavaScript framework - I said front-end framework. Started in 1988 with a framework called Dataviews. Was the bee's knees in the late '80s and early '90s and sadly is superior to the majority of present-day frameworks. Next framework I developed in was X-Windows. Then Motif. Then Generic Logic (awesome, and still exists!). Then MFC. Then Tcl/Tk. Then Netscape-era HTML. Then IE5-era HTML. Then IE6-era AJAX. Then ASP. Then ASP.NET Web Forms. Then XAML. Then ASP.NET MVC. Then JQuery. Then Bootstrap. Then Angular 1. Then Angular 2. Then WebComponents. Then React. Then ... the pace has been picking up! And I've only listed frameworks which I have used to build commercial apps - thus leaving off lots of other stuff I've played around with over the years, like Next and Mac and Android and iOS.
>but that hardly means it'll die off in the next couple years
It's great to know basic principles, and I highly recommend that.
If you want to do frontend though, you need to know some concrete things. And then you choose a framework (or more likely, some frameworks, since there's no 'one-size-fits-all'), and it no longer becomes supported. At that point you begin to feel Javascript fatigue.
But ensure that whenever you're investing time to learn, it's something that will last.
Which web framework is that? Probably none right now. But waiting is not an option, websites need to be built today.
You're investing the time to learn the architectural patterns, which will likely either stay relatively similar over time, or morph (which will be easier for you to pick up), or they're drastically change, in which case you'll probably have a level of understanding for why they changed. And yeah along the way you'll implement stuff today and that's an important component, but learning is as much about the long game as it is the short game, and you can play that long game without having too much anxiety over these choices
Exactly. I've met too many front-end devs who are unable to separate the architectural pattern from the implementation of the library they are using. They have the larger mountain to climb when needing to learn a new framework.
That's actually kind of interesting. HTML/CSS/JS really are the framework. It's already a great separation of concerns (HTML for data/content, Javascript for behavior and logic, and CSS for presentation). Everything on top of it just seems like implementation details.
If you want to display documents, sure, I agree. If you need complex UIs, manually updating DOM without any kind of abstraction is definitely not a right choice.
You mean like altering attributes directly on elements (and proud that they had encapsulated the code in a reusable function) instead of adding/removing a class?
One of the reasons that I think it's more helpful to interview for patterns (and anti-patterns) than it is for algorithms. Especially for the front-end.
You misunderstand his point--with a few exceptions, what these frameworks are doing is fundamentally not difficult for someone with practice in the broad base of knowledge that falls under computing science
Sure, the frameworks aren't doing anything fundamentally difficult. That's why there are so many. But they are doing things that take design, coding and craftsmanship and many hours of testing and debugging to get right.
.Net has shifted a bit. I know companies that invested in Silverlight and are now rewriting that software, for example, or wrote something using Visual Basic .Net and now have to rewrite it for C#, or have software in Webforms that they have to shift to MVC, and software in MVC that's being shifted to MVC + [insert modern javascript framework here]. And once they get to that last one, they have the same problem as everyone else has here.
And now that .Net Core exists, it's almost a guarantee Microsoft will start shifting more and more of its resources to that, so companies eventually will have to invest significant resources rewriting their libraries for .Net Core, which might never support all the features they rely on.
The whole tone of this post feels a bit sketchy to me. Not everyone gets 100% control over what they have to learn.
> JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month.
Or those who work for (or with) those whose priorities are poorly chosen, and who don't have a veto.
I've largely avoided having to deal with JS in its recent pathological era, and I'm very very thankful for that. My attitude toward those less fortunate in this regard is sympathy, not contempt.
Agreed! There's merit to the perspective here, but it speaks mainly to developers who are 1) very good at picking up a new framework and getting it to work, and 2) largely in a position to make their own technology choices.
I've found it much harder to pick up some of these frameworks. Even ember, which should probably be one of the easiest for me as a rails developer (former? I sure hope not...) Learning a framework is, for me, a big enough undertaking that the analogy to ordering something free from the menu doesn't really hold. Some people are much quicker with this than I am, though.
I'm also, unfortunately, really not in control of technology decisions (in spite of the fact that making these decisions is written in my job description signed all the way up the chain - in many orgs, you have to fight like a banshee to exercise this right, even if it is explicitly listed in your job responsibilities!). I can sometimes influence them, but one of the reasons people get into such intense arguments about what framework to use is that you're far more productive with one you already know. If you're good at Ember, you might not want to switch over to React, and vice-versa.
Honestly, if it were up to me, I'd probably stick with the integrated rails app for now, unless there was a very compelling reason to do otherwise.
That says a lot about the kinds of apps I develop. I personally think that the amount of complexity introduced into web apps through the SPA approach is substantial. There's no saying it's strictly right or wrong, just something that needs to be balanced against what you get out of it.
There was a time when a spreadsheet, a server, a database, a web app, all took great skill and cutting edge knowledge. The day will probably come where relatively rich web apps are much simpler and straightforward. Until then, there is a huge opportunity for people who can learn this and leverage the power. There is also a huge opportunity for people to massively over engineer their systems for "no reason", except that there is a reason - resume building. I'm not naive, I was around in the days when if you didn't know "EJB", you might have a harder time getting your next gig, which lead lots of devs to introduce EJBs into apps that had no need for them, mainly to get the experience and skill.
If developers chose technologies based on what their project needs, rather than what their resume needs, I suspect the software development world would be more conservative in applying new technologies. As it stands, there is a lot of incentive to be unnecessarily (possibly even destructively) cutting edge, because that's how you get the experience.
I don't necessarily blame the devs, this is the game.
As far as software development is concerned, all you really need to know is C/C++, a little assembly to get by in gdb, and -nix system calls. Pick an abstraction layer on top of that if you feel it helps you, but don't feel like you need to know about other languages out there, because new ones are being generated faster than you can learn about them.
Yes, I'm being facetious, because that purist approach is impractical in the job market. When I left college C/C++ was what I had done the majority of my development in. I wrote some C yesterday. But nearly all of the development I have done since then has been in a higher-level language like Java, C#, Perl, PHP, Python, or Ruby, all of which I had to pick up and learn for some job somewhere outside of work. And the answer is that learning these things did help me, as I had practical experience with these languages. It's just way worse for front-end these days.
The thing is that the "cool job" job market for front-end guys seems to want people that know the new hotness, and the hotness changes a lot. If you want a job at Facebook or Google etc, it is easy: learn the framework they use in house (React/Angular/etc.) But what if you aren't capable of running the Facebook/Google interview gauntlet, as many are?
You just want a job using the skills you have and are willing to learn. You know JS/HTML/CSS/jQuery. You know how the underlying core concepts work. However, that job posting says you need AngularJS or React or Vue or whatever experience, and your last job was all Knockout.js since the company was older. When you go for the interview, they will take the person with proven experience in the trendier framework. So your job market is fragmented, and if you want mobility between companies -- a big deal when working with startups that might be uncertain -- you have to keep up on all of them to some degree.
I went to a "front end" meetup with some friends that work in typical dev shops not too long ago, and the amount of arguing over frameworks and JS tooling was terrible. Lots of spouting off the opinions of your favorite opinionated framework and a good amount of contempt for the wrong team. I shared a similar opinion as you -- none of them will last and all is old is new again -- and I was practically ignored as an old man unless I was talking about websec concepts.
I feel I've done that. Started as a sys-admin, moved to programming, all that.
The problem is that more and more my clients are looking for live data, push notifications, video-streaming, etc. Sure, I can throw together really solid "classic" websites all day long, with facebook integrations and payment processing and whatever else.
But more of my stuff is requiring reliable well-documented javascript. And since I've got to install at least 3 different tools to get imports working well, that's always going to be a pain. I shouldn't have to run my code through 3 different preprosessors to get common language features.
Maybe those who are downvoting haven't been in the industry long enough?
I started in software development when I was 18. Fresh outta high school. I have never been unemployed for more than a couple of months between gigs. I don't have a degree in compsci, either.
What I do have is all self-learned compsci knowledge. Maybe not perfect knowledge, but anything I am missing I can look up and learn. I am always willing to learn - always.
That's really the key, too - to not be unwilling to learn. Too many fall in the trap of stagnation. But the compsci basics, as noted in the above post, are crucial and always relevant. I first got the inkling of some of them when as a kid I did translation from Fortran, Pascal and C to BASIC (where I started in the 1980s).
Today - to keep up my skills - I am continuously working and improving my knowledge of ML and ANN techniques, as that is what is becoming more in-demand.
I am still angry that ExpressJS got all f-ed up. It was good but it is essentially dead. There seems to be no major replacement for that. I almost wonder if IBM fucked that up intentionally.
Is it that there are important features still missing, or that there are bugs that aren't fixed?
Reason I'm asking is that I was under the impression that ExpressJS was mostly considered feature-complete (with everything else middleware through NPM), and I'd probably still reach for it the next time I need a Node webserver. I'd rather not make a mistake on that front!
"As far as front-end web development is concerned, all you really need to know is JavaScript, HTML, CSS, and the DOM"
This is not true in practice.
In fact, really far from reality.
As evidence I offer that most of the best shops with the most talented people are using frameworks - in fact - they are often the source of the best frameworks.
Nobody is writing 'raw' web apps these days, because there's a huge amount of your roll-your-own code that you'd need to write to even do basic things.
The web before jQuery to handle plaf/frag was rubbish.
Newer frameworks fortunately obfuscate some of the need for jQuery, but still - you need a framework, pragmatically speaking.
Not only are frameworks in most paradigms essential - they change very rapidly. This is the problem.
Finally - HTML, CSS, DOM and JS - just themselves are iterating very rapidly.
The only nit I have to pick is that new frameworks don't have to deal with as much platform fragmentation as jQuery had to paper over in it's heyday, in part because all major browsers are now somewhat more compatible and standards compliant, in part because any missing or incompatible functionality can usually be dealt with by using a polyfill, and in part because evergreen browsers have sharply reduced user updrag.
I think there might be a 'purist' strain here on HN.
Most complex/serious web-apps use frameworks as a given. There's just too much to have to do without them, though it depends on what you're trying to do, surely.
I'm a prototyper, so people often come to me first to vet new ideas. Often times this means implementing a feature on an existing product platform. When I started doing this 5 years ago, I was working with a new language every month. It was ruby one day, C# the next, and I'd go to sleep every night praying next week wouldn't be PHP.
These days everyone is using javascript. In the last year I've done countless javascript projects and one project in java. I can't tell you how refreshing it is to not have to brush up on syntax and install a suite of tools every time I want to work on a new product. Nowadays it's just clone the repo, do a npm install, and you're up and running for the most part. It's lovely.
I agree with his point, but I think he mischaracterizes JS fatigue. He's right that it's exhausting trying to keep up with all of it, and that's part of JS fatigue, but the other side is the endless hype machine that's internal to the tech community, where our media is an endless stream of "look at my new framework!" and "you're doing react wrong!" and "why functional is making a comeback!"
We do it to ourselves not just by continually stuffing the buffet with every possible option, but also by making our community dialogue an endless infomercial, which has a big influence on trying to keep up with it all. We have conflicting desires to contribute and to self-promote, and the result is an aggressive bazaar in which you need to consciously filter out 90% of the noise so you don't get overwhelmed.
I agree with you. IMHO I see it as good thing. Maybe 6 projects bring so little innovation comparing to project they're trying to replace. But then somebody will take the good parts of all those projects and create something that is significantly better. Innovation does not grow on trees, there is slow and bumpy road to it. :-)
> Nobody is ever going to know everything there is to know about modern web architecture
I think this is the root of the sentiment that is expressed as "JS fatigue" and bullet train rides etc.
I'm torn though. On one hand, this is equivalent to saying: Nobody is ever going to know everything about an operating system and how a machine performs the operations we expression a high level language like, you know, C!
The thing is, we still were able to teach the abstraction of the single-machine computation model that C is abstracting in a single semester to the point of making new coders _operational_.
But I can't imagine trying to construct a course to teach "modern web architecture" in a single semester.
On the flip side, a lone developer who can chose their battles wisely has more leverage to produce something of value today than was ever freaking possible, ever!
I'm betting on the the new "OS" abstraction as cloud-native services (DB as a service, event streams as a service, mobile syncing as a service, heck, everything but your core logic as a service).
But by it's nature this world is redundant, competitive, multi-vendor, fractal-specialized and I only see that trend increasing.
So yes, one person will never know everything there is to know, the new skill will not be learning every framework, platform or service, but being able to grok the core nature and characteristics of your problem so you can apply the closest matching tool with the maximum leverage.
Essentially, the new skill will be to optimize for laziness :)
> I can't imagine trying to construct a course to teach "modern web architecture" in a single semester.
Well, see, you got a highly ambiguous term in there. Which of the following do you mean?:
1) Modern web page architecture
2) Modern web site architecture
3) Modern web app architecture
4) Modern web scale architecture
You could certainly cover the first two in a semester. And with those two as prerequisites, you might be able to cover the third in a semester. The fourth will require a whole term on it's own regardless (and I suspect the fourth is the sense of "web" that you mean).
I am not sure I agree that optimizing for laziness will ever be a skill. But indeed, I am not sure it's possible to know everything there is to know about just about anything. How can you ever be sure there isn't still something left to discover?
I am reminded of something I used to hear all the time: you learn something new every day.
Ha! Yes, my shorted argument of "optimizing for laziness" doesn't sit right, but the core of it how much your choices matter in what you are _not_ building.
- Cloud-based apps used to mean managing VMs, keeping kernels up to date, setting security settings on server configs. It doesn't have to[0]
- Mobile dev used to mean compiling platform-specific code and shipping it to app-store review. It doesn't have to[1]
- Storing state server-side used to mean running your own DBs and worrying about their persistence and multi-host-scaling. Don't even need a reference here since there a so many choices.
> Cloud-based apps used to mean managing VMs, keeping kernels up to date, setting security settings on server configs.
PaaS offerings where this kind of thing was not required were among the very early dynamically-scaled application platforms to get the "cloud" label. IaaS offerings where this is required and part of the price for greater control exist, to be sure, but have never been the only cloud platforms.
> The thing is, we still were able to teach the abstraction of the single-machine computation model that C is abstracting in a single semester to the point of making new coders _operational_.
> But I can't imagine trying to construct a course to teach "modern web architecture" in a single semester.
I'm calling shenanigans here. You're comparing "C by itself" to Javascript and the entire web ecosystem. To make that comparison, you'd have to take C, its standard libraries, and the entire POSIX API- which you're not going to be able to teach in a semester.
That said, I don't want to come off as confrontational, and so I will grant that the computation model (event loop vs. "single-machine computation) is obviously simpler for C. But once you start dropping down to the OS level (e.g. "What's a process/describe process states") you're getting right back into irreducible complexity.
In fact, when I was in school, my first CS classes were taught in C, but I didn't actually grok it until later, in my Microprocessors ECE course, where they actually taught us machine code first, then gave us an assembler, and then gave us a compiler.
The pedagogical benefit of Javascript is making the conceptual connection between "I'm writing this weird 'programming language' code" and "oh hey, that code actually made my computer do something I recognize!"
For folks of a certain age (and for fairness, I include myself in this category) it's possible to make that conceptual leap based on the output of a terminal. But very few laypeople use terminals anymore, so in a weird, topsy-turvy sort of sense, this lower-level programming language feels less powerful because its power is more abstract. By comparison, the browser-scripting language feels way more powerful, because hey look! it's got APIs for anything you'd ever want to do with a web page! Sure feels powerful to me!
> So yes, one person will never know everything there is to know, the new skill will not be learning every framework, platform or service, but being able to grok the core nature and characteristics of your problem so you can apply the closest matching tool with the maximum leverage.
And people still do that- even in Javascript-land. For me, one of the interesting things about switching to full-time "modern" Javascript is how much more time I spend actually reading the source code of the libraries I use. You begin to develop heuristics for evaluating dependencies rather than pulling them in blindly. Furthermore, the libraries I do use are much more lightweight than the ones I used to use in Ruby and (ages ago) Java.
Pretty rich coming from the complainer-in-chief of JS, the guy who advises not employing people who don't happen to agree with his personal take on how JS should be written.
I think the bigger problem is that we, as developers, don't appreciate risk and how to mitigate it. We always want to play with the latest and greatest tools, technology, approaches, etc, etc.
My advice to the teams I mentor is choose at most 1-2 risky areas and reduce/eliminate risk everywhere else.
If you have a new idea with a new team, stick with established tools. If you have a well-gelled team with understanding of the space, experiment with tools or approaches.
When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, success is unlikely at best.
>When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, failure is unlikely at best.
One benefit often overlooked is that during high periods of churn in an industry (let's specify JavaScript fatigue as a symptom of rapid churn in Software Engineering for Web Applications). There are more opportunities to quickly speed up your career. Fresh problems call for new solutions and fresh eyes to work on those problems.
The opposite of JS Fatigue is climbing the J2EE certification ladder - if we were all still building Struts/JSP apps then there would be no room for new ideas to flourish. I felt very similarly about Ruby on Rails in 2004, there was 4-6 years where someone early in their software development career to learn a stack, find work doing that tech and manage a team (exactly what me and several of my good friends did).
I see the proliferation of JavaScript tools as a massive failure of the vanilla js standard library and ECMA. Most of the stuff out there just rebuilds basic language features that would be standard in other languages.
We wouldn't need node, npm, typescript, angular, react, web pack, or most of the bazillions of libraries out there if vanilla js had reasonable defaults.
It's causing horrid fragmentations probably won't go away until js is replaced maybe 5 years down the road.
The best we can hope for is a c++ style solution. A new language that's basically a massive preprocessor on top of the original that fixes as much as possible. My hope is in typescript for now
I think node is the funniest example. "Yay we can run js on the server now! This is the future!"
But wait, what other language can't you run on the server? I can't think of a popular language in existence before js to take so damn long just to have a web interface. It took js ten years! Even rust has a web server and it just hit 1.0. Oh and node is still single threaded, something horrific for servers that usually have 16+ cores.
The problem is very accurately described as people trying to use every framework and every library all at once. Too many developers are neglecting their knowledge of the base language. JavaScript has become incredible in recent years, but you'll still find new projects being built incorporating jquery.
I have tried react redux and seriously people, after all your badgering and all of your carrying on. I still prefer vanilla es2015+ with typescript. I can do everything you can do sans MBs of extraneous client side code. I also have more control.
Use your tools for what they are useful for, stick close to the metal. You'll save yourself tons of grief.
Using vanilla js becomes a problem once you start building something bigger than a simple web page. Eventually you will end up with your own framework and new developers still have to understand how it works etc. It's totally fine if you are expert js developer and now how to structure and design your code for maintainability. But few hacks here and there, and you might end up with a mess.
Its really just an excuse for people who don't like JS to complain about JS being popular. They honestly hate the fact that JS is one of the most popular languages in the world right now.
You don't see a-lot of post making the frontpage of HN complaining about programing language fatigue, car fatigue or anything else with a lot of choice fatigue.
I don't hate it because it's popular. I hate that it's encouraging sprawling, insecure, fragile design. It slows my computer to a crawl, and all just to make the web-page render worse than if it wasn't used.
Sure, there are exceptions where JS is amazing, and absolutely necessary. But that's extremely rare, yet everyone thinks their news-site absolutely must have it.
Agree with the author 100%. We want tons of new JS tools and frameworks out there so we can learn and evolve newer and faster ways of developing. I still remember when jQuery first came out and how earth-shattering that was. This inspired so many more devs to create better and easier to use tools.
In hindsight of course it's obvious. jQuery should just have been built-in from the beginning! And all browsers should have always behaved the same and should never break compatibility with never versions. Then jQuery would never have needed to exist in the first place. Problem avoided.
fuck this dude. typical contractor that doesn't have to maintain unsupported backbone.js based applications. just shits something out using the latest technology then fucks off
It means security is hard. And yes, we keep finding security issues (in web specs, not just in implementations) due to two different people designing two subsystems and not considering their interactions, or not even knowing about the existence of the other subsystem.
Finding a sane solution to this problem would be wonderful; I haven't thought of one yet.
Security is it's own separate issue. There are best practices that must be observed in all frameworks (preventing xss, sanitizing user data). Of course sometimes there are bugs, but the OSS community resolves those rather quickly.
In general, if I don't use something, if it's outside of my focus, that shouldn't harm security. As an example, given your two secure systems which can combine into an insecure system, if I don't use that second system I should be good. If I do, I better know their interactions.
This argues for a small reliable toolset rather than having every contrivance in the HomeDepot center aisle on my belt.
Not full stack, definitely not fool stack, just stack.
In some respects the problem of “too many libraries” is the same issue we have with news headlines, etc.: too much going on, and not enough value placed on curating.
Right now everyone just wants to build things full-time. As an industry, it would make a lot of sense to have expert developers who spend some non-trivial amount of their time just on curating: writing down what actually works, what doesn’t, etc. Maybe a “stack overflow” for software packages. And after awhile, it should become expected that you consult those curated lists first, every time before you build anything else.
The fatigue comes from having to constantly keep up with JavaScript and everything new.
5 years ago building JavaScript page was straight forward. Most of the time you would include JQuery from a CDN, and code in a server side template. If you were really serious, you used something like Backbone Or Ember (both very new). But the options were limited. JavaScript was often limited to AJAX requests, a modal or two, and some JQuery plugins. Very few people were "JavaScript Developers." They wrote JS for their webpages and Ruby/Python/Java/Whatever for everything else.
But NodeJS and ES5 broke open the floodgates for JavaScript Development by elevating Javascript from something only seen in a <script> tag to a fullstack language. With that came a surge of new libraries, frameworks, methodologies, and opinions. It's exciting when a community grows so fast and puts out so much. Many old Javascript patterns and styless were declare obsolete and new ones were created.
A new framework and stack seemed to come out every month. Suddenly Javascript needed build scripts and a pipeline. Grunt came along to solve that problem. Which was replaced by Gulp. Which was replaced by npm scripts. And now yarn? This rapid iteration of technologies appeared all across the Javascript ecosystem. Backbone, Angular, React, Vue, Angular 2. Flux, MobX, Redux. But these switches are as much a change in fashion than real improvements. But either way, the change takes effort to learn and implement.
It turns out learning a new framework, library, pattern every 6 months is tiring. Its fun to learn something new. But having to constantly be learning, and at such a high rate, takes a lot of effort. That is the fatigue. The fatigue of every time you open up HN, there is some new JS library that will replace whatever you are using now. And if you don't switch, you are an idiot using old technology. Or at least the community makes you feel that way.
New frameworks keep being made, becoming extremely popular, and then being dropped for the next new framework despite that they often do basically the same thing in roughly the same way. Some people are getting tired of this.
Fatigue can be translated to "feeling worn out and overwhelmed". Basically, so much change you feel obligated to keep up with that you want to quit. I feel this a bit, there was a time when I could keep up with the changes going on in Javascript, but was overwhelmed by the changes happening in C# and Java (which for a time were going fast and furious). Now I'm ok with C# and Java...but Javascript is going berserk. It comes and goes.
Thank you guys for explanation. I had feeling that it must be the thing you've described, but was not sure. I was missing js fatigue of what (context). To give example: js fatigue of new frameworks, js fatigue of constant changes... Anyway now I understand. PS: I don't feel js fatigue of any kind and actually like the pace js is progressing. I just don't jump on hype train anymore. Rather wait till things settle and prove their existence.
I definitely appreciate the sentiment. Its true, the JS ecosystem has exploded and there's been a lot of shrapnel flying around for quite a while. It feels like the smoke is starting to clear and some different groups of consensus are starting to form about some generally reliable patterns and tools which makes things easier.
For me, having learned web development in a time when it really was the smallest part of what could be considered development, the tooling and techniques are at once awesome and horrifying. :) The browser's transition from a much more useful version of Gopher to a platform in and of itself has created a lot of opportunities and challenges, and while JS still isn't my favorite language by a long shot, its gratifying to see its progress.
> I recently built an app prototype in a couple days using nothing but vanilla JS and the DOM. I was literally two days in before I installed a single non-dev dependency. Guess what? It was fine.
IMHO a good strategy to reduce the cognitive load (and limit dependencies).
I loved this admission. There is a lot of awesome, powerful, fancy stuff out there today, but you can get a lot done with the vanilla approach. I was introduced to JS back when AJAX was 'blowing up', and today still prefer to hack quick ideas w/ at most a jQuery import
It's very hard to know everything. I made a programming language and I'd be screwed without the manual to refer to. Recently I was utterly surprised by something that was implemented ("you can do that?").
What was it ... aha, I remember: introspection over exception handling sites. The ability to just get a list of the frames through an API, and then directly pick one and jump to it (regardless of whether it catches the type of exception being passed to it that way).
> "From this point going forward, no single human being is ever going to have a completely full grasp of every corner of JavaScript, CSS, and Web APIs"
This. Reading the comments at HN and other places gives you the impression that there are people who do know everything, but that's not the case. There's just lots of technical people here who are experts in various fields, so there's always experts to comment on things.
I picked EmberJS because of javascript fatigue - it makes most choices for me and gives me some guarantee that it will work together.
But even that fails in practice: sourcemaps don't work properly so you don't get to debug your original ES6 code and more issues like that. Meanwhile there's no clear focus on where the framework is really going (routable components? working pods in ember-cli?, etc)
Could some of this fatigue be due to to JS being so damn hard to troubleshoot? I'm still struggling with troubleshooting JS after years of using it on and off. I still console log everything and keep refreshing the page. Is there a more sane way of doing it?
JS fatigue is not a fake problem, it's real and different from other forms of fatigue.
The metaphor used in the article i.e. 'learning another language every 6 months' is not apt - because those are not 'new languages' and they are not 'new and critical parts of the landscape' for any specific vertical.
If any one of those languages were to have the same degree of evolution as JS ... then 'fatigue' would also be an issue.
JS has a pernicious problem for a few reasons:
1) The language is quirky, fragmented, there are still no 'agreed upon' approaches to do many things even outside the context of libraries. There are really no analogues to 'prototype' based languages, which possibly makes it great for some things, but it's not great for those wanting to use more classical ways of thinking about information organization.
2) Runtimes, particularly browser - are highly fragmented, and there's scant documentation. Safari docs for Mac/iOS are literally empty in some spots.
3) JS doesn't come with a lot of things 'baked in' to the language that most others support, so discovering those 'standard libs' has been a painful process.
4) Due to the limitations of the browser, we see a lot of churn in frameworks.
Though there is some advantage to 'community participation' - the pernicious problem is most of the churn is not fully forward. It's 3 steps forward, 2 steps back, and a step sideways.
There's a lot of time and investment in learning something new that won't exist in the future - that's costly.
Learning Lambda's for Java 8 is probably worth investing in for Java programmers ... because Java 9 will surely use them as well.
Taken as a whole - there is an enormous amount of inherent 'reducible complexity' in the JS ecosystem, which any JS developer intuitively senses.
If someone were to have made up their mind about JS right from the start, and had come up with some good standard libs ... and the evolution of the language were to have been more 'version' and less 'pick and chose' (Es6 means something different in each environment) ... then the complaint would be valid.
It is what it is ... but JS fatigue is a real thing.
You have a lot of great points but one area where I disagree is in this statement:
> Es6 means something different in each environment
Ecmascript 6 (or Ecmascript 2015) by definition is a specification that browsers (and others, such as nodejs) adhere to in order to support that version of JavaScript. The api and functionality are designed to be the same. So Es6 means the same thing no matter the environment. However, there places where they haven't finished implemented ES2015 quite yet.
Most modern browsers have 99% of Ecmascript 2015 all implemented. [0]
And for those that don't, there's always transpilers like Babel or TypeScript.
Nodejs strikes me as an unfortunate consequence of having js in the browser and a drive for reducing the complexity by having the same language on the server.
Example of use outside browsers: Windows and OS X scripting, classic ASP, Pebble watch, MongoDB database, Adobe Photoshop PDF et al, LibreOffice, Unity game engine, Qt, GNOME Shell, Ubuntu Touch, Chromebooks.
I used JavaScript as a web developer for 15 years, but did not like it. It wasn't until I started with NodeJS three years ago I learned JavaScript in depth. It's when you grok closures, events/async/concurrency, prototype, objects, and commonJS modules it starts to get fun. There where a lot of headache going from serial programming to parallel programming like the pyramid of doom, Christmas tree from hell etc, until I learned to manage it.
When CPU's get more cores instead of getting much faster, concurrency is the way to go, and it fits JavaScript well. You should have raised an eyebrow or two reading this, as JavaScript is "single threaded". That just makes things more simple though, if you know how to write event based code, like handling clicks on a web page, you already know how to write distributed systems and can scale beyond a single CPU or server.
Microsoft tried to make vbScript an alternative to JavaScript. vbScript is a good language, but JavaScript is better. For example, how to make a custom object in vbScript:
Class foo
Private barval
Public Property Get bar()
bar = barval
End Property
Public Property Let bar(b)
barval = b
End Property
Private Sub Class_Initialize( )
barval = 1
End Sub
End Class
To make an object in JavaScript:
foo = {bar: 1};
Before NodeJS existed, most people, including myself thought that JavaScript is a stupid language only used in browsers. I was also aware of NodeJS for at least two years before I finally tried it. I thought it was stupid why the hell would you want to code JavaScript outside the browser I thought. After maybe one year of learning, walking through the swamps, I finally saw the light. The most revolutionary I think is the module system in NodeJS, it's what makes writing huge programs in JavaScript manageable. Because of this many JavaScript programs now a days comes with thousands LOC tested and hardened in production, while the actual code you write and maintain yourself is only like one hundred LOC.
I think the NodeJS module system is maybe hundred years ahead of its time, it's right in front of us, but few people seem to notice. And in the direction we are heading now it will soon be forgotten (ES6 import). People use NodeJS modules like imports and couples the code instead of decouple. Sure it works fine for a while, but sooner or later the project will grind to an halt because of code complexity.
What? The engine is written in C, but all JavaScript engines are written in another language (C being the most popular) because it is an interpreted language. The engine isn't written from scratch because it is the V8 engine from Google. Of course the system binding and package system is written specifically for Node.
node.js doesn't just resemble JavaScript, it is JavaScript. Like ES5 standard JavaScript, and (very soon) ES6 standard JS as well. It uses the V8 JS engine.
The only non-standard features of Node.js has been the module system (CommonJS), but even that will be ECMA standard as of next version.
Agreed. I use ES6 modules regularly (via Babel compiled to CommonJS, and also Rollup). Unlike CommonJS, ES6 modules have the advantage (and disadvantage) of being statically resolved, which permits tree-shaking (but denies dynamic resolution of imports like CommonJS).
The "that" in my sentence refers to "module system", not "CommonJS", but I agree my sentence was unclear.
You can't learn every library or every tool but you can learn how the language actually works. For example, if you think JS has floats and integers, you have some reading to do. If you think "array" is a type, take heart, because you can learn why that's not correct. If you can't decide whether to use Ember or Angular, maybe you can grasp how closures work.
Before React and Redux and Gulp and whatever else, understand how the language works. Pretty please.
I suppose it's a matter of perspective. For me, it's more like walking into used car lot. Most of the cars have lost (or voided) their warranties. Some are certified pre-owned. That one in the corner looks nice, but I don't know how to drive stick, and am not really interested in learning. At least it's not a custom gear box, like this other one.
I can look at the new car lot across the street, but I'm not sure I want to be the first to use one of those self-driving electric smart cars. It's neat, but I'd rather stick to proven standards, and gas stations are more common than charge stations, anyway.
And I could probably get to where I'm going with just a bicycle.