22 ms·

Do Not Follow JavaScript Trends

245 points by nikolalsvk 6y ago

chadcmulligan 6y ago
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. 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)
tsdlts 6y ago
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."
mxschumacher 6y ago
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. 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? If we think about users first, maybe we can feel a bit less guilty of not having deployed React Hooks to prod yet?
- chooseaname 6y ago
  > I wonder how much of that "innovation" really makes a difference to users. It makes a huge difference in terms of usability. Some sites are just plain awful to experience now. Not to mention battery hogs on mobile.
  - mxschumacher 6y ago
    in the negative, I agree. I see all the hype around React but when I use Facebook.com I am thoroughly underwhelmed.
    - phailhaus 6y ago
      Eh? You can't "tell" what framework a site is using just by interacting with the site. What you see is what the designers decided. A better proxy, though weak, would be the number of UI bugs you encounter. The best metric would require you to have insider knowledge, to see how much work is saved by reusing components and writing them declaratively.
      - RL_Quine 6y ago
        You can usually tell react based things from the poor performance and bad handling of network conditions.
        valand 6y ago
        Nah, this is just because tutorials for these new frameworks does not include network handling. It's far more easier to put todo list app or counter app to your blogs. Really, we need people to come together to build a proper knowledge base rather than fighting for influence with hype and easy blog posts
      - traverseda 6y ago
        Might just be a firefox thing, or a symptom of my ad-blocker, but facebook and the reddit redesign are both pretty terrible performance wise. The thingiverse redesign seems performant though so I don't know.
      - noisem4ker 6y ago
        When a website loads displaying a spinner or a splash screen, you know it was made with some heavy framework, it's going to be slow, it's going to break a number of estabilished web UX paradigms (such as scrolling, history or the ability to open links in new tabs) and your phone will feel warm in your hand. You just know.
- phailhaus 6y ago
  > What is possible today that was very hard to do 10 years ago in web dev land? Declaratively writing components and reusing behavior (e.g., hooks) across components/applications was basically impossible with the tools of 10 years ago. The benefit to the user is more stable interfaces and a faster release rate.
  - dahfizz 6y ago
    > benefit to the user is more stable interfaces Doubt. Websites are constantly redesigning their interfaces so that they can use the latest trendy technology.
    - arvinsim 6y ago
      Why blame developers? Why not the designers or product managers?
    - phailhaus 6y ago
      Is that the fault of the frameworks for existing? That's like saying we'd be better off if we didn't have so many programming languages.
    - deleted 6y ago
      [deleted]
  - tobyhinloopen 6y ago
    I totally disagree. Reusable components were already there using jquery plugins. Everyone used them and they were easy to use and easy to install. They were deployed as a single file, with optional CSS. Try writing a reusable component now. You have to target all major frameworks and tooling.
    - Grimm1 6y ago
      I think you may be conflating components and good old fashioned libraries. You can certainly make a component into a library but that's not their main use case. Their main use-case is for organization and reusability within a singular codebase. I write reusable components all the time inside my codebases. I never have to target anything except the stack I'm using for my project.
- duxup 6y ago
  Flexbox certainly allows me to accomplish things faster / in ways I couldn't (or wasn't going to hack together with tables) before. Is that for the user, I don't think they care, but they do get changes faster / more features because I'm not pulling my hair out over tables....
- d0m 6y ago
  Analogy: Like looking at stock prices. As javascript developers, we see all the tiny changes every day and it can feel overwhelming. However, looking at with a long-term view, there are only a few major spikes and it seems to be nicely growing.
- onion2k 6y ago
  I want to break this list of things down a bit; CSS Grid / Flexbox - Flexbox was defined in 2009, and was added to browsers about 10 years ago and iterated since. It was literally in the first public version of Chrome. This is not some new tech that's blindsided everyone. Grid is a couple of years old. React - First released 7 years ago and iterated since. Reasonably mainstream for 5 years. That's not a very dramatic change. WASM - Around for a few years now in browsers but tooling for different languages is still patchy. Entirely unnecessary for 99.9% of web development. Most people are still in the "use it because it's cool" phase rather than "use it because it's actually useful". extensions to the web API - Various, obviously. Can't really argue this point. lots of new JS features - Various, but not actually very fast moving with new features. Most things are made available earlier through transpilers, so you can use a feature without it being in mainstream JS engines if you want to. Can't really blame the web if you make that choice though. countless frameworks - You don't need to learn them all. Pick any number to use between zero and all of them depending on how much time you want to spend learning frameworks. Again, this is a choice, and if you're finding it overwhelming it's because you picked the wrong number of frameworks to learn. plugins and build tools - Same answer again. Pick something and learn it. Update your skills every few years if you think your tooling is holding you back. more homogeneity between browsers - This reduces complexity. To complain about that in a list of things to taking up your time is weird. The web isn't that fast moving. I completely agree with your point about focusing on things that benefit the user though. I would argue that frameworks and build tools that enable me to iterate features faster do that though.
  - Elinvynia 6y ago
    There is always some lag when it comes to being safe to use certain features, while it's true that flexbox is quite old, consider that at the time it was released many people still had to support browsers like IE6/7.
    - onion2k 6y ago
      There was also a problem that the spec changed so at one point you had to support two versions, which put a lot of people off adopting it for a long time. The point is still that this stuff isn't new though. Browsers don't change very quickly, especially for the fundamental building blocks of how you get a website on a screen.
- Ataraxy 6y ago
  I would also argue in direct contrast to the author that it makes a difference in terms of keeping interest. The new thing to learn in a dynamic ever changing landscape is also a way of staving off monotony. I legitimately don't care about React hooks though one way or another and it's a bizarre thing to draw a line at.
