JavaScript development is not fun for me anymore

I don&#x27;t think there&#x27;s that big a problem with how many front-end frameworks there are, and the pace of development. I think the problem is people who feel they have to use the latest and greatest feature and they have to know all the frameworks.<p>At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we&#x27;re doing fine as it is.<p>Two years later and we&#x27;ve barely changed aside from some package versions. We&#x27;ve got a very stable front-end with high code quality and component reuse.<p>You don&#x27;t have to listen to the hive-mind. Frameworks don&#x27;t rust.

But JS dev has never been fun.<p>Web dev is fun because the browser is a freaking awesome plateform.<p>However, it is _despite_ of JS.<p>There&#x27;s not a single characteristic of this language that makes it better than any other mainstream high level language out there. We use it because we have no reasonable alternative on the browser. It has always been a pain to use, requiring:<p>- avoiding part of the language that is badly designed to escape traps.<p>- recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc.<p>- fight with the various implementations to find some code that will work for most of your customers.<p>- use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS.<p>The fact that the community is now shooting itself in the foot by providing so many incompatible, badly documented and breaking-compat-all-the-time tools is just icing on the rotten cake.<p>P.S: since this comment is getting upvotes, I will say that having used in prod vanilla, jquery, react, angular and Vue, I will stick with Vue for the next years. I&#x27;m done. My quest is over. It takes 3 hours of reading to be productive with it. It requires no tooling and yet can be used with existing tooling. It&#x27;s fast. It&#x27;s well documented. I can now focus on writing software again.

React + (early flux and later mobx) made web development fun again for me. I was burned out at the end of the jquery era with all the different homemade structures and the limitations of browsers.<p>Then I came back to React and babel&#x2F;gulp (later webpack). Suddently there was structure in the front end that was easy to get into a project and contribute. Building components just felt right. Also js was almost a modern language now and I could use it even if the browsers did not actually support it yet.

Just pick one and stick with it. There&#x27;s some serious FOMO going on in the JavaScript community. When you read articles talking about all the great benefits they see from switching frameworks, <i>what you don&#x27;t see are the gains they&#x27;d have if they just rewrote everything in the same language&#x2F;framework, taking advantage of the increased experience since the original write.</i>

14 year .NET veteran here. For me Javascript (actually Typescript) using Vue as the front-end reinvigorated my joy of creating web applications again.

I totally agree with the sentiment. While others tend to use SPAs with their complex build system and lifecycle for everything, I follow principles of ROCA [1]. I don&#x27;t understand why people think it is better and faster to make complex clients that include logic, that has to be verified on the server anyway. Everything I saw &#x2F; see in the enterprise world is reinvented for client-side development again.<p>[1] <a href="http:&#x2F;&#x2F;roca-style.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;roca-style.org&#x2F;</a>

The last time I&#x27;ve really touched JavaScript is about a year ago, I&#x27;m just working with Python these days. Thinking back, I had 2&#x2F;3 newsletters about JavaScript and whenever I&#x27;ve read them there was a headline &quot;why X is better than Y&quot;, &quot;Y has no chance against Z&quot; &quot;Good old X is better than Z,Y&quot;.<p>I was always feeling, that I&#x27;m missing out on something and that I needed to learn new things. Switching to python actually made writing code enjoyable again.

I teach a course at upenn on intro to javascript. Perhaps the most useful advice I give to my students is that often the simplest tools will get the job done i.e. you don&#x27;t need React, Redux frontend stack because for most cases jquery will get the job done much quicker. Only worry about the frontend libraries when you feel it&#x27;s getting out of hand, otherwise, the simple, straightforward tools will suffice.

The desire to constantly switch JS frameworks is really confusing. I find each one different, exciting in their own way and fun to learn. However, and this is a big however, none of them radically change the work you&#x27;ll create, so I&#x27;m happy with React, and not interested in learning just to learn. Maybe in a year or two, I&#x27;ll try Vue, it won&#x27;t be too hard to pick up.<p>If you&#x27;re at BigCo making internal apps, each one is basically dressing on a way to make various interactive UI states. How you get there is no big deal. How the data flows is no big deal. What test runner you use is no big deal.<p>As a JS dev, my passion is to learn completely non-JS related things. Cryptography, Blockchain, CS Fundamentals I missed. These are much more interesting than the churn.

