Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of JavaScript 2021

2021.stateofjs.com

Post reply on HN
Print view View original

181–190 of 245 posts

Re: State of JavaScript 2021

#181

Post by synergy20 »

Someone1234 wrote: post #169
synergy20 wrote: post #150

Spent one hour to wade through all these results, here are my take away: 1. stay with Typescript 2. embrace vite, pnpm 3. keep using eslint and prettier 4. svelte is below React but *above* vue now! what a momentum. I'm going to checkout svelte one more time and see where it is better than vue.

What advantages does pnpm have over yarn? I'm all on board with npm being problematic due to the security-design, but does pnpm solve that weakness better than yarn or provide other killer features? PS - No testing framework in your list. Any reason?

forgot testing, I use jest and am looking into vitest

Re: State of JavaScript 2021

#182

Post by jimmont »

Deno missed the library list (it includes an extensive standard library) and I'm glad to see it in included in the runtimes and mention of new things. I just finished moving an app from Nodejs+npm to it and am finding work is quite a bit easier. Initially I'd thought it was completely missing.

Re: State of JavaScript 2021

#183

Post by FpUser »

canaus wrote: post #168

There seems to be a bit of animosity towards front-end development based on the comments. Particularly due to the constant change of the environment and what's perceived as the best option. But, there haven't been calls for solutions. There's points to backend technologies not changing much. My thoughts are because the backend just doesn't matter as much. Backends are mostly I/O streams placed and interacted with on…

>"There seems to be a bit of animosity towards front-end development"

On desktop we have nice mature solutions that are powerful and easy to use. Comparatively browser based front ends are a never ending mess in a state of constant swings.

Re: State of JavaScript 2021

#184

Post by Volrath89 »

tmstieff wrote: post #47
searchableguy wrote: post #17

Earlier quoted context omitted.

People inheriting old react codebases now have to deal with way more complexity. For example, everyone was using styled components 2-3 years ago and now they are moving away. The complexity styled components introduced has to be managed alongside the current trend (tailwind?). Old styled components codebase looks horrible. They end up with Java inheritance hell. You create a button, then create another button inherit…

I'm working on a codebase that evolved at the same pace as React, but without any thought for idiomatic principals. As a result, you have class-based components, purely functional components, hook based components, HOCs, Redux state passed in through the older functional way, Redux state passed in through an HOC, styled components, traditional CSS styled components, and anything else you can think of that was in vogu…

Yes! I feel exactly the same.

I don't think I'll be looking to work in a react codebase in the future again. I don't know what was wrong with class based components, especially the lifecycle methods, they were so easy to understand/read. But almost every react codebase is now a combination of classes/hooks or 100% hooks which imo is so messy/unreadable...

When I will be looking for a job change I'll definitively look for angular only jobs (or even better, backend only)

Re: State of JavaScript 2021

#185

Post by mhoad »

romellem wrote: post #170
ricardobeat wrote: post #158

Earlier quoted context omitted.

> A library that let's me focus on business logic rather than boilerplate or implementation details is one that I want to continue using. React is the exact opposite of that. Endless boilerplate, abstractions and unwritten rules. As the reality of large projects sets in, they look nothing like the starter examples.

What frontend library do you think offers less boilerplate, clearer abstractions, and more well defined rules?

I really enjoy the Lit model. It’s quite a bit faster than React, it is a tiny bit of syntactic sugar on top of browser APIs. It’s powering Photoshop (https://web.dev/ps-on-the-web/) and a future release of YouTube I believe.

Take a look at real code here https://lit.dev/tutorial/ and component conceptual model here https://lit.dev/docs/components/overview/

Re: State of JavaScript 2021

#186

Post by agumonkey »

rk06 wrote: post #160
agumonkey wrote: post #19

Earlier quoted context omitted.

Interesting pov. If people had a say in choosing something 90% like react, would they work happier ? Just like clients needing 4 times the same design just so they can pick their preferences?

react also happens to be The js framework used by meta. and the most popular js framework. how do you get something like 90% of that?

My comment wasn't clear but I had this idea that if someone made a clone of react called flowy with only marginal changes, people might be happy to use that because it's just "not react" anymore. I was questioning the emotional aspect of group work.

Re: State of JavaScript 2021

#187

Post by mhoad »

smrtinsert wrote: post #149
topicseed wrote: post #36

JS and TS brought so much happiness to me for years. But I found it extremely difficult to constantly have to "decide" between X and Y. In the backend, I went all in with Golang and oh my... Now I just code. In the frontend, Svelte is a godsend. No longer need to find "React-friendly" libraries. Simple JS works for the most part. Not ideal but great versus React for the types of admin panels I build.

Ignoring virtual dom, the number one thing that kept me in react was normalized event handling across every conceivable type of browser that the web could throw at you. Is that no longer a thing in 2021 or do all libraries handle it?

This is one of many things that were true when React was first created and is now no longer needed. I feel like half of React’s codebase is just reimplementing features that are now browser native.

It seems like they have painted themselves into a weird spot by drifting so far from web standards because the path back doesn’t seem that obvious from the outside at least.

Re: State of JavaScript 2021

#188

Post by eyelidlessness »

davedx wrote: post #22

I read this report every year. This year it feels the most like it's driven by hype (and marketing, hi Vercel!). In my professional and personal experience, react has never been better to use (in terms of features, DX, maturity, community, productivity), yet if you look at the "popularity" (oh dear) graph, it's basically just describing how older tech slides down while newer shiny tech comes in and is instantly the m…

> […] Astro are not "back end frameworks" unless you define tech by what marketing copy people have written

I can’t speak to SvelteKit, but I don’t think Astro even markets itself as such. Last I checked it doesn’t even support SSR (though it appears to be in development).

Re: State of JavaScript 2021

#189

Post by eyelidlessness »

somehnacct3757 wrote: post #81
davedx wrote: post #22

I read this report every year. This year it feels the most like it's driven by hype (and marketing, hi Vercel!). In my professional and personal experience, react has never been better to use (in terms of features, DX, maturity, community, productivity), yet if you look at the "popularity" (oh dear) graph, it's basically just describing how older tech slides down while newer shiny tech comes in and is instantly the m…

It's always driven by hype, or maybe groupthink. Every year I feel bad for the Ember contributors when this thing comes out cuz the respondents boldly claim Ember's bad while also admitting they've never used it and have no interest trying it. The clear mark of a popularity contest.

I mean. It’s a poll. Its express purpose is measuring popularity at a point in time. I can’t imagine what else would be expected.

Re: State of JavaScript 2021

#190

Post by dbbk »

searchableguy wrote: post #17
nindalf wrote: post #3

Not surprised to see satisfaction drop with increase in usage for React. People feeling like they’re forced to use something because of external constraints (coworkers choices etc) are rarely satisfied with that choice. That’s the fate of any tool that becomes popular enough.

People inheriting old react codebases now have to deal with way more complexity. For example, everyone was using styled components 2-3 years ago and now they are moving away. The complexity styled components introduced has to be managed alongside the current trend (tailwind?). Old styled components codebase looks horrible. They end up with Java inheritance hell. You create a button, then create another button inherit…

> For example, everyone was using styled components 2-3 years ago and now they are moving away.

What are you basing this theory on, and what do you think people are moving to? In my experience it's still the go-to industry standard.

Post reply on HN