mxschumacher 6y ago
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: "You don't know JS": https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS "How browsers work": https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ https://www.html5rocks.com/en/tutorials/internals/howbrowser... "High performance browser networking": https://hpbn.co/ https://hpbn.co/
- recursivedoubts 6y ago
  Agreed. I think a lot of folks suffer from not understanding how web 1.0 worked and really groking REST/HATEOAS (which has since been hijacked for JSON APIs, which is complete nonsense.) Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if I'm really joking.
  - no_wizard 6y ago
    There is the the HATEOAS compatible JSON-LD standard being worked on at the W3C https://json-ld.org/ https://json-ld.org/
    - recursivedoubts 6y ago
      Yeah, but it doesn't make up for the decade+ now that plain JSON (perhaps with the occasional URL, which still has to be interpreted correctly by client code!) has been called "REST-ful". On top of that, JSON-LD is still mainly focused on networked object graph serialization. Unfortunately it manages to be a complex specification without providing the functionality that HTML came with out of the gates as a hypertext in an obvious manner. HTML is a good-enough-to-great hypertext, we should probably stick with it.
  - thanatropism 6y ago
    In 1996-1998 as a teen I "made some websites" for local businesses. The one I made for my parents even had a search function (in PHP) in a CSV with their products (which were like 100). The CSV was generated by taking whatever Lotus Approach (their desktop DB) generated and transforming it with some custom Haskell code (I was a teen, what did I know). They clicked an icon to pull the data and another to run a FTP batch file. Fast forward, I understand nothing of the website being developed in React for my startup. The othe technical cofounder does grok it, but I could not lend a hand and can barely even supervise the outside help we brought. I like to think of myself as well-versed in a generalist manner. I can hack a custom sparse matrix (with a very particular structure I was able to prove an iteration for) inversion algorithm, but I understand nothing about painting the background the correct shade of blue!
recursivedoubts 6y ago
Javascript has always gone through hype cycles. Interestingly, it appears to be somewhat correlated with market manias and peaks near the tops of markets. Generally, following industry trends appears to be good for individual careers but bad for code bases (on average, but with occasional big payoffs.)
- User23 6y ago
  Since I own my career but signed away all rights to the code I write as a condition of employment I'm OK with this trade-off.