Speaking as someone who has seen the ebb and flow of frameworks galore on the front-end and back-end, I&#x27;ve found many devs swing back and forth between love and loathing. It&#x27;s just a natural evolution of how we use tools, and quite often the over&#x2F;under application of those for the problems we&#x27;re trying to solve with them.<p>We&#x27;ve never had more options available to all of us to build complex systems, applications and services using highly-targeted tools. The new-framework-a-day pace at which these become available to us is fine, but honestly doesn&#x27;t move the needle for most of us.<p>A former leader of mine once said: you build things with tools, not popularity contests. I&#x27;ve found keeping such a perspective makes my stress level manageable.

&gt; After I was done with the front-end of a project, I hated that I had to do the back-end. I also was not good at it.<p>After many, many years of tutoring students in a variety of subjects, there is definitely a connection between the last sentence and the first. People who work hard to get good at a particular subject often find themselves enjoying it a lot more. But humans don&#x27;t care much for delayed gratification. If we have work that we could be doing that we enjoy more than some other work, than the hated work gets put off. Often indefinitely, as no skill in it ever gets developed, the more it is put off.

I think this is a good description of how front-end development has become a &quot;tool zoo&quot;, where new versions of libraries and frameworks are often radically different, and new libraries&#x2F;frameworks keep popping up. I compare this to Python, where most of the time learning a new library will keep paying off for years and years. It makes front-end development an expensive (educationally) place to work, and the maintenance costs of the code are substantial.

&gt; How to use styled-components to make JavaScript in React do what CSS can do on it’s own.<p>Stopped reading right there. CSS-in-JS is one of the main reasons I&#x27;m even using React to begin with.

Spend your time learning something that isn&#x27;t subject to fads. In five or ten years, React will be a distant memory. Just like all the PHP frameworks are now.<p>Focus on getting good at the web platform standards. I personally jump at any opportunity to learn new web platform APIs, graphics techniques, design patterns, data structures, and different business domains, and stay away from technologies that are fad-driven.<p>Get good at a few basic tools and focus on application development. It&#x27;s not about the code its what we make with the code.

I hate JavaScript with a passion, but 95% of that is fixed with TypeScript. But the thing that TypeScript can&#x27;t fix isn&#x27;t really related to JavaScript, but rather everything around it:<p>1) Build systems suck. Millions of plugins and adapters, opaque json configurations, silent errors, finicky and difficult optimizers, source maps upon source maps, shims everywhere, etc.<p>2) Browsers have unpredictable noncompliance with standards, HTML doesn&#x27;t work well for user interfaces, CSS is obtuse, etc.

I started to feel the same way as the author when 2016 rolled around. I found myself getting caught up in the paranoia of using the latest, greatest, most popular (i.e. supported) framework. Teammates would come to me with a bunch of proposals about how to use X over Y. We questioned continued use of Angular 1.x and had similar negative experiences with the build processes around the latest javascript frameworks. It really had gotten a bit out of hand considering our scope.<p>I found the light at the end of the tunnel with Riotjs. It is close enough to the bare-metal JS runtime to keep you sharp in that regard, but also provides a lot of utility around building components without tying your hands in any particular way. For someone who is trying to build the best UX experience possible, I feel like riot or even vanilla JS provide a much better experience for expressing yourself.<p>Front-end frameworks seem to me to be just a way to systemize the UX&#x2F;UI problem into a thing that back-end engineers can reason with. Staring down a blank HTML&#x2F;JS&#x2F;CSS document without any constraints imposed on you can be a very daunting task until you truly get a feel for it. I strongly believe that one can be VERY productive on even the most complex web project without use of any frameworks, assuming they have the correct &quot;artistic&quot; mindset and the ability to balance that with systemizing the problem. My perspective is that the web is 3 languages (HTML&#x2F;CSS&#x2F;JS) and they need to be treated as equals. Any time you bring in a framework that does not consider all 3 with the same priority, I strongly feel like you are losing something.<p>Since switching to riot&#x2F;vanilla js, I have spent WAY more time thinking about how I want the UX to be than how I can force it into the various boxes some framework wants me to. In the Angular world, things like &quot;it would be nice if that checkbox turned into a DDL when checked&quot; would result in sweaty palms and much googling for phrases like &quot;dynamic element swap directive&quot; and an entire afternoon wasted. When you are used to working with DOM directly on a daily basis, this is a hilariously trivial activity requiring about 2 seconds of deep attention.

Despite its flaws I tend to stick with Backbone whenever I need to do anything sufficiently complex on the frontend, and jQuery if it&#x27;s any simpler. When writing software for money I&#x27;ve always found it pays to take a conservative approach.

