Hacker News Reader

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

History says you are wrong.

If you write a blog post series about your experiences with fron-end frameworks, I would gladly read every post.

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

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.

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

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.

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.

No, CSS/HTML in theory is a good idea, separating content from presentation. In practice, the HTML still needs to know about the presentation.

I find that it's the people that don't know HTML/CSS that have the problems.

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.

> They end up reinventing the wheel repeatedly.

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.

.Net

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

Who works for an organization that changes their infrastructure every week? That business doesn't exist. That business already failed.

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.

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.

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.

I hope asm.js solves some of these problems.

I agree on every sentence of your comment. Really, I can't imagine why you are being down-voted.

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!

express.js doesn't support http/2.

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.

If you study computer science, you will avoid JavaScript fatigue ... but possibly in favor of all out hatred.

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

I'm not sure why you're being downvoted.

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.

HN itself probably doesn't use a framework.

HN is written in Arc, a Lisp/Scheme variant. HN source (news.arc) is actually distributed with the language: https://github.com/wting/hackernews/blob/master/news.arc

Lisps tend to blur the distinction between application code, library code, and framework code somewhat, at least with well-designed applications.