13 ms·

JavaScript Fatigue or My History with Web Development

157 points by akras14 9y ago

stanislavb 9y ago
...and that's why so many devs secretly (or not so secretly) hate JS
finchisko 9y ago
It was said million time here. But if you don't like trying new stuff, learn one stack and stick to it. Nobody is forcing you to try new stuff and then talk about js fatigue. Personally I'm exact opposite, I love where js is headed and like all the new stuff and stacks coming. No fatigue at all for me.
- austenallred 9y ago
  > Nobody is forcing you to try new stuff Well, except for employers
  - eloisant 9y ago
    It's usually the developers who push for a switch to the next shiny thing, employers just want a project done in the time and budget.
    - TeMPOraL 9y ago
      The flipside is that they hire expensive professionals and then don't trust their judgement - instead forcing them to use inadequate tooling for the problem. Also related to some enterprise companies selling software solutions to management instead of tech people.
      - deleted 9y ago
        [deleted]
    - BigJono 9y ago
      Quite often the decision to use new tech is made by CTOs, tech leads and senior devs. The majority of jobs are for plain old "one part of a team" dev roles. If you don't have the experience to jump into a role that commands respect, and the industry is trending towards tools that are overengineered or unsuitable for the problem at hand, then it's perfectly possible to find yourself in a position where you either learn how to do the job poorly or find yourself unemployed.
    - adrianN 9y ago
      Unless someone high up has seen a powerpoint with the newest buzzwords and tells the dev department to get on the bandwagon.
    - threatofrain 9y ago
      Business people are often targets for advertising a technological change. In fact, I think big-contract software firms don't target engineers as priorities for advertising, but rather aim straight for business folks.
  - Vinnl 9y ago
    If my employer wants to pay me for spending time learning that stuff (and making newbie mistakes in their code), then I guess I can live with that. If they don't and still expect me to follow whatever their whim of the day is, then I'm glad I'm in an industry where I can safely say I'd need to look for another job then.
- satyanash 9y ago
  in TFA fatigue appears exactly once. The author isn't even the victim of said fatigue. It's just a fancy title.
  - tempodox 9y ago
    > It's just a fancy title. AKA clickbait.
