> It’s like walking into a restaurant and finding out that they have all your favorite dishes and every one of them is free and complaining about how long it’s going to take you to read over the menu and make up your mind about it.
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.
Also, the problem with big chain restaurants with a thousand things on the menu is not reading the menu, it's that none of it is very good. Much rather eat at a small restaurant with 5 things on the menu that are all excellent.
And also a real effect in restaurants. Think it was like a study in supermarkets they used as an example where people were much more likely to buy a product from a free sample if there weren't too many different options to choose from.[0]
Unfortunately, all cars come with a 10.000 page driver's manual since all levers, gadgets and gauges are completely different, and if you look carefully, they probably have spent a lot of time reinventing the wheels for no obvious reason.
The restaurant comparison actually makes total sense. Whether you use web technology or whether you go out for food, it doesn't matter what you get, the end result is going to be shit.
If Javascript is the native implementation, Svelte - The magical disappearing UI framework (https://svelte.technology) bring back all the familiar native Javascript generating at build time, not runtime.
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.
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.
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.
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.
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.
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 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.
"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 a prototyper, so people often come to me first to vet new ideas. Often times this means implementing a feature on an existing product platform. When I started doing this 5 years ago, I was working with a new language every month. It was ruby one day, C# the next, and I'd go to sleep every night praying next week wouldn't be PHP.
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.
I agree with his point, but I think he mischaracterizes JS fatigue. He's right that it's exhausting trying to keep up with all of it, and that's part of JS fatigue, but the other side is the endless hype machine that's internal to the tech community, where our media is an endless stream of "look at my new framework!" and "you're doing react wrong!" and "why functional is making a comeback!"
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 agree with you. IMHO I see it as good thing. Maybe 6 projects bring so little innovation comparing to project they're trying to replace. But then somebody will take the good parts of all those projects and create something that is significantly better. Innovation does not grow on trees, there is slow and bumpy road to it. :-)
> Nobody is ever going to know everything there is to know about modern web architecture
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 :)
Pretty rich coming from the complainer-in-chief of JS, the guy who advises not employing people who don't happen to agree with his personal take on how JS should be written.
I think the bigger problem is that we, as developers, don't appreciate risk and how to mitigate it. We always want to play with the latest and greatest tools, technology, approaches, etc, etc.
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.
>When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, failure is unlikely at best.
One benefit often overlooked is that during high periods of churn in an industry (let's specify JavaScript fatigue as a symptom of rapid churn in Software Engineering for Web Applications). There are more opportunities to quickly speed up your career. Fresh problems call for new solutions and fresh eyes to work on those problems.
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).
I see the proliferation of JavaScript tools as a massive failure of the vanilla js standard library and ECMA. Most of the stuff out there just rebuilds basic language features that would be standard in other languages.
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
I think node is the funniest example. "Yay we can run js on the server now! This is the future!"
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.
The problem is very accurately described as people trying to use every framework and every library all at once. Too many developers are neglecting their knowledge of the base language. JavaScript has become incredible in recent years, but you'll still find new projects being built incorporating jquery.
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.
Using vanilla js becomes a problem once you start building something bigger than a simple web page. Eventually you will end up with your own framework and new developers still have to understand how it works etc. It's totally fine if you are expert js developer and now how to structure and design your code for maintainability. But few hacks here and there, and you might end up with a mess.
Agree with the author 100%. We want tons of new JS tools and frameworks out there so we can learn and evolve newer and faster ways of developing. I still remember when jQuery first came out and how earth-shattering that was. This inspired so many more devs to create better and easier to use tools.
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
In some respects the problem of “too many libraries” is the same issue we have with news headlines, etc.: too much going on, and not enough value placed on curating.
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.
I definitely appreciate the sentiment. Its true, the JS ecosystem has exploded and there's been a lot of shrapnel flying around for quite a while. It feels like the smoke is starting to clear and some different groups of consensus are starting to form about some generally reliable patterns and tools which makes things easier.
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.
> I recently built an app prototype in a couple days using nothing but vanilla JS and the DOM. I was literally two days in before I installed a single non-dev dependency. Guess what? It was fine.
IMHO a good strategy to reduce the cognitive load (and limit dependencies).
I loved this admission. There is a lot of awesome, powerful, fancy stuff out there today, but you can get a lot done with the vanilla approach. I was introduced to JS back when AJAX was 'blowing up', and today still prefer to hack quick ideas w/ at most a jQuery import
[+] [-] ysavir|9 years ago|reply
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.
[+] [-] Touche|9 years ago|reply
[+] [-] bitwize|9 years ago|reply
[+] [-] nol13|9 years ago|reply
[0]i forget some business class i think
[+] [-] kpil|9 years ago|reply
[+] [-] galacticpony|9 years ago|reply
[+] [-] proyb2|9 years ago|reply
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.
[+] [-] peterkelly|9 years ago|reply
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.
[+] [-] intrasight|9 years ago|reply
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.
[+] [-] ktRolster|9 years ago|reply
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.
[+] [-] mrec|9 years ago|reply
> 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.
[+] [-] micaksica|9 years ago|reply
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.
[+] [-] traverseda|9 years ago|reply
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.
[+] [-] pif|9 years ago|reply
[+] [-] bhouston|9 years ago|reply
[+] [-] kazinator|9 years ago|reply
[+] [-] edblarney|9 years ago|reply
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.
[+] [-] jjcm|9 years ago|reply
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.
[+] [-] fatbird|9 years ago|reply
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.
[+] [-] finchisko|9 years ago|reply
[+] [-] hackcrafter|9 years ago|reply
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 :)
[+] [-] indubitably|9 years ago|reply
[+] [-] caseysoftware|9 years ago|reply
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.
[+] [-] jaredsohn|9 years ago|reply
Should this be success is unlikely at best?
[+] [-] dy|9 years ago|reply
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).
[+] [-] throwbsidbdk|9 years ago|reply
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
[+] [-] throwbsidbdk|9 years ago|reply
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.
[+] [-] nickthemagicman|9 years ago|reply
[+] [-] Kequc|9 years ago|reply
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.
[+] [-] bjacobel|9 years ago|reply
[+] [-] jyriand|9 years ago|reply
[+] [-] wnevets|9 years ago|reply
[+] [-] dennisnedry|9 years ago|reply
[+] [-] edblarney|9 years ago|reply
JS evolution is perniciously different than the evolution of most other languages.
[+] [-] throwaway23421|9 years ago|reply
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
[+] [-] rootlocus|9 years ago|reply
Ha ha! A fatigued JS developer complaining about hipster Haskell things!
[+] [-] amelius|9 years ago|reply
What does that mean for security, given that two secure systems combined can result in an insecure system?
[+] [-] makecheck|9 years ago|reply
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.
[+] [-] finchisko|9 years ago|reply
[+] [-] amelius|9 years ago|reply
[+] [-] paulddraper|9 years ago|reply
[+] [-] karmajunkie|9 years ago|reply
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.
[+] [-] vmorgulis|9 years ago|reply
IMHO a good strategy to reduce the cognitive load (and limit dependencies).
[+] [-] nkkar|9 years ago|reply