duxup 6y ago
I'm a little lost on the examples. 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... 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). If you want to use fetch, that also is hardly an ordeal to do / should not be a big cognitive load for anyone. 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. 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.
- runawaybottle 6y ago
  But do we get it? If we get it, why is frontend churn so prevalent? I don’t think we get it.
  - duxup 6y ago
    Get what?
    - runawaybottle 6y ago
      Resume driven development bad.
  - christophilus 6y ago
    Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn? [Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years of my career, I had to learn ASP, then ASP.NET, and in the Windows app world, we went from WinForms to XAML, then .NET Core came out, and things shifted again... See Rails' history for more examples of churn. It's not like every other platform is a paragon of stability. Clojure is a bulwark of stability compared to just about anything else, but it's hardly fair to hold the front-end community up against that gold standard...]
k__ 6y ago
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. 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.
- itronitron 6y ago
  Serious question, why do they need to know anything about creating prototypes?
  - k__ 6y ago
    The argumentation went like: We did design projects for companies and showed them our ideas as mock images and they didn't like them. We then implemented the exact same designs as prototypical apps, they clicked around in it and loved it.
    - itronitron 6y ago
      Oh, that makes sense. I thought you meant Javascript object prototypes!
    - robjan 6y ago
      You can mock user interactions in Sketch and Figma.
      - k__ 6y ago
        I don't use these apps. It were design teachers that hired me, so I guess they knew and still wanted their students to learn a bit programming.
Tade0 6y ago
I feel like these problems are endemic to React and the surrounding ecosystem. 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. 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. Meanwhile in React every year there's this new convention that isn't explicitly mandatory, but for some reason "cooler" than the previous one. All this won't matter once the next gen compiler-frameworks reach maturity. My take is that hooks are React's swan song.
- alharith 6y ago
  React is 8 years old. It's went through 3 major shifts: From react.CreateClass({}) style, to Class-based components, to now Hooks. In between, it's always embraced and tried to allow the community to adopt a more functional way of programming (Honestly, my personal take is embracing the classical-OO style is what made a lot of this "churny" feeling). But honestly, that's not really that much in 8 years. I think what we are observing is the sheer popularity of React, and how much content is out there, that it feels like every week someone is picking up from some point in the timeline, and it all gets resurfaced and refreshed in people's minds. But those of us who have been here from the beginning would probably say all the improvements have been positive. Really what has changed rapidly, especially in the past 2-3 years, is the underlying web technologies. I am finding that hard to keep up with.
- thanatropism 6y ago
  As an outsider, I feel like React both does too much (a virtual DOM? Aren't current web standards enough to make a flower shop website?) and too little -- there's all these terms/technologies/subframeworks that people are using like "create-react-app" and "Redux" and so on. It's neither an overarching architecture that makes normal web technology obsolete but runs on it, like Windows 95, nor a website generator like Wordpress. Web tech confuses me thoroughly, and I read HN all day.
  - quxbar 6y ago
lmilcin 6y ago
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. 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? 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. 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.
- lmilcin 6y ago
  I forgot to mention there is actually one reason to learn new frameworks and it is to educate yourself on the tools that are available. If you do it correctly you can get 90% benefits with 10% effort. Just don't decide to build your new production application with a framework that you don't know or did little more than hello world.
0az 6y ago
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. 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. The tentatively named Zhi works fast enough for full rebuilds triggered by fswatch. It does one thing and does it well: fswatch -0 -e .venv -e out . | xargs -0 zhi build If there's interest in a simple, understandable Jinja-based static site generator, I can clean it up and release it: https://github.com/0az/zhi https://github.com/0az/zhi (empty repo).
- BossingAround 6y ago
  If you didn't like Gatsby, why not simply use one of the tens of simpler static generators? Hugo is extremely popular, but also just Jekyll or something similar. You won't understand the whole codebase, most likely, but on a user level, it's literally just a "put a markdown file in this directory" type of a thing for most of these generators...
wereHamster 6y ago
Let me make the argument against axios. 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.
- adventured 6y ago
  > 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!) A few times? You're suggesting doing that 50 or 100 times. Adding 4.4kb an actual few times is meaningless for the end user.
  - wereHamster 6y ago
    axios is actually not that bad, in terms of size. There are definitely worse dependencies you can have. However to me the fact that someone decided to use axios in the frontend makes me cautious about everything else. Are they perhaps also using lodash (70kB) for just that one function? Or are they using ramda and lodash at the same time (or any other two packages that contain duplicate functionality)? Don't get me wrong, there are valid reasons to use axios, and I don't have a problem if you communicate those clearly. But I believe few developers make a conscious decision about the tradeoffs, most developers simply dgaf.
- heipei 6y ago
  My argument for using axios is developer ergonomics. There are a few libraries that I use both in the frontend and the backend, for which I gladly accept the increased bundle size: axios, lodash, moment, Q. My users get the benefit in me being able to ship features faster because I don't have to constantly keep up with which feature ships in which browser version etc. I also found the fetch API horrendous to use. It's a tradeoff I'm willing to make.
codingdave 6y ago
Agreed. I approach it more from a "Draw a line in the sand" perspective. 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.
jchook 6y ago
tl;dr: use TypeScript, but don't worry so much about hooks. --- I recently switched my JS + PureComponent mobile app to TypeScript and FC Hooks. I felt motivated to do so because: - You cannot use hooks in PureComponent render(). The two modalities do not play nice together. - 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). Some things I noticed... 1. TypeScript is amazing. Combined with Intellisense it has given me coding superpowers. I can write code faster and with dramatically more confidence. 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). 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. 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]. In retrospect I think I would recommend against porting an existing React project to hooks. However I would absolutely recommend porting to TypeScript, even if you do so slowly and incrementally. 1. https://medium.com/@dan_abramov/this-benchmark-is-indeed-flawed-c3d6b5b6f97f https://medium.com/@dan_abramov/this-benchmark-is-indeed-fla... 2. https://medium.com/reactnative/custom-lifecycle-methods-in-react-native-f84c7257eaa6 https://medium.com/reactnative/custom-lifecycle-methods-in-r...
- BossingAround 6y ago
  I was initially kind of worried about TS. It has kind of a high barrier to entry with linter settings, typescript-specific setting, solving how to compile your code easily, learning the new syntax, etc. etc. I literally spent like an hour reading up on it and learning it, and I realized I never want to go back to a plain old JS. TS feels way closer to Java than to JavaScript, with its own quirks and way of functioning of course. The barrier of entry seems perceived, but not really that big of a deal. I wonder what are the cons of TS.
ctvo 6y ago
No one I know has moved away from React as the base of their front-end UI for the last three years. Maybe I'm out of touch? It doesn't seem like the churn is as much of an issue.
ChrisMarshallNY 6y ago
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. We can have problems when folks start suddenly painting "The New Thing™" over classic designs and architectures. In my experience, that's even worse than rewriting everything. 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. I remember applying at a company, and they gave me a "take-home" test. Fair 'nuff. I like these better than the silly "draw spunky" tests that are so en vogue, these days. 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. 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). 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). It Freaked. Them. Out. I have no idea why. They literally shredded my résumé, at that point. 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.
- memexy 6y ago
  I once worked with a group of people that were afraid of makefiles. I doubt it was your age. People are always afraid of things that are unfamiliar. This applies to snakes and spiders just as much as it applies to programming languages and associated technologies.
  - ChrisMarshallNY 6y ago
    > I doubt it was your age. Wish I could share your confidence, but I have run face-first into this phenomenon. [...removed some stuff that I don't feel like backing up...] We are an unpopular bunch. It used to get me quite upset, but I’ve learned to make it quite clear that I am no youngster; right up front. Avoids stuff like what I mentioned.
gitgud 6y ago
The underlying problems are mainly psychological in my opinion. FOMO (fear of missing out) and attaching your identity to a language or tech stack. People get so religiously tied to their technology sometimes that they cannot change without changing themselves. 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. 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...
darepublic 6y ago
I remember 2016 as the year my peers started telling me that jquery was evil. Also a year of switching from angular to React/redux
nsonha 6y ago
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.
memexy 6y ago
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. 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: https://www.infoworld.com/article/3440104/10-software-development-cults-to-join.html https://www.infoworld.com/article/3440104/10-software-develo....
- ChrisMarshallNY 6y ago
  That is a great article! Thanks! BTW: I did write a bit about this phenomenon, here: https://medium.com/chrismarshallny/concrete-galoshes-a5798a55af2a https://medium.com/chrismarshallny/concrete-galoshes-a5798a5... (Scroll down to "It's Not An Either/Or Choice")
nsonha 6y ago
What do these have to do with managing fads?
joshribakoff 6y ago
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”. https://github.com/reduxjs/redux/pull/3708 https://github.com/reduxjs/redux/pull/3708 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. 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. 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.
- omniscient_oce 6y ago
  react-testing-library and Tailwind are two tools that I use that I feel the userbase are a bit cult-like. I don't know if it's "not invented here" syndrome so much as people use tools based on people, not always just merit. Kent and Adam had similar self-promotion engines running with long-form free video tutorials and strong social media presence, blog posts online, etc. Perhaps this style of promotion more of a tool more than anything is effective at changing the status-quo tools? (Not saying they're necessarily better or worse, just my observation of why they may have become popular)
  - joshribakoff 6y ago
    Yeah a blog post titled “never do X” is going to get more clicks than “consider the trade offs before doing X” unfortunately. This leads to people following “thought leaders” and trends, instead of thinking for themselves imo
mattwad 6y ago
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.
furstenheim 6y ago
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. 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. 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.
- kqr 6y ago
  > 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. It's never the case that you "don't use a framework" for something like that. You'll use a framework, alright. The choice is between using something well-built based on best practises as we know them, or... building it yourself. Other than in very rare circumstances, I fail to see the point of reinventing that wheel. UI frameworks (web front-end or not) are a quagmire of edge cases and other infinite time sinks.
erwinh 6y ago
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 :)
- yen223 6y ago
  In my opinion, React is one of the few libraries out there where the gains from using it is much larger than the effort needed to learn it. It has a relatively small API, more so now that you can get a lot done with just function components. In return, once you grok the whole "components as a function of state" concept, designing data models and designing app components becomes very simple. I really like react, and I'm glad to see other environments adopting a React-like approach to UI development (Apple's SwiftUI and Android's Jetpack Compose, to name two)
andrewl-hn 6y ago
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. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. 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. 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. The whole "JavaScript fatigue" meme has to go.
- strangescript 6y ago
  100%. Normally these articles are thinly veiled attacks on something that has changed in the author's coding ecosystem that has angered them. When I saw hooks in the first few paragraphs I assumed it was going to be a "hooks are bad, mkay" article. It isn't, but still some what vague on actionable points or ideas. Ultimately no one likes rewriting code and is typically under-estimated since developers mentally trivialize previous work rather than a greenfield affair.
- Softcadbury 6y ago
  I agree for frameworks, but building tools and package management are still nightmares for me
- draw_down 6y ago
  Blessed sanity. Great post, thank you.
- dlbucci 6y ago
  I have to chime in as someone who created an Angular.js app in 2017. I suppose it happens. Not that I actually wanted to, I was just working with a dumbass who overruled me. I don't really have anything it say, I just have a really strong negative association with this specific topic, I guess...
diffrinse 6y ago
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. 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. 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".
dpweb 6y ago
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. 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. 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.
- worik 6y ago
  Been a while for me, but I agree But when I spent a year doing Javascript I found that in JQuery there were a lot of shortcuts I was writing my self to lower the RSI from typing long Javascript statements. Beyond that there is nothing useful in JS frame works. They make simple things easy and the complicated stuff (which is design and logic) stays hard.
underbluewaters 6y ago
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.
- koheripbal 6y ago
  And a key component of that is evaluating not learning the new framework. It's a meta analysis on the new tech that can be done in less than a day, rather than spending weeks mastering it just to determine if it fits in your tech stack. Focus is everything. The universe is too infinite to learn everything.
- mtts 6y ago
  > As a software developer I consider the most important part of my job to be evaluating new tools and techniques. Really? I would argue it’s building software. > This craft is in its infancy We’ve been building software since ... dunno ... 1950s? 1960s? > our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget This is probably true, but I suspect chasing new tools isn’t the solution. I’ve seen a lot of very much with it development teams fail at building stuff because they couldn’t get their shiny new stuff to work predictably. > If someone is "tired" of this process it might be time to consider another profession. On the front end, yes, it’s probably par for the course. I suspect it’s because front end development is even more removed from rigorous engineering practice than back end development. On the back end, however, lots of stuff is still built in Java and C(++) and it all works reasonably well. It’s just not very exciting.
Aissen 6y ago
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 ? 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 ?
jaquers 6y ago
Didn't read. Follow JavaScript trends that make sense for you and your team. Ignore the noise, get shit done. 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.
- worik 6y ago
  Depends if you want your code to be maintainable into the future with other teams. If you do not care about the future (which os OK in some contexts) then you are correct
mot0rola 6y ago
Stay curious, try new things! Party of being a developer is exploration and discovery. Do not discourage!
jaeming 6y ago
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. Do I regret investing time in learning any of those frameworks or technologies? 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. Does it devalue me as an Engineer to learn many things as opposed to becoming an expert in a single tech stack? 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.
- koheripbal 6y ago
  The downside probably being that an employer paid you during that time of learning and didn't get much work product out of it. Learning for the sake of learning is an infinite endeavour. I try to practice strategic learning - learning skills/frameworks/topics that will have a high likelihood of being used in the course of my current project. There's just so so much out there... focus is everything.
  - jaeming 6y ago
    I am actually paid by my employer to do 5 hours of training per week. It's required and I am allowed to study anything I want, whether it's a new framework or a self-improvement book. I usually spend that time studying something that I think may be useful or related to my job but I have been encouraged to explore. My employer is a big believer that innovation comes from exploration. As you pointed out, it is an infinite endeavor. I'm okay with that. If I just stuck with the current technologies that were used when I first came in, we'd probably still be using jQuery and .ERB templates. Instead I personally pushed for using new technologies and my team is personally responsible for introducing Vue, Typescript, and GraphQL to our stack among other technologies.
DoubleGlazing 6y ago
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. 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. 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. 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. 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. That being said my preference is to use a framework to prototype and then convert to plain old JS where possible.
dpix 6y ago
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. 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. People see that diagram and think it doesn't matter if you jump in at the hype stage because eventually this tech will become mainstream, when a lot of the time that graph just drops to zero after the hype stage.
atum47 6y ago
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
dilandau 6y ago
I remember having a coworker who was "learning clojure". That guy did more damage than could even be imagined.
seph-reed 6y ago
I don't use frameworks, and have found more efficient, better organized, more native ways of doing everything that frameworks do. 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). Here's a simple example of the algorithm: https://codepen.io/SephReed/pen/gOaeQLv https://codepen.io/SephReed/pen/gOaeQLv
awirth 6y ago
Some days I miss using prototype.js and script.aculo.us
sdfhbdf 6y ago
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 blindly.
thesuitonym 6y ago
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.
WA 6y ago
One thing that is, unfortunately, a bit neglected in the post: dependencies deprecate and JS has a lot of them. 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. This fact alone leads to many heavy refactorings and even rewrites. 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.
joeblow21 6y ago
Plain old javascript still works... right? Good
pldr1234 6y ago
Article very empty of any real, tangible advice.

245 points by nikolalsvk 6y ago

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

tsdlts 6y ago

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

mxschumacher 6y ago

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. 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? If we think about users first, maybe we can feel a bit less guilty of not having deployed React Hooks to prod yet?

chooseaname 6y ago
> I wonder how much of that "innovation" really makes a difference to users. It makes a huge difference in terms of usability. Some sites are just plain awful to experience now. Not to mention battery hogs on mobile.
- mxschumacher 6y ago
  in the negative, I agree. I see all the hype around React but when I use Facebook.com I am thoroughly underwhelmed.
  - phailhaus 6y ago
    Eh? You can't "tell" what framework a site is using just by interacting with the site. What you see is what the designers decided. A better proxy, though weak, would be the number of UI bugs you encounter. The best metric would require you to have insider knowledge, to see how much work is saved by reusing components and writing them declaratively.
    - RL_Quine 6y ago
      You can usually tell react based things from the poor performance and bad handling of network conditions.
      - valand 6y ago
        Nah, this is just because tutorials for these new frameworks does not include network handling. It's far more easier to put todo list app or counter app to your blogs. Really, we need people to come together to build a proper knowledge base rather than fighting for influence with hype and easy blog posts
    - traverseda 6y ago
      Might just be a firefox thing, or a symptom of my ad-blocker, but facebook and the reddit redesign are both pretty terrible performance wise. The thingiverse redesign seems performant though so I don't know.
    - noisem4ker 6y ago
      When a website loads displaying a spinner or a splash screen, you know it was made with some heavy framework, it's going to be slow, it's going to break a number of estabilished web UX paradigms (such as scrolling, history or the ability to open links in new tabs) and your phone will feel warm in your hand. You just know.
phailhaus 6y ago
> What is possible today that was very hard to do 10 years ago in web dev land? Declaratively writing components and reusing behavior (e.g., hooks) across components/applications was basically impossible with the tools of 10 years ago. The benefit to the user is more stable interfaces and a faster release rate.
- dahfizz 6y ago
  > benefit to the user is more stable interfaces Doubt. Websites are constantly redesigning their interfaces so that they can use the latest trendy technology.
  - arvinsim 6y ago
    Why blame developers? Why not the designers or product managers?
  - phailhaus 6y ago
    Is that the fault of the frameworks for existing? That's like saying we'd be better off if we didn't have so many programming languages.
  - deleted 6y ago
    [deleted]
- tobyhinloopen 6y ago
  I totally disagree. Reusable components were already there using jquery plugins. Everyone used them and they were easy to use and easy to install. They were deployed as a single file, with optional CSS. Try writing a reusable component now. You have to target all major frameworks and tooling.
  - Grimm1 6y ago
    I think you may be conflating components and good old fashioned libraries. You can certainly make a component into a library but that's not their main use case. Their main use-case is for organization and reusability within a singular codebase. I write reusable components all the time inside my codebases. I never have to target anything except the stack I'm using for my project.
duxup 6y ago
Flexbox certainly allows me to accomplish things faster / in ways I couldn't (or wasn't going to hack together with tables) before. Is that for the user, I don't think they care, but they do get changes faster / more features because I'm not pulling my hair out over tables....
d0m 6y ago
Analogy: Like looking at stock prices. As javascript developers, we see all the tiny changes every day and it can feel overwhelming. However, looking at with a long-term view, there are only a few major spikes and it seems to be nicely growing.
onion2k 6y ago
I want to break this list of things down a bit; CSS Grid / Flexbox - Flexbox was defined in 2009, and was added to browsers about 10 years ago and iterated since. It was literally in the first public version of Chrome. This is not some new tech that's blindsided everyone. Grid is a couple of years old. React - First released 7 years ago and iterated since. Reasonably mainstream for 5 years. That's not a very dramatic change. WASM - Around for a few years now in browsers but tooling for different languages is still patchy. Entirely unnecessary for 99.9% of web development. Most people are still in the "use it because it's cool" phase rather than "use it because it's actually useful". extensions to the web API - Various, obviously. Can't really argue this point. lots of new JS features - Various, but not actually very fast moving with new features. Most things are made available earlier through transpilers, so you can use a feature without it being in mainstream JS engines if you want to. Can't really blame the web if you make that choice though. countless frameworks - You don't need to learn them all. Pick any number to use between zero and all of them depending on how much time you want to spend learning frameworks. Again, this is a choice, and if you're finding it overwhelming it's because you picked the wrong number of frameworks to learn. plugins and build tools - Same answer again. Pick something and learn it. Update your skills every few years if you think your tooling is holding you back. more homogeneity between browsers - This reduces complexity. To complain about that in a list of things to taking up your time is weird. The web isn't that fast moving. I completely agree with your point about focusing on things that benefit the user though. I would argue that frameworks and build tools that enable me to iterate features faster do that though.
- Elinvynia 6y ago
  There is always some lag when it comes to being safe to use certain features, while it's true that flexbox is quite old, consider that at the time it was released many people still had to support browsers like IE6/7.
  - onion2k 6y ago
    There was also a problem that the spec changed so at one point you had to support two versions, which put a lot of people off adopting it for a long time. The point is still that this stuff isn't new though. Browsers don't change very quickly, especially for the fundamental building blocks of how you get a website on a screen.
