Why I’m thankful for JavaScript fatigue
medium.com
medium.com
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.
npm ERR! 404 Registry returned 404 for GET on
https://registry.npmjs.org/can-of-chef-boyardeeIt 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.
[0]i forget some business class i think
[1] http://faculty.washington.edu/jdb/345/345%20Articles/Iyengar...
[2] http://www.csmonitor.com/Business/Donald-Marron/2012/0719/Th...
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.
I thought we were supposed to help write the manual by contributing copy edits to the sales flyer...
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.
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.
> 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.
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.
http://rubyonrails.org/doctrine/#integrated-systems
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.
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.
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.
That's because front-end development is based on a core of HTML/CSS/JS which itself does not lend very well to architectural paradigms.
People 'starting out' on the front-end, in some ways, never learn how to write propers software. They've been using weird ideas from the start.
They end up reinventing the wheel repeatedly.
There's a whole lot of JavaScript devs out there that think they are front-end devs. They aren't. There's nothing wrong with that of course.
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?
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 problem is that more and more my clients are looking for live data, push notifications, video-streaming, etc. Sure, I can throw together really solid "classic" websites all day long, with facebook integrations and payment processing and whatever else.
But more of my stuff is requiring reliable well-documented javascript. And since I've got to install at least 3 different tools to get imports working well, that's always going to be a pain. I shouldn't have to run my code through 3 different preprosessors to get common language features.
I hope asm.js solves some of these problems.
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!
There was an express.js 5 alpha version already last year, but then there was no follow-up since.
Insightful and entertaining discussion from begin of year: https://github.com/expressjs/express/issues/2844
Seems like Doug (maintainer of express.js) could need some help but is he prepared to delegate work?
It has happened before; TJ (former maintainer of express.js) got a burnout and quit.
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.
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.
HN itself probably doesn't use a framework.
Lisps tend to blur the distinction between application code, library code, and framework code somewhat, at least with well-designed applications.
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.
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.
>but that hardly means it'll die off in the next couple years
History says you are wrong.
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.
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 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 am reminded of something I used to hear all the time: you learn something new every day.
- Cloud-based apps used to mean managing VMs, keeping kernels up to date, setting security settings on server configs. It doesn't have to[0]
- Mobile dev used to mean compiling platform-specific code and shipping it to app-store review. It doesn't have to[1]
- Storing state server-side used to mean running your own DBs and worrying about their persistence and multi-host-scaling. Don't even need a reference here since there a so many choices.
[0] https://www.ibm.com/developerworks/cloud/library/cl-bluemixf...
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.
> 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.
At any rate, just my 2 cents. :)
Exactly! For better or worse, this is the baseline attitude needed.
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).
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.
Should this be success is unlikely at best?
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).
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
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.
Netscape Enterprise Server supported Javascript as a server-side language, similar to VBScript or PHP. They called it Livewire.
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.
Can you elaborate why you called the problem fake? Not disagreeing, genuinely curious as to why you called it that.
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.
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.
JS evolution is perniciously different than the evolution of most other languages.
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
Ha ha! A fatigued JS developer complaining about hipster Haskell things!
What does that mean for security, given that two secure systems combined can result in an insecure system?
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.
Finding a sane solution to this problem would be wonderful; I haven't thought of one yet.
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.
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.
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.
IMHO a good strategy to reduce the cognitive load (and limit dependencies).
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).
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.
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)
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.
From nodejs.org:
> Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript 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.
(also, Node.js was built in C++ and JS)
The "that" in my sentence refers to "module system", not "CommonJS", but I agree my sentence was unclear.
Everything else is just Stockholm-syndrome.
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.
ref: https://en.wikipedia.org/wiki/JavaScript
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.
As a language, it has more warts and less features than many other languages, but it also is unimposing and does not get in your way.
It could have been much better though.
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
foo = {bar: 1};
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.
Not quite.
JS is a great language for doing async.
I much prefer Node.js over CGI, Java or Ruby back-ends.
But yes, there is some craziness given how for so many other reasons, JS is not a great language.
> 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.
Before React and Redux and Gulp and whatever else, understand how the language works. Pretty please.