7 ms·

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 universiti

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.

traverseda 10y ago
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.
mrec 10y ago
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.
- dukerutledge 10y ago
  Who works for an organization that changes their infrastructure every week? That business doesn't exist. That business already failed.
- geebee 10y ago
  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 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.
pif 10y ago
I agree on every sentence of your comment. Really, I can't imagine why you are being down-voted.
- cr0sh 10y ago
  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.
ktRolster 10y ago
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.
- gp7 10y ago
  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
  - zepto 10y ago
    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.
- awinder 10y ago
  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
  - bobbytherobot 10y ago
    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.
bhouston 10y ago
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.
- mercer 10y ago
  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!
  - tannhaeuser 10y ago
    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 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.
edblarney 10y ago
"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.
- webmaven 10y ago
  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.
  - edblarney 10y ago
    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.
    - webmaven 10y ago
      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 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.
micaksica 10y ago
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.
intrasight 10y ago
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.
- lojack 10y ago
  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.
  - intrasight 10y ago
    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.
kazinator 10y ago
If you study computer science, you will avoid JavaScript fatigue ... but possibly in favor of all out hatred.

traverseda 10y ago

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.

mrec 10y ago

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.

dukerutledge 10y ago
Who works for an organization that changes their infrastructure every week? That business doesn't exist. That business already failed.
geebee 10y ago
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 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.

pif 10y ago

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

cr0sh 10y ago
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.

ktRolster 10y ago

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.

gp7 10y ago
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
- zepto 10y ago
  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.
awinder 10y ago
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
- bobbytherobot 10y ago
  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.

bhouston 10y ago

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.

mercer 10y ago
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!
- tannhaeuser 10y ago
  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 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.

edblarney 10y ago

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

webmaven 10y ago
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.
- edblarney 10y ago
  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.
  - webmaven 10y ago
    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 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.

micaksica 10y ago

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.

intrasight 10y ago

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.

lojack 10y ago
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.
- intrasight 10y ago
  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.

kazinator 10y ago

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