Ataraxy 6y ago
I would also argue in direct contrast to the author that it makes a difference in terms of keeping interest. The new thing to learn in a dynamic ever changing landscape is also a way of staving off monotony. I legitimately don't care about React hooks though one way or another and it's a bizarre thing to draw a line at.

mxschumacher 6y ago

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: "You don't know JS": https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS "How browsers work": https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ https://www.html5rocks.com/en/tutorials/internals/howbrowser... "High performance browser networking": https://hpbn.co/ https://hpbn.co/

recursivedoubts 6y ago
Agreed. I think a lot of folks suffer from not understanding how web 1.0 worked and really groking REST/HATEOAS (which has since been hijacked for JSON APIs, which is complete nonsense.) Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if I'm really joking.
- no_wizard 6y ago
  There is the the HATEOAS compatible JSON-LD standard being worked on at the W3C https://json-ld.org/ https://json-ld.org/
  - recursivedoubts 6y ago
    Yeah, but it doesn't make up for the decade+ now that plain JSON (perhaps with the occasional URL, which still has to be interpreted correctly by client code!) has been called "REST-ful". On top of that, JSON-LD is still mainly focused on networked object graph serialization. Unfortunately it manages to be a complex specification without providing the functionality that HTML came with out of the gates as a hypertext in an obvious manner. HTML is a good-enough-to-great hypertext, we should probably stick with it.
