Live data from Hacker News

Do Not Follow JavaScript Trends

pragmaticpineapple.com

191–200 of 275 posts

Re: Do Not Follow JavaScript Trends

#191

Earlier quoted context omitted.

No, people are realizing that they were just using redux as a caching layer and the boilerplate associated with it wasn't worth it when there are better approaches to caching local data now.

I disagree. Redux has a lot of icky boilerplate, but the Flux pattern, and variations of it, are useful. You're either using Redux, something like Redux (context hooks, possibly), or you are passing single variables through 3 or more layers of spaghetti.

There's truth to both these statements.

If the only thing you're doing with Redux is just fetching and caching data, and nothing further, there are other tools that are likely going to be more ergonomic for that (Apollo, react-query, SWR).

However, if you're actually _manipulating_ that data after it's been fetched, or working with more complex client-side state, the Flux architecture really becomes useful. As the Redux docs FAQ entry on "When should I use Redux?" says [0]:

> In general, use Redux when you have reasonable amounts of data changing over time, you need a single source of truth, and you find that approaches like keeping everything in a top-level React component's state are no longer sufficient.

(We also have additional guidance on when it makes sense to put any given piece of state into Redux [1], and I'm adding more guidance on this sort of topic as I work on rewriting our docs.)

Beyond that, our new Redux Toolkit package [2] has been specifically designed to eliminate most or all of that "boilerplate" concern, and provides a set of utilities that simplify most common Redux use cases. We now recommend it as the default approach for writing Redux logic, and I'm currently working on a new "Quick Start" docs section [3] that will teach it as the right way to use Redux for beginners (alongside the existing tutorial sequence that teaches how Redux works from the ground up).

Related to this, while I've been very reluctant to try to build any type of official Redux-based query/caching solution, we _did_ recently release a new `createAsyncThunk` API [4] that simplifies the process of dispatching actions while fetching and a `createEntityAdapter` API that handles some normalization [5], and I _am_ considering trying to add some more involved abstraction to RTK in the near future [6].

[0] https://redux.js.org/faq/general#when-should-i-use-redux

[1] https://redux.js.org/faq/organizing-state#do-i-have-to-put-a...

[2] https://redux-toolkit.js.org

[3] https://deploy-preview-3740--redux-docs.netlify.app/tutorial...

[4] https://redux-toolkit.js.org/api/createAsyncThunk

[5] https://redux-toolkit.js.org/api/createEntityAdapter

[6] https://github.com/reduxjs/redux-toolkit/issues/603

Re: Do Not Follow JavaScript Trends

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

Re: Do Not Follow JavaScript Trends

#193
post #54

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…

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'…

When you found the fetch API horrendous were you using async/await? They make it not horrendous.

You don't have to keep up with which feature ships in which browser; that's what browserslist is for. https://github.com/facebook/create-react-app/blob/master/pac...

Re: Do Not Follow JavaScript Trends

#194
post #142

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 Deco…

Yeah; I think your timeline is off. I don't remember React being the very clear choice until probably 2017. It was still up in the air in 2016, and certainly moreso in 2015. > by 2015 React "won" the framework battle. Things have calmed down now. Its better, and has been for a couple years (not 5+ years). But, this isn't a battle. Its not a war. Just because things are calm now, doesn't mean they won't go crazy again…

Either way the article is way off:

> Let us quickly travel back in time to 2016 ... If you are using a JavaScript framework or want to use a framework, Angular.js is probably something you would choose

Angula.JS was in the "failed experiment" category by 2016. The announcement that Angular2 was a rewrite (in 2014) was proof of that.

So in 2016 Angular was still really new and React had eaten AngularJS's market share.

Re: Do Not Follow JavaScript Trends

#195

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 "How browsers work": https://www.html5rocks.com/en/tutorials/internals/howbrowser... "High performance browser networking": https://hpbn.co/

I would add Javascript- The definitive guide (David Flanagan) I just bought it again, Version 7 just been released 9 years after version 6. It’s an amazing book.

Re: Do Not Follow JavaScript Trends

#196

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…

> the w3c fetch function is definitely better for your users

Sure, unless your users are desktop IE11 users. They won't care about 4.4kb but they'll definitely care about a broken page :)

Re: Do Not Follow JavaScript Trends

#197

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 Deco…

But how long was Angular in vogue before React? If it was also ~5 years then a shift in frameworks every 5 years of calm + 2 years of chaos still isn't ideal.

Re: Do Not Follow JavaScript Trends

#198

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 Deco…

You are overly optimistic with the timeline. No, React had not "won" by 2015, not even by 2016[0]. Also the burn of more than half a decade is very real, both on developers and in codebases. [0] http://2016.stateofjs.com/2016/frontend/ . From that link: > What's more, there's just so many options: Do you use React or Angular 2? Do you really need Webpack? And what's this month's recommended way of dealing with CSS? >…

From that survey, is you look at positive (would like to learn + would use again) vs. negative responses (not interested + would not use again), it looks like React is crushing everything outright. 85% positive / 15% negative. Amongst the other frameworks, the only one without at least 50% negative response is Vue at 43% positive / 35% negative, with a heart "never heard of it" segment as well.

Re: Do Not Follow JavaScript Trends

#199
post #147

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 Deco…

You make it sound like we're all using React and that's all there is to it. That's not quite true, and it's just one of the choices you have to make. So you've decided on React, but what about state management, transpilation, do you use GraphQL? What am I doing for styles, should I write them in Javascript too now? Oh no! Webpack isn't for me! Can I use modules yet? Ah bugger, we need SSR, suppose I should have manag…

Excuse me, it isn't a real frontend without a service worker and offline capabilities.

Re: Do Not Follow JavaScript Trends

#200

Earlier quoted context omitted.

I'm just now getting back into webdev after 3 years. Can you please recommend a good tutorial/demo using Hooks? Especially if it's using Typescript! I strongly dislike the create-react-app project because it abstracts everything away.

For react hooks: the base results are decent, for that particular search phrase. You won't go wrong with the reactjs docs, prominently placed there. https://reactjs.org/docs/hooks-intro.html For react hooks typescript: sorry, I can't. This is a pretty good example of the problem, because I just searched Google's first page of results for react hooks typescript tutuorial, and they were all bad. 3 of very top results s…

> Also I want to call out this example for being especially ridiculous, because it titles itself as "Using React Hooks with Typescript" and then doesn't actually use any Typescript!

That is all 100% valid, fully typed TypeScript

TypeScript's inference is smart enough to know that ...

    const [count, setCount] = useState(0)
... is the same as ...

    const [count, setCount] = useState(0)
Post reply on HN