Live data from Hacker News

State of JavaScript 2021

2021.stateofjs.com

161–170 of 245 posts

Re: State of JavaScript 2021

#161
post #154
post #111

> Another guaranteed scientific finding: buying our t-shirt will increase your programming skills by over 9000! Okay, fellow kids. This report doesn't surprise me. The JS community has devolved into bunch of people who re-invent everything in 2-3 year cycles. It's Silicon Valley in online clique form - and that's coming from being both deeply intertwined in it for the better part of a decade, and working in SF big te…

> The JS community has devolved into bunch of people who re-invent everything in 2-3 year cycles. Devolved? I honestly thought it had always been this way, going all the way back to the jQuery / MooTools / YUI / Dojo days.

People were pretty supportive of each other for a long time. The community was a somewhat tighter-knit group of people just enjoying seeing what could be done with Javascript. Nowadays everything is so enterprise and formalized (see Typescript), and if you don't do X thing exactly in Y way, you're unemployable and non-"standard" (even though the "standard" changes every 6 months).

On jQuery, it hasn't really been re-invented by much these days, except for a lot of it being moved into the browser APIs directly (e.g. querySelectorAll()) which I would argue is not "re-inventing" things. Just replaced.

Anyway, maintaining Javascript projects is a chore now. People are rude, demanding, spammy, whiney, persistent, etc. It didn't use to be like this, and you don't see the same thing in other language spheres quite like you do with Javascript.

Re: State of JavaScript 2021

#162

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…

> I'm not sure if this effects other frontend frameworks as much

Depends. Angular is the same old solid brick you can toss towards your enemies since 2017 or so. Vue has had at least one major breaking release, but there's a migration path, so it's not impossible to transition(although I know of one instance where the team opted for not doing that because of uncertain estimates).

But none of them have this goldfish-memory-like attraction to the new and shiny.

Re: State of JavaScript 2021

#164

Could there be a conflict of interest with the pick of the year? > Lee Robinson, Director of Developer Relations at Vercel > SvelteKit is a fresh take on building for the web and has an incredibly passionate, growing community of supporters.

Not really, Vercel has employed the Svelte creator. They don't care which framework (svelteKit in this case) is popular, as long as it drives people to use their service.

Also people can have opinions, outside of being company spoke persons.

Re: State of JavaScript 2021

#165

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.

I think I might try Golang, I would love to just code again. I'll look into Svelte as well.

The truth about Svelte post of Rich Harris is very much in point about Svelte. It gets out of your way and feels like HTML/JS/CSS + a few thought out features. You can use a lot of libraries without a wrapper for svelte.

https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...

I hope it gets adoption, I would like to work with it. I like React as well and use it but Svelte straight forward in so many situations that I just enden coding instead of thinking about X different ways to solve a problem and that is where I see similarities with Go.

Re: State of JavaScript 2021

#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 mega-monolithic-hardware.

Front-end is different in every aspect. User interaction, engine/language constraints, client differences, and more. They all come into play. The applications you can run on the front-end currently would be alien to those writing them in the 90's, 00's and early 10's.

Front-end has to deal with immensely more complexity than the backend, and therefore new solutions and technologies need to be made.

Re: State of JavaScript 2021

#169

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?

Re: State of JavaScript 2021

#170

Earlier quoted context omitted.

I really disagree with this, plus I have to say, it doesn't sound like you are offering an alternative. 1. Escape hatches are good. Designing an API is hard, and supporting every use case within that API is harder. Providing a way to make sure you don't get backed into a corner means you can continue building things. 2. State updates -> View updates seems perfectly reasonable to me. I don't think I've ever wanted a v…

> 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?
Post reply on HN