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.

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.

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

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.

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.

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.

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.