- BigJono 9y ago
  > Nobody is forcing you to try new stuff and then talk about js fatigue This is just not true. I recently had a discussion at work where I was flat out asked "how do you expect to learn new things if you don't try new libraries?". Coming up with a solution yourself (assuming these libraries are even introduced to solve an existing problem, which is sadly not always true) was not seen as an acceptable answer... The options appear to be assimilate into this culture, or find a new industry to call home. Front-end dev doesn't appear to be for people that care more about a lean, pragmatic stack than a trendy one.
  - aaron-lebo 9y ago
    Coming up with your own solution when it isn't informed by other solutions just means you are building another poor alternative. Frankly these frameworks and libraries are all very similar and they do very similar things. Once you've learned one you can transition to the others quickly (it's the same way with old web frameworks, MVC frameworks are all the same with minor tweaks). They are worth evaluating though because some of them do one thing better than others, might as well borrow it where possible. I love learning new technology because even if I don't end up using framework x or y, I can pick up the best parts and use it in my own work which becomes simpler and more expressive as a result. I don't want to keep building websites from 2005. There have been some real advances and it's fun touse the best parts.
    - BigJono 9y ago
      Yes, you're building a poor alternative. But you learn far more than you ever would just by using the existing libraries, by virtue of learning what not to do. Using other's tools is trading off knowledge for development time. It's often a good trade to make, but to pretend that learning the API surface of library #34341 is going to improve your skills more is wrong.
      - amackera 9y ago
        Nobody said learning API surfaces is the right way. Most of these frameworks offer fairly simple APIs that are frankly pretty trivial to learn --- the key is to learn the application architecture and why it's different than the alternatives. Anyway, I think we can agree that exposure to other people's thoughts, and also coming up with your own thoughts, is probably the most fruitful way to learn.
- bl4ckj4ck 9y ago
  Same here. We should remember that JavaScript is a language and React/Angular/Vue are just frameworks/libraries. The latter come and go, the former stays. Sometimes I just think that for JavaScript developers is simply difficult to choose, so someone created the "JavaScript fatigue". Even Java has a lot of frameworks and libraries to choose from, but I don't see any fatigue there. Probably we should just be less open to temporary fashions.
- coldtea 9y ago
  >It was said million time here. But if you don't like trying new stuff, learn one stack and stick to it. Nobody is forcing you to try new stuff and then talk about js fatigue. You'd be surprised -- since even single stacks change all the time. Try using React Router and keeping it stable. Heck, even React changes paradigms (from mixins and factories, to ES6 classes and pure components, to fibers, etc). And from pure React, to coming up with Flux, 4-6 flux alternatives, the Redux dominating, etc. And let's not get started with things like Angular to Angular 2 et al...
  - finchisko 9y ago
    I would not be. React Router 4 is awesome. Wish I had time to write down why. But if you have reason not to upgrade, you can stay on version 3, which is still supported. Same with Angular. Of course there will be examples you're right, but not those two. ;-)
- shusson 9y ago
  > Nobody is forcing you to try new stuff and then talk about js fatigue. If you read the conclusion, the author is actually very positive about the entire experience.
rectangletangle 9y ago
Man... when it's laid out like that, it does seem a bit insane. By comparison Python's primary web framework in 2012 was Django, and today it remains Django. Despite this relatively glacial pace, there's been a ton of improvement to Django, and the surrounding Python ecosystem. A more conservative development culture can pay off sometimes, since it allows the community as a whole to focus on polishing the existing ecosystem. As opposed to dropping Django when "real time" Websockets were all the rage, there was a concerted effort to include it in the framework with the Django Channels project.
- polskibus 9y ago
  Don't forget that move towards microservices and Go caused many Django devs to move away from it.
  - rectangletangle 9y ago
    That's certainly true for that particular niche. However Python has certainly come into it's own over that timespan, with the rise of various machine learning approaches. This reinvigoration, seems to have manifested in the web side of the language too, seeing as many models eventually need some form of HTTP server. Admittedly though the community isn't perfect. There was quite a schism over Python 2 vs 3 for a while. Thankfully it's looking like that may be past us. Anecdotally the Python community seems more active than ever.
nice_byte 9y ago
How do you end up with like six "build systems" for web applications? What even is there to build? Why can't you concatenate all javascript and run it through a minifier with a shellscript? I haven't done webdev since 2010 and now that I look at it, it just seems so bizzare.
- chj 9y ago
  One thing I like about JS is that you don't need to compile or build anything. I get it that you will need to bundle everything in production, but I am baffled that bundling can't be automatically done. The process should be transparent to developers.
  - rimliu 9y ago
    if you use ES6+ and target not so capable browsers, if you use JSX you need to compile. And while you can write React without the JSX it is not something anyone would enjoy.
- duval 9y ago
  Yours do that if you want, but then you might have customers using large parts of the code base that other don't have access to so you want to use code splitting. You probably have some images and want them to look good on all screens but also want them to be a small size so you use image srcset but you need to output 6 images for all the sizes. If you're using svgs you might want to inline these. I mean it goes on and on really, just look at all the headings within the webpack docs if you want more insight. I can understand why it seems crazy and perhaps it is more crazy than I think but if you want you can just concatenate all the scripts, if you want more bells and whistles then you can too
  - pdkl95 9y ago
    > code splitting That should only take a few lines in a Makefile. JSTARGETS = foo.js bar.js build-js: $(JSTARGETS) foo.js: foo_main.js lib_a.js lib_b.js cat $< > $@ bar.js: bar_main.js lib_a.js lib_x.js lib_y.js cat $< > $@ With make's builtin topological sort, adding dependency information to control the order or other unusual build requirements isn't hard to add. > output 6 images for all the sizes IMAGES=( baz quux ) IMGSRC=(patsubst %,src/images/%.jpg,$(IMAGES)) IMGSML=(patsubst %,build/images/%-small.jpg,$(IMAGES)) build/images/%-small.jpg: src/images/%.jpg convert $< -resize 25% $@ build-images: $(IMGSML)
TeMPOraL 9y ago
> I’ve only been a full time web developer for the past 5 years. It’s barely enough time to start calling myself a “senior” Software Engineer. Offtopic, but when does one start to be "senior" then? I've been coding for the past 17 years or so, including about 6 years professionally. Do I get to be a "senior" dev now? How do I convince my boss?
- RandomInteger4 9y ago
  Ask your boss if you can get a promotion / raise and if they deny you that, then ask if at the very least you can have a new title, then use that on your resume for your next job.
- dagw 9y ago
  Offtopic, but when does one start to be "senior" then? It differs massively from company to company. Where I'm currently working the guideline is 10 years relevant professional experience plus either significant project management experience or having an area where you can generally be considered an expert in your field. I've also worked at places where people 3 years out of school are considered senior.
superasn 9y ago
I really don't understand this hate for Angular 1. I think till date it is among one of the best things to happen to the web after jQuery. Yes, I think jQuery is great and Angular 1 is fantastic for making website super quickly and maintaining them.
- rectangletangle 9y ago
  Implementing unit tests always seemed excessively painful, especially when compared to React/Redux.
  - superasn 9y ago
    In my experience it wasn't that hard writing unit tests for Angular 1 modules. They have a pretty solid testing framework built for it.
    - rectangletangle 9y ago
      Hard isn't really the right term, more just annoying, because you have to mock out everything and the kitchen sink. To be fair, I can't think of a frontend framework that had any real unit-test framework before Angular. So it was an improvement at the time.
- RonanTheGrey 9y ago
  I can't stand Angular 1 the framework or the language. I also credit them with promoting modern web development and producing a realistic expectation that browsers can actually present some really cool, sophisticated applications. It is largely because of Angular 1 (and other, less known libraries) that we currently are seeing an explosion of innovation. I may not have liked the framework, but I cannot deny the incredibly powerful (and in my estimation, positive) effect it had on the industry.
  - superasn 9y ago
    You're right about that.. It's still my favorite framework even though I too have my pet peeves (no lazy loading, really?). Anyway, what are you currently using? Why?
deleted 9y ago
[deleted]
patatino 9y ago
I fell in love with web development over 15 years ago because it was just a request to the browser and an answer. I've worked on windows applications and just hated it. All this code handling the state of controls depending on the input/action. Sometimes I have the feeling I'm doing this stuff on the web again which I haven't for over 10 years and it just feels wrong.
- aaron-lebo 9y ago
  What's difficult about it? The underlying model is incredibly simple. You have a visual model/datastore that you manipulate and the UI changes as a result. Interactions with the UI drive events which might call out to a server or do a calculation, which in turn changes the view model/datastore and that changes the UI and so on and so forth... You probably get that, but I've down programming with wxPython, Qt, etc. I've done Django, Rails, Flask, etc. and frontend frameworks are so much more powerful and easier to use than those old models and getting them up and running takes a few minutes. When I see how much difficulty and how much anxiety this new tech is causing people it makes me wonder if the frameworks are just covering up how easy all this stuff is and how powerful it is. It's really exciting stuff, it sucks if people are missing that.
  - skyisblue 9y ago
    Are you still using Django, Rails, or Flask to provide API end points to your front end? If not, what do you use?
    - aaron-lebo 9y ago
      Not a big fan of Ruby or Python as the backend server given the choice, there's just a lot of languages that do it better (Elixir, Clojure, Go for example). Django and Rails have a lot of extra stuff you don't need. But if you just want to get an api up quickly its really hard to beat Flask or even Bottle (not sexy but very simple) and I've never used it but Sinatra is supposed to be great, too. Microframeworks are great.
Animats 9y ago
“My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.” - Lewis Caroll, Alice in Wonderland Coming up next, WebAssembly for strong obfuscation.
- tom_wilde 9y ago
  The only winning move is not to play.
- SamUK96 9y ago
  Proprietary code blobs running in everyone's browsers. God what a recipe for absolute carnage...
  - manigandham 9y ago
    We had that before with native plugins and extensions. We can also install random programs on any OS. It's really not a big deal.
  - kronos29296 9y ago
    Is WASM really a proprietary code blob? Or the WebAssemsblers will be proprietary code blobs? Isn't it being done by guys at Mozilla, Google and folks. Or are you confusing Assembly lang that is used with different CPUs and this. If so try this: [1] https://auth0.com/blog/7-things-you-should-know-about-web-assembly/ https://auth0.com/blog/7-things-you-should-know-about-web-as... [2] https://gotechster.com/2017/04/web-assembly/ https://gotechster.com/2017/04/web-assembly/
  - maeln 9y ago
    Javascript already does that. If you look at any website nowaday you will find minified JS that is impossible to understand. What's the difference with a binary format at this point ? It does not change the fact that those blob are executed in a sandboxed environnement with a permission system. At least WebAssembly is more efficient and will make it finally possible to use staticly typed langage for web developpment.
raquo 9y ago
JavaScript is a small language because it needs browser support and backwards compatibility. A small language that can't change much over time can't afford to have opinions on how to build dynamic interfaces. Therefore, all the complexity of building interfaces will be in the libraries and because opinions on such complex issues vary, there are many libraries to do the same thing. Eventually the interior ones are recognized and culled. They typically are supported for quite some time after becoming uncool, it's just that no one wants to work with lame, obsolete tehnology for good reasons. The solution I see to this are compile-to-JS languages that make it possible to use a different ecosystem of libraries than te JS one, like Scala.js. However, those tools are also still evolving, so one way or another you're dealing with a lot of library churn in frontend development right now, so learn to pick winners and stick to them until it's as weird to use them as jquery for complex UI was in 2012.
unclebucknasty 9y ago
I dunno. I'm starting to wonder if writing disciplined code with jQuery for support is a better approach than the framework soup we've been dealing with in recent years. I know, I uttered the "j-word that shalt no longer be spoken" but that's kinda' my point--what's wrong with writing code anymore? If you use simple, clean modular coding patterns, componentize for reuse, make judicious use of promises, and sprinkle in lightweight templating and routing libraries, etc., you'd effectively have your own mini-framework on which to continue building. After all, frameworks themselves are code under the covers--code that encourages patterns. Sure, some say it's reinventing the wheel to write JS without someone else's framework. But, it seems to me that the frameworks are re-inventing the wheel. Not only is there a new one every day, but they are even re-inventing themselves (I'm looking at you Angular). Looking at the mere scaffolding alone for some of these frameworks makes me think, "what are we doing to ourselves?". Generate an "empty" project on some of these guys and prepare to be overwhelmed with opinionated cruft. Rolling my own code is not reinventing the wheel, because Angular, et. al. are not the wheels I'd invent in the first place. Until a framework comes along that truly abstracts away HTML, CSS, the DOM and the rest of the old Web, so that it genuinely allows construction of clean event-driven, componentized applications, I'm not sure I see the benefit of playing the framework du jour game.
- zer0tonin 9y ago
  >Until a framework comes along that truly abstracts away HTML, CSS, the DOM and the rest of the old Web, so that it genuinely allows construction of clean event-driven, componentized applications So react?
  - deleted 9y ago
    [deleted]
  - unclebucknasty 9y ago
    More like Swing.
shubhamjain 9y ago
I think the problem is more common than people think. It takes lots of bad frameworks to establish a single dominant one. It reminds me of the similar issue PHP landscape was fraught with—lack of a framework/approach with no downside. Figuring which PHP framework to use was a problem of choosing between dozens of options, each with their own mighty cons. Every time a new framework came, it demonstrated an ability to fix all the known problems but time and again it faltered (Kohana, CakePHP, Yii). In the recent times, Laravel has provenly become a better choice than what was available only a few years back. It has grown a community of a considerable size and it's unlikely it would getting supplanted in future. I am guessing at some point in the future, the landscape would stabilise and a single approach would become the obvious choice for JS just like Rails is for Ruby.
- aaron-lebo 9y ago
  You're right, it is common and it's easy to forget that. Python in 2007 was Django, web.py, Subway, Turbogears, Pylons, Werkzeug, Zope, and a bunch of tools a lot of people have never heard of competing for space. Who needed all of those frameworks anyway? It took awhile but slowly what works and what doesn't was figured out and we've got better approaches. Web programming circa 2007 was by its nature simpler and despite that the Python community (which is a blip compared to the JS community today) churned out a lot of stuff. You can still build websites like it is 1999 but you've got a lot of other options now, too. Use the best parts and dip your toes into that stream of new stuff when you feel like it. Competition and progress beat the hell out of stagnation though.
- fetbaffe 9y ago
  I hope that never happens. Why? Frameworks solves a generic problem, but you in your project are solving a specific problem, hence you can never solve your problem better than what the Framework allows you to. Problem is rather developers don't know how to organize their code without the help of the Framework. If they knew, Frameworks would not be needed, only libraries. One Framework to rule them all will stifle progress, it locks the community into one size fit all mentality and therefore clouds the minds of the developers to not think about the possibilities outside their worldview. Laravel will, of course, eventually be replaced, as with all frameworks. Current hype now are "micro" frameworks. So all that effort put into the Framework will be partially lost due to it is locked to that Framework. Lessons learned ought to be, write reusable framework independent libraries instead.
holydude 9y ago
My advise is when you care about your "career" stick to the one with the largest user base (or depending on your location). Learn it, love it, embrace it. Then experiment with whatever you want to.
sutee 9y ago
While it's easy to get frustrated especially if you are following each twist and turn that js takes, I think if you step back a little, you can see things are getting better as a whole. For the longest time, js was just a thing I did on weekend or as part of tertiary projects at work. I first used js as a kid for my geocities page, used jquery and YUI for a work projects starting about eight years ago, experimented with Angular, and most recently embraced React and es6. Almost two years ago, I quit my job and started building a side project in React and Fluxxor for fun. At this point there were a bunch of Flux implementations and no dominant library had emerged. I got frustrated with the build process and then got distracted with other life experiences. I returned to javascript less than a year later and was amazed at how much better things got. I could do npm install and npm start and there was a good chance things would actually work. I was doing the same google searches but noticed that the documentation was a lot better. I also had a friend this time around and he steered me toward Redux and es6. Javascript suddenly became an enjoyable language for me enough that I plan to focus on it. This is after more than close to twenty years of fits and starts.
alanfranzoni 9y ago
To me, it is incredible that the frameworks matter THAT much in the JS world. Once you know about Javascript, the web, and browsers... any good dev should be able to pickup such part of the tech stack (frameworks, libraries, ecc) quite quickly. In other environments (e.g. Python, Java) nobody expects you to know everything about the specific libraries used in a company; once you know the language and a bit about the technologies (e.g. work on Linux, on a webapp or a desktop app), you're good, you'll pickup the details while working. Forcing a technology change because it's not the "latest and greatest big, shiny thing"... I find this is a slightly disturbing trend in frontend development.
- kutkloon7 9y ago
  This also has to do with browser compatibility. Vanilla Javascript sucks so hard because it's so difficult to write non-trivial stuff that just works. This is the whole raison d'être for JQuery. This is mainly because the different browsers don't coordinate and there is no official standard. It should have been obvious from the start that this is a recipe for disaster.
- shams93 9y ago
  It's not an issue with JavaScript it's that the Dom has always been horrible. It's actually slowly improved but not enough to do without the need for frameworks for complex front end applications.
  - maxxxxx 9y ago
    I think that's the real problem. Most JS frameworks wouldn't be needed if the DOM was designed for what it's used today.
  - fenwick67 9y ago
    Yes yes yes. Simply creating nested elements and getting references to each of them is such a huge pain, and it's a huge part of why frameworks are needed. You would think creating, say, a form with a button and a textarea, and getting references to those things would be simple, but it's crazy painful in vanilla JS.
prashantswain 9y ago
If you seek legitimate hacking service ,contact hdmoore.hacks@gmail.com ...dude's a cyber guru, involved with cloning phones, hacked into my ex's gmail and facbook, what let me knowing she was infidel and also gave my nephew some really outstanding school scores which he upgraded himself, cool way to have financial freedom as well. Get your bank blank atm cards which could debit money from any a.t.m machine. Make $20,000 and more in a couple days. Bank transfers and wire transfers as well as Paypal jobs, hes that good, had to make him my personal hacker. You could mail him as well if you got issues, he's as discreet and professional too. He's kinda picky though so make mention of the reference
mstijak 9y ago
I fully agree with the OP. I used Bootstrap/jQuery, Ext JS, D3, Highcharts, Angular and React. Each of these felt right for a period of time. Now, I'm using my experience to put the best features of all these into my own commercial framework called CxJS - https://cxjs.io/ https://cxjs.io/
manigandham 9y ago
From the article > How much has medicine, accounting, politics, law, construction, or math changed in that time period? The webapps that services those industries has changed massively in the past decade. The web has evolved from simple documents to complex applications. The browser is the new app delivery platform, and it's perfectly reasonable that this would bring increased complexity. Backend development has countless languages, compilers, frameworks, toolchains, CLIs, OSes, containers, etc. - so it's really not that strange to see frontend dev catch up. What's rather amazing is that there's just 1 language with everything else being frameworks and tools that let you shape it to your needs (and also runs just as well server-side with nodejs).
richardknop 9y ago
Another option to avoid this JS fatigue is to switch to a different web development job. Get a job which focuses on backend and APIs. Or you can even take it further and go focus on more networking / sysadmin / devops area. Les fatigue there.
preordained 9y ago
All this great "progress" and "innovation"...and yet, have you been out there lately? The web? Everything just barely works, and I haven't the slightest illusion that I'm using anything but a patchwork networked application. Most times I'm trying to kill or avoid whatever the hell this page is trying to do and just get my text or content, or submit the stupid form. I feel like if the front-end dev world is so keen on reinventing itself, it should just go all the way...repackaging HTML/CSS/JS in new and interesting forms and frameworks isn't getting anyone anywhere, IMO. Scorched earth, a new protocol for web applications...don't even call it the web anymore...just put on your CS hats and start over...kill the whole thing with fire.
- noshbrinken 9y ago
  The last part of your comment blames front-end developers for the shortcomings of the web platform. I think many would be interested in a more uniform, stable interface. But they're not the ones with the power to change things on the protocol layer.
fetbaffe 9y ago
Frontend development in JavaScript has become a hellhole. Projects can have three plus build tools that each take a long time. Massive list of dependencies plus bad dependency management, lack of documentation, everything changes so fast you need to find the correct stackoverflow answer for this week solution to your build problems, build tools depends on other build tools configurations in undocumented ways, reimplementation of the model & business logic of each project, constantly reinvention of the wheel. And the end result? Web just becomes slower and slower. Developers today build software that fits their paradigm, not the users experience.
- lllr_finger 9y ago
  That last sentence succintly describes my primary issue with front end developing, and why I'm starting a new job in a few weeks that is almost purely backend. Most of my recent web work has been trying to manage shared libs and duct taping the build process together. Every feature branch has major shrinkwrap merge conflicts because there is so much module churn.
- jbreckmckye 9y ago
  I am currently working on a Node/React project with 120 first-order dependencies. 120! And it's just a crud app with a few canvas visualisations.
Yuioup 9y ago
I'm curious about the statement "React has become the champion" I've recently moved from ASP.NET MVC/jQuery to Angular4. I'm extremely happy with the transition and I intend to stick with Angular. After not worked with React (yet), what am I missing?
- akras14 9y ago
  Nothing, its mostly hype. If Angular works for you, you are not missing much
- RonanTheGrey 9y ago
  These days I split my time between React & Angular 4. I love Angular as much as React. Both very cool platforms to work on, if you are happy there, stick with it! There are tons of jobs these days on the new Angular.
ericssmith 9y ago
That conclusion made me laugh. In the early to mid 90s, I was working on 3D interactive software. The video drivers and chips had advanced so much in one year that all of the lovingly handcrafted assembly I had written over that time was useless. I thought to myself, "what an unstable industry to build a career in". I also made comparisons to accounting, medicine, and law, thinking perhaps I had made a wrong choice. Turns out that adapting to rapid change is a critical aspect to this career choice. It is also a problem for businesses, which you start to grapple with as you move up the chain of command. The mistake is wistfully hoping that things would slow down enough for you rest on your hard-won knowledge, as in other fields. There is no competitive advantage in aging technology.
- deleted 9y ago
  [deleted]
- 0xdeadbeefbabe 9y ago
  > as in other fields Well maybe it isn't a field after all. Maybe it's "pop culture" like this cranky old guy says https://www.youtube.com/watch?v=FvmTSpJU-Xc https://www.youtube.com/watch?v=FvmTSpJU-Xc.
- geebee 9y ago
  There can be a competitive advantage in aging technology. For instance, suppose you were writing an app that makes heavy use of scientific or ML libraries in python, but your UI is a mainly layout and forms with admin, login, accounts, and so forth. I could easily see huge advantages to keeping it in python, using Django, with a bit of CSS and javascript sparsely applied where needed. Some of this comes down to personality, too. A lot of people talk about how people were abandoning ruby and rails once it was no longer the "new hotness". Plenty of us (who like rails) came to it somewhat reluctantly, only after the benefits were very clear and the initial chaos had started to subside. We, the reluctant ones, just tend to be a bit quieter about things. I think we're reluctant because we see greater danger and risk in a constantly evolving set of technologies, and we don't like spending a lot of time figuring out how to get a drop down list to populate, not when there's limited time and there's value to be added on the back end. I've been at this for a while, and I'm getting more and more ok with sticking with an aging technology - even when I know the technology is becoming obsolete. Right now, it's pretty clear to me that web based UIs in the future will be more asynchronous and elaborate, but there will be a lot of false starts and dead ends as we get there. Remember spring mvc, spring di, iBatis, hibernate, tapestry, pico, tiles struts, struts 2...? Yes, the old request-response servlet with jdbc was unlikely to remain a choice for new development, but honestly, I think it might have been a good idea to stick with it for a while and stay out of that mess. Yeah, you'll need to change and adapt, but that doesn't mean you need to jump into the swirling mess. ...unless you do! There are, of course, remarkable opportunities when a new technology hits, and if you wait for it to settle down, you may often find that others have too great a lead. You just really need to figure out if that's you. Because otherwise, you may find that instead of improving the accuracy and speed of some critical calculations your users need to improve their supply chains, you instead spent all your time figuring out how to asynchronously update a drop down list depending on where they clicked on a map. And a round trip to the server and an extra second to load that drop down list might not have been all that big a deal compared to the actual business use of your app.
drumttocs8 9y ago
Can anyone tell me why I shouldn't still just use standard, ECMAScript, and (gasp) jQuery? There's so much churn in the JS world, sometimes it makes sense to just build something, and then optimize it later.
- kcdev 9y ago
  For small projects, this is definitely still OK. Green browsers don't really need jQuery any more, but if it's what you're comfortable using and it gets the job done, then use it. Large projects or team projects, you will want to use something with more structure.
  - aaron-lebo 9y ago
    Some of the newer frontend frameworks are so small that it really doesn't benefit you to use jQuery even for small projects. It lacks structure and it's way too easy to start manipulating state though the dom when you could have reusable components and a decent structure with a few extra lines of code.
- lxrbst 9y ago
  No one is seriously saying you can't. If your problems are simple enough to be solved with plain js/jquery, feel free. I don't get all this tooling and framework hate - no one is forcing you to choose anything, it's an open buffet, and you can choose as much as you want from wherever you want, for free.
  - unclebucknasty 9y ago
    I think he/she is saying the opposite: that people who don't use frameworks get the hate, and there is a lot of pressure to pick a framework. Not an invalid point. Mention jQuery here, or anywhere, and witness the response.
- chasing 9y ago
  Remember that part of being an experienced developer is having the wisdom and knowledge to select the right tool for the right job. Sometimes that's the hot new cool shit. Oftentimes it's something much more mundane. If you project calls for "standard, ECMAScript, and (gasp) jQuery," then use them! Just be aware of the benefits and trade-offs.
vmware505 9y ago
Why I've never seen any Ember.js dev writing about javascript fatigue? Because healthy community, matured framework, happy developers never felt that. Ah, and there are plenty of jobs with much higher salaries.
hugs 9y ago
Every time I read an article like this I wonder: "Where are all the three.js users? Am I the only one? And am I the only one not suffering from JS fatigue?"
draw_down 9y ago
Just a thought, but: you don't have to write JavaScript. There are lots of other languages than JS, and lots of areas of programming other than the web. So it's really, really possible to not write JS if you don't want to. Just think, you could be free! Forever!!!!!
gotofritz 9y ago
Oh not another one of these I have "JS Fatigue" fatigue

157 points by akras14 9y ago

...and that's why so many devs secretly (or not so secretly) hate JS

It was said million time here. But if you don't like trying new stuff, learn one stack and stick to it. Nobody is forcing you to try new stuff and then talk about js fatigue. Personally I'm exact opposite, I love where js is headed and like all the new stuff and stacks coming. No fatigue at all for me.

austenallred 9y ago
> Nobody is forcing you to try new stuff Well, except for employers
- eloisant 9y ago
  It's usually the developers who push for a switch to the next shiny thing, employers just want a project done in the time and budget.
  - TeMPOraL 9y ago
    The flipside is that they hire expensive professionals and then don't trust their judgement - instead forcing them to use inadequate tooling for the problem. Also related to some enterprise companies selling software solutions to management instead of tech people.
    - deleted 9y ago
      [deleted]
  - BigJono 9y ago
    Quite often the decision to use new tech is made by CTOs, tech leads and senior devs. The majority of jobs are for plain old "one part of a team" dev roles. If you don't have the experience to jump into a role that commands respect, and the industry is trending towards tools that are overengineered or unsuitable for the problem at hand, then it's perfectly possible to find yourself in a position where you either learn how to do the job poorly or find yourself unemployed.
  - adrianN 9y ago
    Unless someone high up has seen a powerpoint with the newest buzzwords and tells the dev department to get on the bandwagon.
  - threatofrain 9y ago
    Business people are often targets for advertising a technological change. In fact, I think big-contract software firms don't target engineers as priorities for advertising, but rather aim straight for business folks.
- Vinnl 9y ago
  If my employer wants to pay me for spending time learning that stuff (and making newbie mistakes in their code), then I guess I can live with that. If they don't and still expect me to follow whatever their whim of the day is, then I'm glad I'm in an industry where I can safely say I'd need to look for another job then.
satyanash 9y ago
in TFA fatigue appears exactly once. The author isn't even the victim of said fatigue. It's just a fancy title.
- tempodox 9y ago
  > It's just a fancy title. AKA clickbait.
BigJono 9y ago
> Nobody is forcing you to try new stuff and then talk about js fatigue This is just not true. I recently had a discussion at work where I was flat out asked "how do you expect to learn new things if you don't try new libraries?". Coming up with a solution yourself (assuming these libraries are even introduced to solve an existing problem, which is sadly not always true) was not seen as an acceptable answer... The options appear to be assimilate into this culture, or find a new industry to call home. Front-end dev doesn't appear to be for people that care more about a lean, pragmatic stack than a trendy one.
- aaron-lebo 9y ago
  Coming up with your own solution when it isn't informed by other solutions just means you are building another poor alternative. Frankly these frameworks and libraries are all very similar and they do very similar things. Once you've learned one you can transition to the others quickly (it's the same way with old web frameworks, MVC frameworks are all the same with minor tweaks). They are worth evaluating though because some of them do one thing better than others, might as well borrow it where possible. I love learning new technology because even if I don't end up using framework x or y, I can pick up the best parts and use it in my own work which becomes simpler and more expressive as a result. I don't want to keep building websites from 2005. There have been some real advances and it's fun touse the best parts.
  - BigJono 9y ago
    Yes, you're building a poor alternative. But you learn far more than you ever would just by using the existing libraries, by virtue of learning what not to do. Using other's tools is trading off knowledge for development time. It's often a good trade to make, but to pretend that learning the API surface of library #34341 is going to improve your skills more is wrong.
    - amackera 9y ago
      Nobody said learning API surfaces is the right way. Most of these frameworks offer fairly simple APIs that are frankly pretty trivial to learn --- the key is to learn the application architecture and why it's different than the alternatives. Anyway, I think we can agree that exposure to other people's thoughts, and also coming up with your own thoughts, is probably the most fruitful way to learn.
bl4ckj4ck 9y ago
Same here. We should remember that JavaScript is a language and React/Angular/Vue are just frameworks/libraries. The latter come and go, the former stays. Sometimes I just think that for JavaScript developers is simply difficult to choose, so someone created the "JavaScript fatigue". Even Java has a lot of frameworks and libraries to choose from, but I don't see any fatigue there. Probably we should just be less open to temporary fashions.
coldtea 9y ago
>It was said million time here. But if you don't like trying new stuff, learn one stack and stick to it. Nobody is forcing you to try new stuff and then talk about js fatigue. You'd be surprised -- since even single stacks change all the time. Try using React Router and keeping it stable. Heck, even React changes paradigms (from mixins and factories, to ES6 classes and pure components, to fibers, etc). And from pure React, to coming up with Flux, 4-6 flux alternatives, the Redux dominating, etc. And let's not get started with things like Angular to Angular 2 et al...
- finchisko 9y ago
  I would not be. React Router 4 is awesome. Wish I had time to write down why. But if you have reason not to upgrade, you can stay on version 3, which is still supported. Same with Angular. Of course there will be examples you're right, but not those two. ;-)
shusson 9y ago
> Nobody is forcing you to try new stuff and then talk about js fatigue. If you read the conclusion, the author is actually very positive about the entire experience.

rectangletangle 9y ago

Man... when it's laid out like that, it does seem a bit insane. By comparison Python's primary web framework in 2012 was Django, and today it remains Django. Despite this relatively glacial pace, there's been a ton of improvement to Django, and the surrounding Python ecosystem. A more conservative development culture can pay off sometimes, since it allows the community as a whole to focus on polishing the existing ecosystem. As opposed to dropping Django when "real time" Websockets were all the rage, there was a concerted effort to include it in the framework with the Django Channels project.

polskibus 9y ago
Don't forget that move towards microservices and Go caused many Django devs to move away from it.
- rectangletangle 9y ago
  That's certainly true for that particular niche. However Python has certainly come into it's own over that timespan, with the rise of various machine learning approaches. This reinvigoration, seems to have manifested in the web side of the language too, seeing as many models eventually need some form of HTTP server. Admittedly though the community isn't perfect. There was quite a schism over Python 2 vs 3 for a while. Thankfully it's looking like that may be past us. Anecdotally the Python community seems more active than ever.

nice_byte 9y ago

How do you end up with like six "build systems" for web applications? What even is there to build? Why can't you concatenate all javascript and run it through a minifier with a shellscript? I haven't done webdev since 2010 and now that I look at it, it just seems so bizzare.

chj 9y ago
One thing I like about JS is that you don't need to compile or build anything. I get it that you will need to bundle everything in production, but I am baffled that bundling can't be automatically done. The process should be transparent to developers.
- rimliu 9y ago
  if you use ES6+ and target not so capable browsers, if you use JSX you need to compile. And while you can write React without the JSX it is not something anyone would enjoy.
duval 9y ago
Yours do that if you want, but then you might have customers using large parts of the code base that other don't have access to so you want to use code splitting. You probably have some images and want them to look good on all screens but also want them to be a small size so you use image srcset but you need to output 6 images for all the sizes. If you're using svgs you might want to inline these. I mean it goes on and on really, just look at all the headings within the webpack docs if you want more insight. I can understand why it seems crazy and perhaps it is more crazy than I think but if you want you can just concatenate all the scripts, if you want more bells and whistles then you can too
- pdkl95 9y ago
  > code splitting That should only take a few lines in a Makefile. JSTARGETS = foo.js bar.js build-js: $(JSTARGETS) foo.js: foo_main.js lib_a.js lib_b.js cat $< > $@ bar.js: bar_main.js lib_a.js lib_x.js lib_y.js cat $< > $@ With make's builtin topological sort, adding dependency information to control the order or other unusual build requirements isn't hard to add. > output 6 images for all the sizes IMAGES=( baz quux ) IMGSRC=(patsubst %,src/images/%.jpg,$(IMAGES)) IMGSML=(patsubst %,build/images/%-small.jpg,$(IMAGES)) build/images/%-small.jpg: src/images/%.jpg convert $< -resize 25% $@ build-images: $(IMGSML)

TeMPOraL 9y ago

> I’ve only been a full time web developer for the past 5 years. It’s barely enough time to start calling myself a “senior” Software Engineer. Offtopic, but when does one start to be "senior" then? I've been coding for the past 17 years or so, including about 6 years professionally. Do I get to be a "senior" dev now? How do I convince my boss?

RandomInteger4 9y ago
Ask your boss if you can get a promotion / raise and if they deny you that, then ask if at the very least you can have a new title, then use that on your resume for your next job.
dagw 9y ago
Offtopic, but when does one start to be "senior" then? It differs massively from company to company. Where I'm currently working the guideline is 10 years relevant professional experience plus either significant project management experience or having an area where you can generally be considered an expert in your field. I've also worked at places where people 3 years out of school are considered senior.

superasn 9y ago

I really don't understand this hate for Angular 1. I think till date it is among one of the best things to happen to the web after jQuery. Yes, I think jQuery is great and Angular 1 is fantastic for making website super quickly and maintaining them.

rectangletangle 9y ago
Implementing unit tests always seemed excessively painful, especially when compared to React/Redux.
- superasn 9y ago
  In my experience it wasn't that hard writing unit tests for Angular 1 modules. They have a pretty solid testing framework built for it.
  - rectangletangle 9y ago
    Hard isn't really the right term, more just annoying, because you have to mock out everything and the kitchen sink. To be fair, I can't think of a frontend framework that had any real unit-test framework before Angular. So it was an improvement at the time.
RonanTheGrey 9y ago
I can't stand Angular 1 the framework or the language. I also credit them with promoting modern web development and producing a realistic expectation that browsers can actually present some really cool, sophisticated applications. It is largely because of Angular 1 (and other, less known libraries) that we currently are seeing an explosion of innovation. I may not have liked the framework, but I cannot deny the incredibly powerful (and in my estimation, positive) effect it had on the industry.
- superasn 9y ago
  You're right about that.. It's still my favorite framework even though I too have my pet peeves (no lazy loading, really?). Anyway, what are you currently using? Why?

deleted 9y ago

[deleted]

patatino 9y ago

I fell in love with web development over 15 years ago because it was just a request to the browser and an answer. I've worked on windows applications and just hated it. All this code handling the state of controls depending on the input/action. Sometimes I have the feeling I'm doing this stuff on the web again which I haven't for over 10 years and it just feels wrong.

aaron-lebo 9y ago
What's difficult about it? The underlying model is incredibly simple. You have a visual model/datastore that you manipulate and the UI changes as a result. Interactions with the UI drive events which might call out to a server or do a calculation, which in turn changes the view model/datastore and that changes the UI and so on and so forth... You probably get that, but I've down programming with wxPython, Qt, etc. I've done Django, Rails, Flask, etc. and frontend frameworks are so much more powerful and easier to use than those old models and getting them up and running takes a few minutes. When I see how much difficulty and how much anxiety this new tech is causing people it makes me wonder if the frameworks are just covering up how easy all this stuff is and how powerful it is. It's really exciting stuff, it sucks if people are missing that.
- skyisblue 9y ago
  Are you still using Django, Rails, or Flask to provide API end points to your front end? If not, what do you use?
  - aaron-lebo 9y ago
    Not a big fan of Ruby or Python as the backend server given the choice, there's just a lot of languages that do it better (Elixir, Clojure, Go for example). Django and Rails have a lot of extra stuff you don't need. But if you just want to get an api up quickly its really hard to beat Flask or even Bottle (not sexy but very simple) and I've never used it but Sinatra is supposed to be great, too. Microframeworks are great.

Animats 9y ago

“My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.” - Lewis Caroll, Alice in Wonderland Coming up next, WebAssembly for strong obfuscation.

tom_wilde 9y ago
The only winning move is not to play.
SamUK96 9y ago
Proprietary code blobs running in everyone's browsers. God what a recipe for absolute carnage...
- manigandham 9y ago
  We had that before with native plugins and extensions. We can also install random programs on any OS. It's really not a big deal.
- kronos29296 9y ago
  Is WASM really a proprietary code blob? Or the WebAssemsblers will be proprietary code blobs? Isn't it being done by guys at Mozilla, Google and folks. Or are you confusing Assembly lang that is used with different CPUs and this. If so try this: [1] https://auth0.com/blog/7-things-you-should-know-about-web-assembly/ https://auth0.com/blog/7-things-you-should-know-about-web-as... [2] https://gotechster.com/2017/04/web-assembly/ https://gotechster.com/2017/04/web-assembly/
- maeln 9y ago
  Javascript already does that. If you look at any website nowaday you will find minified JS that is impossible to understand. What's the difference with a binary format at this point ? It does not change the fact that those blob are executed in a sandboxed environnement with a permission system. At least WebAssembly is more efficient and will make it finally possible to use staticly typed langage for web developpment.

raquo 9y ago

JavaScript is a small language because it needs browser support and backwards compatibility. A small language that can't change much over time can't afford to have opinions on how to build dynamic interfaces. Therefore, all the complexity of building interfaces will be in the libraries and because opinions on such complex issues vary, there are many libraries to do the same thing. Eventually the interior ones are recognized and culled. They typically are supported for quite some time after becoming uncool, it's just that no one wants to work with lame, obsolete tehnology for good reasons. The solution I see to this are compile-to-JS languages that make it possible to use a different ecosystem of libraries than te JS one, like Scala.js. However, those tools are also still evolving, so one way or another you're dealing with a lot of library churn in frontend development right now, so learn to pick winners and stick to them until it's as weird to use them as jquery for complex UI was in 2012.

unclebucknasty 9y ago

I dunno. I'm starting to wonder if writing disciplined code with jQuery for support is a better approach than the framework soup we've been dealing with in recent years. I know, I uttered the "j-word that shalt no longer be spoken" but that's kinda' my point--what's wrong with writing code anymore? If you use simple, clean modular coding patterns, componentize for reuse, make judicious use of promises, and sprinkle in lightweight templating and routing libraries, etc., you'd effectively have your own mini-framework on which to continue building. After all, frameworks themselves are code under the covers--code that encourages patterns. Sure, some say it's reinventing the wheel to write JS without someone else's framework. But, it seems to me that the frameworks are re-inventing the wheel. Not only is there a new one every day, but they are even re-inventing themselves (I'm looking at you Angular). Looking at the mere scaffolding alone for some of these frameworks makes me think, "what are we doing to ourselves?". Generate an "empty" project on some of these guys and prepare to be overwhelmed with opinionated cruft. Rolling my own code is not reinventing the wheel, because Angular, et. al. are not the wheels I'd invent in the first place. Until a framework comes along that truly abstracts away HTML, CSS, the DOM and the rest of the old Web, so that it genuinely allows construction of clean event-driven, componentized applications, I'm not sure I see the benefit of playing the framework du jour game.

zer0tonin 9y ago
>Until a framework comes along that truly abstracts away HTML, CSS, the DOM and the rest of the old Web, so that it genuinely allows construction of clean event-driven, componentized applications So react?
- deleted 9y ago
  [deleted]
- unclebucknasty 9y ago
  More like Swing.

shubhamjain 9y ago

I think the problem is more common than people think. It takes lots of bad frameworks to establish a single dominant one. It reminds me of the similar issue PHP landscape was fraught with—lack of a framework/approach with no downside. Figuring which PHP framework to use was a problem of choosing between dozens of options, each with their own mighty cons. Every time a new framework came, it demonstrated an ability to fix all the known problems but time and again it faltered (Kohana, CakePHP, Yii). In the recent times, Laravel has provenly become a better choice than what was available only a few years back. It has grown a community of a considerable size and it's unlikely it would getting supplanted in future. I am guessing at some point in the future, the landscape would stabilise and a single approach would become the obvious choice for JS just like Rails is for Ruby.

aaron-lebo 9y ago
You're right, it is common and it's easy to forget that. Python in 2007 was Django, web.py, Subway, Turbogears, Pylons, Werkzeug, Zope, and a bunch of tools a lot of people have never heard of competing for space. Who needed all of those frameworks anyway? It took awhile but slowly what works and what doesn't was figured out and we've got better approaches. Web programming circa 2007 was by its nature simpler and despite that the Python community (which is a blip compared to the JS community today) churned out a lot of stuff. You can still build websites like it is 1999 but you've got a lot of other options now, too. Use the best parts and dip your toes into that stream of new stuff when you feel like it. Competition and progress beat the hell out of stagnation though.
fetbaffe 9y ago
I hope that never happens. Why? Frameworks solves a generic problem, but you in your project are solving a specific problem, hence you can never solve your problem better than what the Framework allows you to. Problem is rather developers don't know how to organize their code without the help of the Framework. If they knew, Frameworks would not be needed, only libraries. One Framework to rule them all will stifle progress, it locks the community into one size fit all mentality and therefore clouds the minds of the developers to not think about the possibilities outside their worldview. Laravel will, of course, eventually be replaced, as with all frameworks. Current hype now are "micro" frameworks. So all that effort put into the Framework will be partially lost due to it is locked to that Framework. Lessons learned ought to be, write reusable framework independent libraries instead.

holydude 9y ago

My advise is when you care about your "career" stick to the one with the largest user base (or depending on your location). Learn it, love it, embrace it. Then experiment with whatever you want to.

sutee 9y ago

While it's easy to get frustrated especially if you are following each twist and turn that js takes, I think if you step back a little, you can see things are getting better as a whole. For the longest time, js was just a thing I did on weekend or as part of tertiary projects at work. I first used js as a kid for my geocities page, used jquery and YUI for a work projects starting about eight years ago, experimented with Angular, and most recently embraced React and es6. Almost two years ago, I quit my job and started building a side project in React and Fluxxor for fun. At this point there were a bunch of Flux implementations and no dominant library had emerged. I got frustrated with the build process and then got distracted with other life experiences. I returned to javascript less than a year later and was amazed at how much better things got. I could do npm install and npm start and there was a good chance things would actually work. I was doing the same google searches but noticed that the documentation was a lot better. I also had a friend this time around and he steered me toward Redux and es6. Javascript suddenly became an enjoyable language for me enough that I plan to focus on it. This is after more than close to twenty years of fits and starts.

alanfranzoni 9y ago

To me, it is incredible that the frameworks matter THAT much in the JS world. Once you know about Javascript, the web, and browsers... any good dev should be able to pickup such part of the tech stack (frameworks, libraries, ecc) quite quickly. In other environments (e.g. Python, Java) nobody expects you to know everything about the specific libraries used in a company; once you know the language and a bit about the technologies (e.g. work on Linux, on a webapp or a desktop app), you're good, you'll pickup the details while working. Forcing a technology change because it's not the "latest and greatest big, shiny thing"... I find this is a slightly disturbing trend in frontend development.

kutkloon7 9y ago
This also has to do with browser compatibility. Vanilla Javascript sucks so hard because it's so difficult to write non-trivial stuff that just works. This is the whole raison d'être for JQuery. This is mainly because the different browsers don't coordinate and there is no official standard. It should have been obvious from the start that this is a recipe for disaster.
shams93 9y ago
It's not an issue with JavaScript it's that the Dom has always been horrible. It's actually slowly improved but not enough to do without the need for frameworks for complex front end applications.
- maxxxxx 9y ago
  I think that's the real problem. Most JS frameworks wouldn't be needed if the DOM was designed for what it's used today.
- fenwick67 9y ago
  Yes yes yes. Simply creating nested elements and getting references to each of them is such a huge pain, and it's a huge part of why frameworks are needed. You would think creating, say, a form with a button and a textarea, and getting references to those things would be simple, but it's crazy painful in vanilla JS.

prashantswain 9y ago

If you seek legitimate hacking service ,contact hdmoore.hacks@gmail.com ...dude's a cyber guru, involved with cloning phones, hacked into my ex's gmail and facbook, what let me knowing she was infidel and also gave my nephew some really outstanding school scores which he upgraded himself, cool way to have financial freedom as well. Get your bank blank atm cards which could debit money from any a.t.m machine. Make $20,000 and more in a couple days. Bank transfers and wire transfers as well as Paypal jobs, hes that good, had to make him my personal hacker. You could mail him as well if you got issues, he's as discreet and professional too. He's kinda picky though so make mention of the reference

mstijak 9y ago

I fully agree with the OP. I used Bootstrap/jQuery, Ext JS, D3, Highcharts, Angular and React. Each of these felt right for a period of time. Now, I'm using my experience to put the best features of all these into my own commercial framework called CxJS - https://cxjs.io/ https://cxjs.io/

manigandham 9y ago

From the article > How much has medicine, accounting, politics, law, construction, or math changed in that time period? The webapps that services those industries has changed massively in the past decade. The web has evolved from simple documents to complex applications. The browser is the new app delivery platform, and it's perfectly reasonable that this would bring increased complexity. Backend development has countless languages, compilers, frameworks, toolchains, CLIs, OSes, containers, etc. - so it's really not that strange to see frontend dev catch up. What's rather amazing is that there's just 1 language with everything else being frameworks and tools that let you shape it to your needs (and also runs just as well server-side with nodejs).

richardknop 9y ago

Another option to avoid this JS fatigue is to switch to a different web development job. Get a job which focuses on backend and APIs. Or you can even take it further and go focus on more networking / sysadmin / devops area. Les fatigue there.

preordained 9y ago

All this great "progress" and "innovation"...and yet, have you been out there lately? The web? Everything just barely works, and I haven't the slightest illusion that I'm using anything but a patchwork networked application. Most times I'm trying to kill or avoid whatever the hell this page is trying to do and just get my text or content, or submit the stupid form. I feel like if the front-end dev world is so keen on reinventing itself, it should just go all the way...repackaging HTML/CSS/JS in new and interesting forms and frameworks isn't getting anyone anywhere, IMO. Scorched earth, a new protocol for web applications...don't even call it the web anymore...just put on your CS hats and start over...kill the whole thing with fire.

noshbrinken 9y ago
The last part of your comment blames front-end developers for the shortcomings of the web platform. I think many would be interested in a more uniform, stable interface. But they're not the ones with the power to change things on the protocol layer.

fetbaffe 9y ago

Frontend development in JavaScript has become a hellhole. Projects can have three plus build tools that each take a long time. Massive list of dependencies plus bad dependency management, lack of documentation, everything changes so fast you need to find the correct stackoverflow answer for this week solution to your build problems, build tools depends on other build tools configurations in undocumented ways, reimplementation of the model & business logic of each project, constantly reinvention of the wheel. And the end result? Web just becomes slower and slower. Developers today build software that fits their paradigm, not the users experience.

lllr_finger 9y ago
That last sentence succintly describes my primary issue with front end developing, and why I'm starting a new job in a few weeks that is almost purely backend. Most of my recent web work has been trying to manage shared libs and duct taping the build process together. Every feature branch has major shrinkwrap merge conflicts because there is so much module churn.
jbreckmckye 9y ago
I am currently working on a Node/React project with 120 first-order dependencies. 120! And it's just a crud app with a few canvas visualisations.

Yuioup 9y ago

I'm curious about the statement "React has become the champion" I've recently moved from ASP.NET MVC/jQuery to Angular4. I'm extremely happy with the transition and I intend to stick with Angular. After not worked with React (yet), what am I missing?

akras14 9y ago
Nothing, its mostly hype. If Angular works for you, you are not missing much
RonanTheGrey 9y ago
These days I split my time between React & Angular 4. I love Angular as much as React. Both very cool platforms to work on, if you are happy there, stick with it! There are tons of jobs these days on the new Angular.

ericssmith 9y ago

That conclusion made me laugh. In the early to mid 90s, I was working on 3D interactive software. The video drivers and chips had advanced so much in one year that all of the lovingly handcrafted assembly I had written over that time was useless. I thought to myself, "what an unstable industry to build a career in". I also made comparisons to accounting, medicine, and law, thinking perhaps I had made a wrong choice. Turns out that adapting to rapid change is a critical aspect to this career choice. It is also a problem for businesses, which you start to grapple with as you move up the chain of command. The mistake is wistfully hoping that things would slow down enough for you rest on your hard-won knowledge, as in other fields. There is no competitive advantage in aging technology.

deleted 9y ago
[deleted]
0xdeadbeefbabe 9y ago
> as in other fields Well maybe it isn't a field after all. Maybe it's "pop culture" like this cranky old guy says https://www.youtube.com/watch?v=FvmTSpJU-Xc https://www.youtube.com/watch?v=FvmTSpJU-Xc.
geebee 9y ago
There can be a competitive advantage in aging technology. For instance, suppose you were writing an app that makes heavy use of scientific or ML libraries in python, but your UI is a mainly layout and forms with admin, login, accounts, and so forth. I could easily see huge advantages to keeping it in python, using Django, with a bit of CSS and javascript sparsely applied where needed. Some of this comes down to personality, too. A lot of people talk about how people were abandoning ruby and rails once it was no longer the "new hotness". Plenty of us (who like rails) came to it somewhat reluctantly, only after the benefits were very clear and the initial chaos had started to subside. We, the reluctant ones, just tend to be a bit quieter about things. I think we're reluctant because we see greater danger and risk in a constantly evolving set of technologies, and we don't like spending a lot of time figuring out how to get a drop down list to populate, not when there's limited time and there's value to be added on the back end. I've been at this for a while, and I'm getting more and more ok with sticking with an aging technology - even when I know the technology is becoming obsolete. Right now, it's pretty clear to me that web based UIs in the future will be more asynchronous and elaborate, but there will be a lot of false starts and dead ends as we get there. Remember spring mvc, spring di, iBatis, hibernate, tapestry, pico, tiles struts, struts 2...? Yes, the old request-response servlet with jdbc was unlikely to remain a choice for new development, but honestly, I think it might have been a good idea to stick with it for a while and stay out of that mess. Yeah, you'll need to change and adapt, but that doesn't mean you need to jump into the swirling mess. ...unless you do! There are, of course, remarkable opportunities when a new technology hits, and if you wait for it to settle down, you may often find that others have too great a lead. You just really need to figure out if that's you. Because otherwise, you may find that instead of improving the accuracy and speed of some critical calculations your users need to improve their supply chains, you instead spent all your time figuring out how to asynchronously update a drop down list depending on where they clicked on a map. And a round trip to the server and an extra second to load that drop down list might not have been all that big a deal compared to the actual business use of your app.

drumttocs8 9y ago

Can anyone tell me why I shouldn't still just use standard, ECMAScript, and (gasp) jQuery? There's so much churn in the JS world, sometimes it makes sense to just build something, and then optimize it later.

kcdev 9y ago
For small projects, this is definitely still OK. Green browsers don't really need jQuery any more, but if it's what you're comfortable using and it gets the job done, then use it. Large projects or team projects, you will want to use something with more structure.
- aaron-lebo 9y ago
  Some of the newer frontend frameworks are so small that it really doesn't benefit you to use jQuery even for small projects. It lacks structure and it's way too easy to start manipulating state though the dom when you could have reusable components and a decent structure with a few extra lines of code.
lxrbst 9y ago
No one is seriously saying you can't. If your problems are simple enough to be solved with plain js/jquery, feel free. I don't get all this tooling and framework hate - no one is forcing you to choose anything, it's an open buffet, and you can choose as much as you want from wherever you want, for free.
- unclebucknasty 9y ago
  I think he/she is saying the opposite: that people who don't use frameworks get the hate, and there is a lot of pressure to pick a framework. Not an invalid point. Mention jQuery here, or anywhere, and witness the response.
chasing 9y ago
Remember that part of being an experienced developer is having the wisdom and knowledge to select the right tool for the right job. Sometimes that's the hot new cool shit. Oftentimes it's something much more mundane. If you project calls for "standard, ECMAScript, and (gasp) jQuery," then use them! Just be aware of the benefits and trade-offs.

vmware505 9y ago

Why I've never seen any Ember.js dev writing about javascript fatigue? Because healthy community, matured framework, happy developers never felt that. Ah, and there are plenty of jobs with much higher salaries.

hugs 9y ago

Every time I read an article like this I wonder: "Where are all the three.js users? Am I the only one? And am I the only one not suffering from JS fatigue?"

draw_down 9y ago

Just a thought, but: you don't have to write JavaScript. There are lots of other languages than JS, and lots of areas of programming other than the web. So it's really, really possible to not write JS if you don't want to. Just think, you could be free! Forever!!!!!

gotofritz 9y ago

Oh not another one of these I have "JS Fatigue" fatigue