It sounds like he doesn&#x27;t dislike JS, he dislikes what web development has become.<p>I dislike build tools and all the little doo-dads that we <i></i>have<i></i> to have now. Like, sometimes I just want to write some CSS and launch it with `npm start`

My biggest complaint about Javascript development is the config... OMG the config. So many modules, so many dependencies, so many build steps, so much half-baked documentation, so much assuming that you already know X, Y, and Z.

To put a finer point on his argument; I&#x27;m working on an Angular project at the moment. Every time I refresh the page I have to wait 10 seconds before I see any of my changes while Angular compiles everything. I calculated that, given the number of times I have to refresh to test my changes, all of those 10 second compilations is costing my client tens of thousands of dollars every year in wasted productivity. So I can&#x27;t help but wonder how Angular and their ilk are better?

$ ls node_modules | wc -l =&gt; 872 * Starts crying <i>

It&#x27;s been fun again since I stopped worrying about keeping up with framework churn and all the tooling. I still feel bad when people ask what framework we use and I can rattle off a list of trendy new stuff but I quickly remind myself how asinine that is and go back to making perfectly fine, successful-in-production JS apps with stable boring things like ES5 and Backbone.

&gt; So that’s why I’m now learning to be a Web Animator and UX Designer.<p>Has anyone played around with the Web Animations API?<p>I noticed that Chromium now lets you use elem.animate to animate SVG elements-- even properties like &quot;width&quot; which aren&#x27;t technically presentation attributes in the 1.1 spec.<p>Anyway, it&#x27;s a very handy interface and easy to play around with inside about:blank to prototype things.

Well, that&#x27;s what happens when you move the problems from the server to the browser (routing, dynamic data, auth, etc). instead of focusing only on UI you are working on a complete application.<p>I like making SPAs, but there is really no need to do that. In many cases making an SPA is not even desirable.

Using Typescript with Angular2 + RXJS is like my second wind and a breathe of fresh air. It&#x27;s like web development is &quot;real&quot; software development now.

&gt; [Front-end is] looking more and more like the back-end<p>This rings true to me. It&#x27;s also partially why I don&#x27;t really mind front-end development like I used to.

I must admit having a hard time relating to all the complaints over js churn and the new world of...compiling code. I hated website dev in the past, hated using jQuery, hated being driven insane by the css cascade, hated wasting all my time on arbitrary and stupid browser incompatibility bugs with magic arcane solutions.<p>I develop apps---not traditional websites---so I know this colors my experience. But every single tech change that I&#x27;ve made the past 4 years has been motivated by a real need. (Of course this assumes I have control over the tech: I&#x27;m grateful that I&#x27;ve only been forced to work on one Angular project for work!)<p>I started using React in December 2013 after a shootout of the competing view libraries at the time because I didn&#x27;t like having to be Sherlock Holmes to figure out how to change someone else&#x27;s (or my own!) wild jQuery code, and I always inarticulately felt like I was fighting against a natural flow when using the old MVC frameworks. I now haven&#x27;t churned my basic framework for almost <i>4 years</i>. And don&#x27;t expect to for many more! (I know that to an extent I got lucky: it&#x27;s easy to forget now how much shit I got at the time for using dumb React lol compared to Angular). Ember is fascinating, I&#x27;m glad Preact, etc is around as a backup...but churning would solve no problem for me, and most jobs I&#x27;d get (for years now) require React, so why worry about changing?<p>I&#x27;ve been a redux user for over <i>2 years</i> now. I eagerly switched over the codebase I was working on because it solved a need I had: getting rid of a bug-prone, undocumented state solution of my own design which everyone else had to figure out for themselves. I expect I will switch out redux one of these years. But haven&#x27;t seen anything to motivate it yet. Mobx-state-tree is very interesting, but until I see the benefits are worth the switch, why churn?<p>I did really hate having to worry about babel, webpack, etc since it distracted from writing actual product code, though ES6 was just so obviously better than old JS that it was worth it. But now create-react-app and its siblings make the dev environment a matter of typing a single command. Contrary to this article, it points out errors that could easily have gone undetected in the the old world of wild web dev. No churn here. CRA all the way. Until I run into a need for something new.<p>Styling solutions are something I have actually churned. But because I knew I wasn&#x27;t committing, all css-in-js library code I write is in two or three &quot;ui library&quot; files. The app code itself only uses a jsx prop interface. So swapping these libraries on a mature app takes an afternoon at best. Though for the first time I now expect that I&#x27;ll stick with Glamorous. I expect I&#x27;m going to stop churning here because I&#x27;m aware of no problem I personally have that Glamorous does not solve, unlike previous css-in-js libraries.<p>I don&#x27;t know, this guy&#x27;s rant just put me in the mood for ranting lol. Anyway, I&#x27;m glad this guy found his real interest now might be as an animator and UX designer and I wish him the best! Those are important contributions too, possibly more important.