- thanatropism 6y ago
  In 1996-1998 as a teen I "made some websites" for local businesses. The one I made for my parents even had a search function (in PHP) in a CSV with their products (which were like 100). The CSV was generated by taking whatever Lotus Approach (their desktop DB) generated and transforming it with some custom Haskell code (I was a teen, what did I know). They clicked an icon to pull the data and another to run a FTP batch file. Fast forward, I understand nothing of the website being developed in React for my startup. The othe technical cofounder does grok it, but I could not lend a hand and can barely even supervise the outside help we brought. I like to think of myself as well-versed in a generalist manner. I can hack a custom sparse matrix (with a very particular structure I was able to prove an iteration for) inversion algorithm, but I understand nothing about painting the background the correct shade of blue!

recursivedoubts 6y ago

Javascript has always gone through hype cycles. Interestingly, it appears to be somewhat correlated with market manias and peaks near the tops of markets. Generally, following industry trends appears to be good for individual careers but bad for code bases (on average, but with occasional big payoffs.)

User23 6y ago
Since I own my career but signed away all rights to the code I write as a condition of employment I'm OK with this trade-off.

duxup 6y ago

I'm a little lost on the examples. 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... 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). If you want to use fetch, that also is hardly an ordeal to do / should not be a big cognitive load for anyone. 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. 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.

