I vividly remember 2016. I was doing backend programming at the time, but no one I knew were using Angular.js at that time for new codebases.<p>React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle.<p>It's been 5+ years since then, and React JavaScript world was remarkably stable. Fashion changes were largely superficial: React.createClass vs ES classes, Heavy use of Decorators vs not using them, and now Hooks. These were mostly cosmetic choices, and if your team picked the wrong side they could migrate over relatively painlessly or straight up ignore the issues for years.<p>On the other side of spectrum we have Ember that maintained backward compatibility and ease of upgrades since ~2013, Angular 2+ is doing the same for many years, too.<p>The whole "JavaScript fatigue" meme has to go.
A good way to not be completely overwhelmed by all the new tooling and frameworks is to have a strong grasp of the fundamentals, here are three foundational resources:<p>"You don't know JS": <a href="https://github.com/getify/You-Dont-Know-JS" rel="nofollow">https://github.com/getify/You-Dont-Know-JS</a><p>"How browsers work": <a href="https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/" rel="nofollow">https://www.html5rocks.com/en/tutorials/internals/howbrowser...</a><p>"High performance browser networking": <a href="https://hpbn.co/" rel="nofollow">https://hpbn.co/</a>
I'm a little lost on the examples.<p>There are reasons to use fetch and hooks, and the article seems to relegate them to being unnecessary 'trends' without doing what it suggests, actually evaluating what value they might have...<p>In React you can use hooks with a class heavy application and still be just fine / get the benefits of hooks in a given component(s).<p>If you want to use fetch, that also is hardly an ordeal to do / should not be a big cognitive load for anyone.<p>I get it, resume driven development bad, we get it, we hear it in opinion pieces all the time. Also you should think about it before rewriting an entire application. Yup, that makes sense.<p>But here we have examples of small changes that are pretty light weight... and no effort is made to do exactly what it suggests, evaluate those choices.
I find it interesting the blog post mentioned Kent Dodds article recommending everyone rewrite fetch. I just argued adamantly against Redux docs about writing tests being switched off of Enzyme to his library because it’s “more trendy”.<p><a href="https://github.com/reduxjs/redux/pull/3708" rel="nofollow">https://github.com/reduxjs/redux/pull/3708</a><p>Unfortunately, the community overruled me and the docs no longer show how to test Redux apps with enzyme. It only shows Kent’s “react testing library”. The library authors are complicit in this. Rather than showing the pros and cons of both, the trends are being pushed, leading people to falsely believe they must rewrite their whole code base in my experience.<p>The troubling part for me is often those creating these trends may be working on a very different type of app. When you’re writing something complicated, and the ecosystem is dominated by patterns (also preached by Kent) that work best in simpler apps like “only write integration tests” it can be frustrating.<p>If Kent thought enzyme promoted anti patterns he could have technically made a docs PR or just written a thin layer on top of enzyme. Now we have yet another divisive issue. Getting him early access to new react apis and officially recommending RTL in the react docs (while he sells his training videos) make it sit worse with me. It doesn’t feel like the trends are always based on the merits, it feels more like “not invented here” and “nepotism” driving some of these trends for sure.
Shiny new thing (SNT) comes along, sales people and thought leaders get excited about SNT because they can sell it, everyone piles on as SNT picks up more and more hype, SNT falls apart as soon as it hits real world use cases, sales people and thought leaders start looking for new SNT and the cycle repeats.<p>I can not stop the cycle. You can not stop the cycle. All we can do is notice it and let it pass and hope some SNT will eventually be useful instead of pure hype. Oh, and also, avoid joining any cults: <a href="https://www.infoworld.com/article/3440104/10-software-development-cults-to-join.html" rel="nofollow">https://www.infoworld.com/article/3440104/10-software-develo...</a>.
From a developer perspective, changes in frontend web development have been pretty dramatic: CSS Grid / Flexbox, React, WASM, extensions to the web API, lots of new JS features, countless frameworks, plugins and build tools more homogeneity between browsers. There is always lots of change and excitement.<p>I wonder how much of that "innovation" really makes a difference to users. As a programmer, I get a bit cynical about having 50 ways to do the exact same thing. What is possible today that was very hard to do 10 years ago in web dev land?<p>If we think about users first, maybe we can feel a bit less guilty of not having deployed React Hooks to prod yet?
As a software developer I consider the most important part of my job to be evaluating new tools and techniques. This craft is in its infancy and our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget. Nobody can afford to miss out on productivity enhancements and that means following trends, but with a critical eye. If someone is "tired" of this process it might be time to consider another profession.
The user does care. At a previous company we started migrating from angular to vue. Vue was so fast that those parts would be completely rendered and the rest would be white. It was also snappy.<p>Of course, one has to be mindful about the transition. You cannot stop business, but you can take a little extra time whenever there's need to modify a section to improve quality (both code and ui). Actually that's why we chose vue, it allowed to a progressive migration out of angular.<p>BTW, someone had the "great" idea of not using a framework for an internal admin portal. It turned immediately into a huge ball of mud.
On the react bandwagon for almost 5 years now and haven’t regretted it a single day. Started using it because it allowed me to build d3-type data visualisations but with way more flexibility in terms of hierarchy and grouping of DOM elements in what for me felt like a very intuitive format of components and JSX. So I would say thrust your own judgement when considering which tools! Not all trends are pure hype, there might be something real behind it :)
Almost every time it is better to invest in learning your framework well and learning patterns to work around framework's issues rather than learning a new framework.<p>First, it is naive to think the new framework does not have any problems. Marketing would like you to think everything is perfect but if that ever happened, why do we have new frameworks all the time?<p>Second, you will pay with decreased productivity while you are learning the new framework and you are not guaranteed to be more productive than with the old framework.<p>Third, due to decreased initial productivity, even if you potentially get more productive with new framework, it is going to take time to realize any benefits. If you are switching the framework too frequently you are cutting yourself off from the benefits.
I feel like these problems are endemic to React and the surrounding ecosystem.<p>Since its introduction in late 2016 Angular 2+ has had no major changes on the scale of hooks and is unlikely to introduce them, because its target audience - large companies making large-scale applications is fairly conservative.<p>Vue I think had one measurably large syntax shift around v2.5(or 2.6) and will have another one with 3.0, but that's about it.<p>Meanwhile in React every year there's this new convention that isn't explicitly mandatory, but for some reason "cooler" than the previous one.<p>All this won't matter once the next gen compiler-frameworks reach maturity. My take is that hooks are React's swan song.
Not just JS. JS is an enormous ecosystem, so it shows this issue, but pretty much all tech (and other industries, as well), have the same problems.<p>We can have problems when folks start suddenly painting "The New Thing™" over classic designs and architectures.<p>In my experience, that's even worse than rewriting everything.<p>Also, it can become a requirement for hiring, because some manager, or their "top tech," have suddenly latched onto a technique/technology they encountered at a conference.<p>I remember applying at a company, and they gave me a "take-home" test.<p>Fair 'nuff. I like these better than the silly "draw spunky" tests that are so <i>en vogue</i>, these days.<p>They said I needed to use a certain third-party library, and use MVVM, or PM. That made no sense to me. It would result in the dependency being "married" to the application.<p>In my response, I used dependency injection to add the third-party library they wanted me to use. I wrote the app in about three hours, and incorporated the library (which is a great library, but one I had never used before). I delivered an app that met their specs -very quickly-, and of remarkably high quality. It also featured the ability to easily "swap out" the dependency (which is a huge reason for using dependency injection).<p>Dependency Injection is not a new thing. I think the name may be a bit new, but it's a fairly classic pattern that is a great way to encapsulate dependencies (which is something I always do).<p>It Freaked. Them. Out. I have no idea why. They literally shredded my résumé, at that point.<p>I have my suspicions why. I think they found out something else about me during the process (my age), and that may have been a contributing factor.
Let me make the argument against axios.<p>Even if you are happy, your users may not. Axios (btw still on version 0.x despite being one of the older javascript packages, means it can introduce breaking changes without any warning, think about that) adds 4.4kB (minified+gzipped) to your bundle. Do that a few times and you have hundreds of kB of additional code your users don't need to download (and execute!). If all you need to GET or POST, without any special needs, the w3c fetch function is definitely better for your users.
No one I know has moved away from React as the base of their front-end UI for the last three years.<p>Maybe I'm out of touch? It doesn't seem like the churn is as much of an issue.
The underlying problems are mainly psychological in my opinion. FOMO (fear of missing out) and attaching your identity to a language or tech stack.<p>People get so religiously tied to their technology sometimes that they cannot change without changing themselves.<p>It's the same case with the fractured ecosystem of Linux distros, there's tonnes of them! From the outside it looks overwhelming as all these projects are concurrently developing similar things. But the benefits are a rich and diverse ecosystem meeting a range of needs.<p>Imagine if everyone used one language like Java and never created new packages... and simply maintained existing libraries... that's not a world I'd like developing in...
I agree totally with this - but if you want to get a new job, you have no choice but to follow the latest javascript framework, because thats who's hiring. They want to build their new doodad in the latest doodad - react, Vue, ...., because thats what their google turned up thats the latest and greatest.<p>Further if you're looking at getting your next job, you'll make your next project using the latest doodad, because thats who's hiring when you finish this project (as long as your project doesn't take to long and you miss the boat - you can probably quit midway, I suppose)
Javascript has always gone through hype cycles.<p>Interestingly, it appears to be somewhat correlated with market manias and peaks near the tops of markets.<p>Generally, following industry trends appears to be good for individual careers but bad for code bases (on average, but with occasional big payoffs.)
Agreed entirely. Now all you have to do is convince my team of this without being bombarded with the platitude of "don't reinvent the wheel."
Have followed the trends and I now know Ember, Angular(both legacy and new), Vue(with and without typescript), and React(both classes and hooks). I've also used Svelte, and Stencil JS in my personal projects. In addition, I've also dived headfirst into GraphQL and Typescript pretty heavily lately.<p>Do I regret investing time in learning any of those frameworks or technologies?<p>Not at all. It was fun and interesting at the time I learned something different from each of them. Perhaps the most valuable thing I learned was that it is worthwhile to evaluate new technologies and to continue learning new things.<p>Does it devalue me as an Engineer to learn many things as opposed to becoming an expert in a single tech stack?<p>Much the opposite. A lot of the underlying principles and architecture remain the same and yet, I find each framework offers something new. Whether it's questioning some convention, or approaching a problem with a different paradigm, or just being heavily opinionated, I feel like I gained some value from each of these and had fun while doing so.
One problem I have with that hype cycle diagram is that it appears to show that all technologies that get a lot of hype will eventually even out and get good adoption once they go through some growing pains.<p>Realistically though a lot of new tech will get into the hype stage and then everyone will realise that is in fact no good or just disappear for some other reason.<p>People see that diagram and think it doesn't matter if you jump in at the hype stage because <i>eventually</i> this tech will become mainstream, when a lot of the time that graph just drops to zero after the hype stage.
Agreed. I approach it more from a "Draw a line in the sand" perspective.<p>We start a project, pick our stack, pick framework versions and features to use. And then we code for a year using those decisions. We do watch to see what new things come up over the course of a year. We also learn lessons from our choices. When our year is over, we talk about new things, evaluate them, decide what we want to adopt, and move the line in the sand to include the changes that make sense. Then... for another year, stay where we are.
One thing that is, unfortunately, a bit neglected in the post: dependencies deprecate and JS has a lot of them.<p>One npm audit shows a lot of vulnerabilities for the long trail of dependencies in my Angular 4 app. My web app uses Hapi 17 and many plugins have changed APIs in the more recent version.<p>This fact alone leads to many heavy refactorings and even rewrites.<p>As a solo dev, I can only try to reduce dependencies (taking a massive hit on productivity) or keep up with the newest way to write stuff in my former self’s framework of choice.
This lustrates a problem I've encountered on a few recent projects - we are suffering an embarrassment of riches when it comes to front end technology.<p>I found myself slipping in the architect role on a few recent projects with various employers and being forced to make the call on which front end framework to use. The problem is that there are so many to choose from and it very hard to predict what you will need in terms of features from your chosen framework six months or longer after making your decision.<p>Plus, your fellow devs will probably be arguing with you over which one is better based on their experience. All the emails and messages pointing me to various websites claiming React/Vue/Angular etc is best with stats and graphs I really don't have to the time to get my head around.<p>It's that fear of making the wrong choice that bothers me. The idea a year down the line the front end seems a bit sluggish and someone then points out that {other_framework} would be flying with the same workload.<p>Don't get me wrong choice is good, but with so much going on in the world of front-end right now coupled with all the hype and shouts about which is best it is hard to just pick one and run with it. Especially in the metric driven world we live in where a manager who doesn't get tech will berate you for choosing the wrong framework or wonder why you aren't buying in the latest hyped up framework.<p>That being said my preference is to use a framework to prototype and then convert to plain old JS where possible.
I think Software Engineers' role is to pick the right tool for the job - taking into account all the advantages and drawbacks of each one. Following the trends is a good way of knowing if any of the drawbacks of the previous tools were alleviated in the new ones. Of course the refactoring time must also be a deciding factor in a switch - most of the times it won't be worth it. I think what the author meant was don't follow the JS treds <i>blindly</i>.
Let's reverse the question: if you didn't follow the trends, were a decision maker, and wanted to bet on a frontend "framework" for the next 10+ years for a greenfield (or full rewrite) project. What would you chose in 2020 ?<p>From where I stand, it seems vue or react aren't going away anytime soon. But the same could be said of angular, ember, and probably many others. What would you chose and why ?
The problem to me isn't so much hype trains for this or that framework but that, as a Front-Ender myself, many Front-End Devs don't know how to do anything without a framework; the person I report to, the Front-End Manager, had been mucking about with jQuery for 15 years straight and didn't know about CSS animations.<p>I was able to work alongside a very saavy consultant for a year when I started out who I feel pointed me in the right direction wrt coding 'from the problem itself', if you will, but they'd have me do interviews and I'd be astounded at what applicants didn't know or grasp who'd been doin this front-end thing much longer than I.<p>If there were better solution design pedagogy instead of React's original marketing of "We know better about efficient DOM updates than you" I think you'd see substantially less reliance on these types of things, and probably a lot less unmaintainable code disguised as maintainable because it uses "a framework".
I'm teaching frontend development to designers right now and after almost a semester, I have the feeling I have to cut out much more concepts.<p>There are just too many ways to do things to teach a beginner in one semester and they just should be able to create basic prototypes anyway.
I think either vanilla js, or the other route, a full blown batteries included, like Visual Basic 6 was for windows development. Either abstract away nothing, or everything.<p>In the middle, is developing with a framework. The problem is you have to know the language + the peculiarities of the framework. New frameworks and "features" happen on too short a timeframe. And, frankly, it costs too little to just invent a new framework. So, 10000 frameworks.<p>There is a mental cost that increases exponentially with every layer of abstraction. When people have to post questions about why they can't understand such "features" of panacea x , that's the problem.
I just wish more developers would stop trying to improve their products by chasing the newest, coolest standard, and instead work on fixing bugs. But that's not en vogue these days.
I don't use frameworks, and have found more efficient, better organized, more native ways of doing everything that frameworks do.<p>It took a lot of time and effort and being a stick in the mud, but the trick was ultimately an algorithm/abstraction I call source derivation (SDx).<p>Here's a simple example of the algorithm: <a href="https://codepen.io/SephReed/pen/gOaeQLv" rel="nofollow">https://codepen.io/SephReed/pen/gOaeQLv</a>
Unfortunately we work with others and sometimes powerless in this. I worked in 2 front-end teams both using redux inherited from the early stage of the projects. In both cases the marority of the team don't like it but we're too deep in it to get out without affecting our roadmap. Another case I had to talk a college into not using graphql just because he could, felt like a jerk.
this is a fight a developer alone cannot win. my first job after college was in a company that created a software to manage industrial production. they were on their third refactor of their frontend. first was polymer?, then angular and now they were trying vue. I spent a lot of time and energy trying to convince them to write they own framework, if they like frameworks so bad. funny story, that's how I built FOS, the framework I use on my website. anyway, I was hired by some other company and don't know the end of the story there, but I'll bet they went with vue, just to rewrite the whole thing in react in a couple of months
I recently started a new app using Material UI, after doing web dev since pre-CSS days. I'm trying to grok CSS-in-JS, and it's only been a few weeks but it still feels so completely unneccessary.
tl;dr: use TypeScript, but don't worry so much about hooks.<p>---<p>I recently switched my JS + PureComponent mobile app to TypeScript and FC Hooks. I felt motivated to do so because:<p>- You cannot use hooks in PureComponent render(). The two modalities do not play nice together.<p>- Many of the libraries I use like react-spring and react-navigation have fully embraced hooks, sometimes without an HOC equivalent. So I felt forced to also embrace hooks or write complicated wrappers to facilitate them, for example new component lifecycle methods (e.g. componentDidFocus).<p>Some things I noticed...<p>1. TypeScript is amazing. Combined with Intellisense it has given me coding superpowers. I can write code faster and with dramatically more confidence.<p>2. You can incrementally shift your JS app to use TypeScript. You can even write type declarations for your JS code without rewriting it in TS. Most of your favorite libraries already have such type definitions (see DefinitelyTyped).<p>3. Hooks require a significantly different mental model than PureComponent. It feels horribly wasteful at first but apparently relies heavily on JS interpreter optimizations and memoization to achieve superior FMP performance[1]. My app feels noticeably snappier now, but it took a good bit of tuning to correct issues introduced during the port.<p>4. It IS indeed possible to write a functional wrapper that provides otherwise unavailable hook support for your Component or PureComponent. The tricky part is that you need to use a ref to invoke lifecycle methods on your wrapped component[2].<p>In retrospect I think I would recommend <i>against</i> porting an existing React project to hooks. However I would absolutely recommend porting to TypeScript, even if you do so slowly and incrementally.<p>1. <a href="https://medium.com/@dan_abramov/this-benchmark-is-indeed-flawed-c3d6b5b6f97f" rel="nofollow">https://medium.com/@dan_abramov/this-benchmark-is-indeed-fla...</a><p>2. <a href="https://medium.com/reactnative/custom-lifecycle-methods-in-react-native-f84c7257eaa6" rel="nofollow">https://medium.com/reactnative/custom-lifecycle-methods-in-r...</a>
Didn't read. Follow JavaScript trends that make sense for you and your team. Ignore the noise, get shit done.<p>You know what I hate more than "JS fatigue" - it's ppl complaining about "JS fatigue". Software evolves, and I'm always looking to bring a better experience for my users - and then means replacing components sometimes when there are clearly better alternatives, whether that is for developer experience, smaller bundle sizes, etc.
A while back, I got tired of dealing with the mess of Gatsby, Next.js, and Vuepress, so I made my own static site generator in Python.<p>I don't want a GraphQL database for my static site. I just want something to template out my site's boilerplate, and I don't want to deal with Webpack speed, or lack thereof. One file, ~200 loc, and I understand all of it.<p>The tentatively named Zhi works fast enough for full rebuilds triggered by fswatch. It does one thing and does it well:<p><pre><code> fswatch -0 -e .venv -e out . | xargs -0 zhi build
</code></pre>
If there's interest in a simple, understandable Jinja-based static site generator, I can clean it up and release it: <a href="https://github.com/0az/zhi" rel="nofollow">https://github.com/0az/zhi</a> (empty repo).