He wasn&#x27;t a programmer since the beginning. He was a designer.

I think Framework-itis is a result of front-end developers—who are often junior developers who may not even have CS degrees—inculcating the false message that they are not &quot;real&quot; developers. As an industry, we have treated front-end development work as entry-level, occasionally even frivolous work, as it grew organically out of the left-over work that systems developers gave to the designers.<p>Developing a framework doesn&#x27;t look very much like doing front-end work; frameworks are generic, planned, and built from scratch, whereas the typical front-end developer is used to making highly-specific, ad-hoc changes to existing code (either because they&#x27;ve come in on a project started as a proof-of-concept by more senior developers, or they&#x27;ve used a boilerplate generating tool). Being more like so-called &quot;real&quot; software development, only &quot;real&quot; developers should be allowed to work on something ostensibly so important and complex as a &quot;framework&quot;.<p>The front-end developer has been indoctrinated into believing she (and it&#x27;s very often a she, &#x27;cuz design work is women&#x27;s work, amiright?) has no business writing code, and that the code she does write is woefully &quot;WRONG, WRONG, you&#x27;re doing it wrong! What are you even trying to do?&quot; by the karma-craving, bottom-feeders of StackOverflow. To avoid further public shaming—lest there be some hidden defects their inexperienced eyes cannot detect, no matter how trivial the bit of code may be—they avoid the actual act of writing code as much as possible and spend an inordinate amount of time searching for packages that may be imported from the gods. Thus left-pad, and the ensuing post-hoc rationalization in that debacle&#x27;s aftermath that such trivial micro-packages are somehow a <i>good</i> development practice.<p>I don&#x27;t think there are a uniquely numerous quantity of framework projects in front-end land. Systems developers make custom tools all the time. But systems developers don&#x27;t have a general fear, uncertainty, and doubt about their own work sewn into them, so it&#x27;s more common for systems developers to jump into writing their own code than looking for pre-existing tools in whatever they might deem as trivial. Instead, I think a plethora of front-end tools reach a unique tipping-point level of popularity giving the <i>perception</i> of many more tools total, because of a general fear of falling behind. The front-end developer sees themselves as having no business criticizing their &quot;betters&quot; and must therefor accept what is handed down to them without question. If the front-end developer cannot prove they are a good little worker bee by keeping pace with any and all frameworks their benevolent employer or more-senior, more-&quot;real&quot; coworkers may spring on them, they risk having to go back to working as a barista.<p>Something to think about while replying to a seemingly &quot;simple&quot; questions.

<i>&gt;Plus, now I have to learn what Redux is, and how Vue is the next best thing that happened since Angular 2.0. How to use styled-components to make JavaScript in React do what CSS can do on it’s own.</i><p>I&#x27;m glad I get to call the shots where I work, and I&#x27;ve steered my team clear of all of this stuff. If you have a deep knowledge of the core technologies -- HTML, JS, and CSS -- you can build a great front end with a reasonable amount of time and effort. If something breaks, it&#x27;s likely going to be our own code, and much easier to diagnose and fix.

Please try TypeScript. It&#x27;s the only tech I will actively promote as &#x27;not a fad&#x27; but a very useful thing. So useful, I stopped writing JS the first day I tried TS.<p>For anyone with a background in classical software, it makes JS &#x27;feel more real&#x27;.<p>I can&#x27;t imagine writing more than 50 lines of JS anymore.

JS moving in the direction of being compiled, statically typed, and adding lots of boilerplate for various reasons. When I started writing JS, it was partially to get away from these things in the .NET world. So, to be honest I don&#x27;t enjoy these changes in isolation, but I understand why they are happening.<p>I like that we&#x27;re starting to think in a more systematic way about how to organize applications, and I think that bigger codebases and teams probably benefit from using static types. But god, sometimes when you open up these codebases they sometimes hardly look like JS anymore. Not to mention the tooling and build stuff, which still have a lot of maturing to do.