runawaybottle 6y ago
But do we get it? If we get it, why is frontend churn so prevalent? I don’t think we get it.
- duxup 6y ago
  Get what?
  - runawaybottle 6y ago
    Resume driven development bad.
- christophilus 6y ago
  Is front end churn really so prevalent? I hear this opinion all the time, but React is 7 years old. I've been using it for around 5 years, I think. Redux is 5 years old. How old does the most popular web framework need to be before we consider it to be low churn? [Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn there was at least as bad, maybe worse in my personal experience. Over 15 years of my career, I had to learn ASP, then ASP.NET, and in the Windows app world, we went from WinForms to XAML, then .NET Core came out, and things shifted again... See Rails' history for more examples of churn. It's not like every other platform is a paragon of stability. Clojure is a bulwark of stability compared to just about anything else, but it's hardly fair to hold the front-end community up against that gold standard...]

k__ 6y ago

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

itronitron 6y ago
Serious question, why do they need to know anything about creating prototypes?
- k__ 6y ago
  The argumentation went like: We did design projects for companies and showed them our ideas as mock images and they didn't like them. We then implemented the exact same designs as prototypical apps, they clicked around in it and loved it.
  - itronitron 6y ago
    Oh, that makes sense. I thought you meant Javascript object prototypes!
  - robjan 6y ago
    You can mock user interactions in Sketch and Figma.
    - k__ 6y ago
      I don't use these apps. It were design teachers that hired me, so I guess they knew and still wanted their students to learn a bit programming.

Tade0 6y ago

I feel like these problems are endemic to React and the surrounding ecosystem. 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. 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. Meanwhile in React every year there's this new convention that isn't explicitly mandatory, but for some reason "cooler" than the previous one. All this won't matter once the next gen compiler-frameworks reach maturity. My take is that hooks are React's swan song.

alharith 6y ago
React is 8 years old. It's went through 3 major shifts: From react.CreateClass({}) style, to Class-based components, to now Hooks. In between, it's always embraced and tried to allow the community to adopt a more functional way of programming (Honestly, my personal take is embracing the classical-OO style is what made a lot of this "churny" feeling). But honestly, that's not really that much in 8 years. I think what we are observing is the sheer popularity of React, and how much content is out there, that it feels like every week someone is picking up from some point in the timeline, and it all gets resurfaced and refreshed in people's minds. But those of us who have been here from the beginning would probably say all the improvements have been positive. Really what has changed rapidly, especially in the past 2-3 years, is the underlying web technologies. I am finding that hard to keep up with.
thanatropism 6y ago
As an outsider, I feel like React both does too much (a virtual DOM? Aren't current web standards enough to make a flower shop website?) and too little -- there's all these terms/technologies/subframeworks that people are using like "create-react-app" and "Redux" and so on. It's neither an overarching architecture that makes normal web technology obsolete but runs on it, like Windows 95, nor a website generator like Wordpress. Web tech confuses me thoroughly, and I read HN all day.
- quxbar 6y ago

lmilcin 6y ago

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

lmilcin 6y ago
I forgot to mention there is actually one reason to learn new frameworks and it is to educate yourself on the tools that are available. If you do it correctly you can get 90% benefits with 10% effort. Just don't decide to build your new production application with a framework that you don't know or did little more than hello world.

0az 6y ago

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. 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. The tentatively named Zhi works fast enough for full rebuilds triggered by fswatch. It does one thing and does it well: fswatch -0 -e .venv -e out . | xargs -0 zhi build If there's interest in a simple, understandable Jinja-based static site generator, I can clean it up and release it: https://github.com/0az/zhi https://github.com/0az/zhi (empty repo).

BossingAround 6y ago
If you didn't like Gatsby, why not simply use one of the tens of simpler static generators? Hugo is extremely popular, but also just Jekyll or something similar. You won't understand the whole codebase, most likely, but on a user level, it's literally just a "put a markdown file in this directory" type of a thing for most of these generators...

wereHamster 6y ago

Let me make the argument against axios. 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.

adventured 6y ago
> 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!) A few times? You're suggesting doing that 50 or 100 times. Adding 4.4kb an actual few times is meaningless for the end user.
- wereHamster 6y ago
  axios is actually not that bad, in terms of size. There are definitely worse dependencies you can have. However to me the fact that someone decided to use axios in the frontend makes me cautious about everything else. Are they perhaps also using lodash (70kB) for just that one function? Or are they using ramda and lodash at the same time (or any other two packages that contain duplicate functionality)? Don't get me wrong, there are valid reasons to use axios, and I don't have a problem if you communicate those clearly. But I believe few developers make a conscious decision about the tradeoffs, most developers simply dgaf.
