It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now!
It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.
Make a framework? Post it on github, go to a conference, write some blog posts, get your framework its own conference, ?, profit! (now I'm thinking of that Southpark guitar hero episode but with famo.us as Stan) There's incentive to put out new tools for the producers of those tools.
On the user side it's easier than ever to learn new tech and framework. I'm learning Clojure and in a few weeks I've asked at least five questions about libraries and frameworks on stackoverflow and slack that have been answered by the authors of those tools. It's 3am on a Tuesday/Wednesday and there are still people helping each other out all over the internet, writing how-to blogs, answering Stack questions. As an aside, for all the weird pathologies of this profession and our community I think that's pretty awesome.
My point is that even though the continuing learning burden might be volumetrically much larger, I'm not sure it's significantly more difficult.
Yes, but those developers are not doing front end web development for a living.
I live under the assumption that you don't have to. The thing you should figure out is: finding a stack that suits your needs (and the needs of your customers) best. If you find it, is is perfectly reasonable to beeing a bit more conservative and stick with it. On the backend for example I used rails for years, and with good reason. I am not planning to switch, but I am open enough to consider my options and experiment with other stuff. I know there are (maybe pretty good) alternatives: enterprisey Java-frameworks; good old django; nodejs; experimental stuff with erlang or haskell.
I think the frontend/js-world is not so much different. You don't have to know every framework, because it is the latest hot shit... It is not wrong knowing the strenghts and weaknesses of new frameworks, but you don't have to use and adopt to everything thats new.
Your second example of AWS/React/Redux is also a little weird since AWS is a cloud platform and it offers around 50 or so products. You can run a CGI based web app programmed with Perl in EC2 if you wish, and you can do that as easily as 15 years ago if you learned it back then.
As a younger web developer sort of a guy, I'd say that the current situation is not something where you have to be learning a whole new set of tools every 6 months. You can still easily find a job if you know for example Angular 1.x, some CSS, and understand how to create a stateless JSON API using whatever language you are comfortable with. Betting on the strongest horses of the front end side has had you learn two different technologies (both in the same language) in the past four years, I'd say that's not too much asked. In the back end cloud platforms have really taken over, but it's not really that different from 15 years ago when people ran their own hardware. Linux is still the king, now you can just choose whether you want to be in 100% control of the infrastructure or actually make your life easier by purchasing a PaaS (e.g. heroku, beanstalk).
Yes yes, I know :)
I played a bit too fast and loose with that particular example but it was late and it was more to make a rather hurried point then to actually engineer a production stack.
But facts are facts, so I appreciate the correction.
For other languages/ecosystems I would agree. However, in the JS world there is a lot of stuff that exists simply to exist. There are typically multiple libraries to do the same thing (in general) but with someone else's opinionated take on it.
Sometimes I feel like the developer of framework B was having a hard time grokking framework A and just decided to roll their own, like framework A, except for the parts they didn't like or understand. Then someone came along and realized that framework B had gaping security issues and was horrifically slow- so they created framework C which is the more secure and performant opiniated take on framework B that was an opinionated take on framework A. But then after four long months the devs behind C no longer maintain it because they've moved on to WebAssembly so a team spins off a fork of C in Coffeescript.
In a lot of other communities they would've just evolved framework A, or C would've pushed some patches back to B. Or D would've taken over for C and there would've been a handoff.
It's effing ridiculous that if I go back to a 5 month old project I will spend all damn day getting a build from source to work.
It's not just the libraries and packages. It's the toolchain, the build pipeline (heaven forbid you look like a grandpa and still use Grunt!), the transpilers. I love that people are creating cool shit all the time, but it really seems like if the code didn't come from their team, they're going to iterate the idea and put out a competing package instead of contributing back to the original. And then we wind up with two unmaintained projects 6 months later...
It really feels like there aren't many people (at least making headlines) that have had to maintain an actual live production system for more than a year or two. It'll be interesting to see what these people are doing 5 years down the road...
Not worth spending energy in worthless battles using tech that might be dead tomorrow.
Most of the JS library tools seem to encourage keeping code outside of source control which is pure crazy. It might work tolerably for a evergreen SaaS application, but you still have way too common complaints from developers that they couldn't build because someone else's server was down (NPM has trouble weekly). What is even worse is the encouragement to use a library/font/etc that is hosted in a CDN so the uptime of the app is also dependent on the uptime of the CDN hosting the library.
Interesting. We deploy daily, always fresh from NPM at each deployment stage and have never had an issue with NPM. We had one legacy dependency downloading from github (ugh) which caused an issue the last time it went down, but we quickly sorted that out.
I'm not really familiar with any popular build toolchain libraries written for 5 that haven't been updated to work with 6. It's not like a Python 2/3 scenario, or even an Angular 1/2.
> Babel has worked itβs way into the standard Javascript toolchain, and now most builders include it as a first-class plugin
Which version of Babel, 5? or 6? Because there's a lot of incompatibility issues right there and I think it is just as symptomatic of the typical JS fatigue issues which aren't really discussed.
I'm not as optimistic as the author about the future. The fatigue is real - and the value proposition of having to throw code away every year isn't that great. The JS build toolchain and steps are just plain old insane; and neither durable nor resilient. 4-6 month old code bases become antiquated vs a few years ago when you could expect 4-6 years max.
BTW, I'm pretty sure C had the same kind of explosion 30+ years ago... Obj-C started off as a set of macros in the late 80's/early 90's. But it wouldn't be proper JS engineering if a wheel wasn't reinvented along the way.