heipei 6y ago
My argument for using axios is developer ergonomics. There are a few libraries that I use both in the frontend and the backend, for which I gladly accept the increased bundle size: axios, lodash, moment, Q. My users get the benefit in me being able to ship features faster because I don't have to constantly keep up with which feature ships in which browser version etc. I also found the fetch API horrendous to use. It's a tradeoff I'm willing to make.

codingdave 6y ago

Agreed. I approach it more from a "Draw a line in the sand" perspective. 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.

jchook 6y ago

tl;dr: use TypeScript, but don't worry so much about hooks. --- I recently switched my JS + PureComponent mobile app to TypeScript and FC Hooks. I felt motivated to do so because: - You cannot use hooks in PureComponent render(). The two modalities do not play nice together. - 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). Some things I noticed... 1. TypeScript is amazing. Combined with Intellisense it has given me coding superpowers. I can write code faster and with dramatically more confidence. 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). 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. 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]. In retrospect I think I would recommend against porting an existing React project to hooks. However I would absolutely recommend porting to TypeScript, even if you do so slowly and incrementally. 1. https://medium.com/@dan_abramov/this-benchmark-is-indeed-flawed-c3d6b5b6f97f https://medium.com/@dan_abramov/this-benchmark-is-indeed-fla... 2. https://medium.com/reactnative/custom-lifecycle-methods-in-react-native-f84c7257eaa6 https://medium.com/reactnative/custom-lifecycle-methods-in-r...

BossingAround 6y ago
I was initially kind of worried about TS. It has kind of a high barrier to entry with linter settings, typescript-specific setting, solving how to compile your code easily, learning the new syntax, etc. etc. I literally spent like an hour reading up on it and learning it, and I realized I never want to go back to a plain old JS. TS feels way closer to Java than to JavaScript, with its own quirks and way of functioning of course. The barrier of entry seems perceived, but not really that big of a deal. I wonder what are the cons of TS.

ctvo 6y ago

No one I know has moved away from React as the base of their front-end UI for the last three years. Maybe I'm out of touch? It doesn't seem like the churn is as much of an issue.

ChrisMarshallNY 6y ago

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. We can have problems when folks start suddenly painting "The New Thing™" over classic designs and architectures. In my experience, that's even worse than rewriting everything. 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. I remember applying at a company, and they gave me a "take-home" test. Fair 'nuff. I like these better than the silly "draw spunky" tests that are so en vogue, these days. 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. 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). 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). It Freaked. Them. Out. I have no idea why. They literally shredded my résumé, at that point. 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.

memexy 6y ago
I once worked with a group of people that were afraid of makefiles. I doubt it was your age. People are always afraid of things that are unfamiliar. This applies to snakes and spiders just as much as it applies to programming languages and associated technologies.
- ChrisMarshallNY 6y ago
  > I doubt it was your age. Wish I could share your confidence, but I have run face-first into this phenomenon. [...removed some stuff that I don't feel like backing up...] We are an unpopular bunch. It used to get me quite upset, but I’ve learned to make it quite clear that I am no youngster; right up front. Avoids stuff like what I mentioned.

gitgud 6y ago

The underlying problems are mainly psychological in my opinion. FOMO (fear of missing out) and attaching your identity to a language or tech stack. People get so religiously tied to their technology sometimes that they cannot change without changing themselves. 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. 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...

darepublic 6y ago

I remember 2016 as the year my peers started telling me that jquery was evil. Also a year of switching from angular to React/redux

nsonha 6y ago

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.

memexy 6y ago

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. 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: https://www.infoworld.com/article/3440104/10-software-development-cults-to-join.html https://www.infoworld.com/article/3440104/10-software-develo....

ChrisMarshallNY 6y ago
That is a great article! Thanks! BTW: I did write a bit about this phenomenon, here: https://medium.com/chrismarshallny/concrete-galoshes-a5798a55af2a https://medium.com/chrismarshallny/concrete-galoshes-a5798a5... (Scroll down to "It's Not An Either/Or Choice")

nsonha 6y ago

What do these have to do with managing fads?

joshribakoff 6y ago

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”. https://github.com/reduxjs/redux/pull/3708 https://github.com/reduxjs/redux/pull/3708 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. 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. 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.

omniscient_oce 6y ago
react-testing-library and Tailwind are two tools that I use that I feel the userbase are a bit cult-like. I don't know if it's "not invented here" syndrome so much as people use tools based on people, not always just merit. Kent and Adam had similar self-promotion engines running with long-form free video tutorials and strong social media presence, blog posts online, etc. Perhaps this style of promotion more of a tool more than anything is effective at changing the status-quo tools? (Not saying they're necessarily better or worse, just my observation of why they may have become popular)
- joshribakoff 6y ago
  Yeah a blog post titled “never do X” is going to get more clicks than “consider the trade offs before doing X” unfortunately. This leads to people following “thought leaders” and trends, instead of thinking for themselves imo

mattwad 6y ago

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.

furstenheim 6y ago

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

kqr 6y ago
> 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. It's never the case that you "don't use a framework" for something like that. You'll use a framework, alright. The choice is between using something well-built based on best practises as we know them, or... building it yourself. Other than in very rare circumstances, I fail to see the point of reinventing that wheel. UI frameworks (web front-end or not) are a quagmire of edge cases and other infinite time sinks.

erwinh 6y ago

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 :)

yen223 6y ago
In my opinion, React is one of the few libraries out there where the gains from using it is much larger than the effort needed to learn it. It has a relatively small API, more so now that you can get a lot done with just function components. In return, once you grok the whole "components as a function of state" concept, designing data models and designing app components becomes very simple. I really like react, and I'm glad to see other environments adopting a React-like approach to UI development (Apple's SwiftUI and Android's Jetpack Compose, to name two)

andrewl-hn 6y ago

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. React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React "won" the framework battle. 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. 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. The whole "JavaScript fatigue" meme has to go.

strangescript 6y ago
100%. Normally these articles are thinly veiled attacks on something that has changed in the author's coding ecosystem that has angered them. When I saw hooks in the first few paragraphs I assumed it was going to be a "hooks are bad, mkay" article. It isn't, but still some what vague on actionable points or ideas. Ultimately no one likes rewriting code and is typically under-estimated since developers mentally trivialize previous work rather than a greenfield affair.
Softcadbury 6y ago
I agree for frameworks, but building tools and package management are still nightmares for me
draw_down 6y ago
Blessed sanity. Great post, thank you.
dlbucci 6y ago
I have to chime in as someone who created an Angular.js app in 2017. I suppose it happens. Not that I actually wanted to, I was just working with a dumbass who overruled me. I don't really have anything it say, I just have a really strong negative association with this specific topic, I guess...

diffrinse 6y ago

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

dpweb 6y ago

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

worik 6y ago
Been a while for me, but I agree But when I spent a year doing Javascript I found that in JQuery there were a lot of shortcuts I was writing my self to lower the RSI from typing long Javascript statements. Beyond that there is nothing useful in JS frame works. They make simple things easy and the complicated stuff (which is design and logic) stays hard.

underbluewaters 6y ago

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.

koheripbal 6y ago
And a key component of that is evaluating not learning the new framework. It's a meta analysis on the new tech that can be done in less than a day, rather than spending weeks mastering it just to determine if it fits in your tech stack. Focus is everything. The universe is too infinite to learn everything.
mtts 6y ago
> As a software developer I consider the most important part of my job to be evaluating new tools and techniques. Really? I would argue it’s building software. > This craft is in its infancy We’ve been building software since ... dunno ... 1950s? 1960s? > our profession borders on complete incompetence when it comes to predictably building usable tools at a reasonable budget This is probably true, but I suspect chasing new tools isn’t the solution. I’ve seen a lot of very much with it development teams fail at building stuff because they couldn’t get their shiny new stuff to work predictably. > If someone is "tired" of this process it might be time to consider another profession. On the front end, yes, it’s probably par for the course. I suspect it’s because front end development is even more removed from rigorous engineering practice than back end development. On the back end, however, lots of stuff is still built in Java and C(++) and it all works reasonably well. It’s just not very exciting.

Aissen 6y ago

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 ? 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 ?

jaquers 6y ago

Didn't read. Follow JavaScript trends that make sense for you and your team. Ignore the noise, get shit done. 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.

worik 6y ago
Depends if you want your code to be maintainable into the future with other teams. If you do not care about the future (which os OK in some contexts) then you are correct

mot0rola 6y ago

Stay curious, try new things! Party of being a developer is exploration and discovery. Do not discourage!

jaeming 6y ago

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. Do I regret investing time in learning any of those frameworks or technologies? 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. Does it devalue me as an Engineer to learn many things as opposed to becoming an expert in a single tech stack? 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.

koheripbal 6y ago
The downside probably being that an employer paid you during that time of learning and didn't get much work product out of it. Learning for the sake of learning is an infinite endeavour. I try to practice strategic learning - learning skills/frameworks/topics that will have a high likelihood of being used in the course of my current project. There's just so so much out there... focus is everything.
- jaeming 6y ago
  I am actually paid by my employer to do 5 hours of training per week. It's required and I am allowed to study anything I want, whether it's a new framework or a self-improvement book. I usually spend that time studying something that I think may be useful or related to my job but I have been encouraged to explore. My employer is a big believer that innovation comes from exploration. As you pointed out, it is an infinite endeavor. I'm okay with that. If I just stuck with the current technologies that were used when I first came in, we'd probably still be using jQuery and .ERB templates. Instead I personally pushed for using new technologies and my team is personally responsible for introducing Vue, Typescript, and GraphQL to our stack among other technologies.

DoubleGlazing 6y ago

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. 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. 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. 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. 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. That being said my preference is to use a framework to prototype and then convert to plain old JS where possible.

dpix 6y ago

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. 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. People see that diagram and think it doesn't matter if you jump in at the hype stage because eventually this tech will become mainstream, when a lot of the time that graph just drops to zero after the hype stage.

atum47 6y ago

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

dilandau 6y ago

I remember having a coworker who was "learning clojure". That guy did more damage than could even be imagined.

seph-reed 6y ago

I don't use frameworks, and have found more efficient, better organized, more native ways of doing everything that frameworks do. 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). Here's a simple example of the algorithm: https://codepen.io/SephReed/pen/gOaeQLv https://codepen.io/SephReed/pen/gOaeQLv

awirth 6y ago

Some days I miss using prototype.js and script.aculo.us

sdfhbdf 6y ago

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

thesuitonym 6y ago

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.

WA 6y ago

One thing that is, unfortunately, a bit neglected in the post: dependencies deprecate and JS has a lot of them. 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. This fact alone leads to many heavy refactorings and even rewrites. 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.

joeblow21 6y ago

Plain old javascript still works... right? Good

pldr1234 6y ago

Article very empty of any real, tangible advice.