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

111–120 of 245 posts

Re: State of JavaScript 2021

#111

Post by junon »

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

It's pretty much all hype now, and the 'vibes' have gotten so toxic and corporate that it's hard to really enjoy doing FOSS for Javascript nowadays.

Re: State of JavaScript 2021

#112

Post by arvinsim »

egeozcan wrote: post #76
tmstieff wrote: post #47

Earlier quoted context omitted.

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…

From here, your problem sounds like a broken code review process or missing/unclear style guides in teams/company. > I'm not sure if this effects other frontend frameworks as much, but it does seem like React was always pushing for a "new way to do things" every year. In my experience, it purely depends on how you regulate the code internally. You can always find developers using something shiny every week when you a…

> It may be amazing tech, but do you really need it if you can KISS without it?

I am only half joking when I say that most developers would say yes due to Resume Driven Development

Re: State of JavaScript 2021

#113

Post by junon »

rk06 wrote: post #108

Full version of conclusion, by swyx : https://www.swyx.io/state-of-js-2021/

> JavaScript is in a tremendously better state today compared to the first survey in 2016. Back then, only 21% of you used TypeScript, compared to a nice 69% today.

... what? Typescript isn't Javascript, just like C++ isn't C. They're two completely separate languages controlled by two completely separate entities.

Typescript is cool but it's not a replacement to Javascript. I don't see the point of implying that not using Typescript is "not nice".

Re: State of JavaScript 2021

#114

Post by andreime »

sensanaty wrote: post #100
kklisura wrote: post #92

Earlier quoted context omitted.

Handlebars extends on Mustache which considers itself "logic-less" templating language. I think `{{#if (and foo bar)` goes against that principle, so introducing ie `shouldShowX` property on component which then depends on foo && bar and just using `{{#if shouldShowX` really helps.

I do understand that reasoning, but that comes back to my annoyance with having to deal with a million files to do anything simple. I then need to create a backing controller if it wasn't there before, and if it is there, I need to add on an extra computed on top of the mess of other computeds already present. Why so complicated? JSX and Vue's flavor of templating is infinitely better, since it's basically just regul…

I've read your comments and it looks like a mess of a codebase, more than a "framework mess". It seems like a bad experience and I would not want to deal with deep inheritance and over-reliance on old/deprecated functionality (computed properties), so... hug.

Controllers are not required for anything except query params mapping. It's perfectly fine, and I think very common, to load data in components. A rule of thumb is to load in the route only the minimum amount of data for your layout to work. As for the million of files ... React co-locates template and logic code while ember-cli generates a js/ts file, a hbs file and a test file. It's either 2 to 3 (if you count a test file for the React component) or 1 to 2 (discard test files). Finding the sweetspot between large components and multiple components is not easy. For example, it was considered a best practice to apply the presentation-container pattern in React, which means 2 components.

I'm not going to say anything about your claim that JSX is regular javascript in the template.

Re: State of JavaScript 2021

#115

Post by lmiller1990 »

jve wrote: post #4

Gulp build tool not receiving much love lately with a very strong "Would not use again". Why so? https://2021.stateofjs.com/en-US/libraries/build-tools/#buil...

Webpack and friends do a lot of what people used to do with Gulp, I guess. I still use Gulp as a task runner to kick off my various dev servers (including webpack).

Re: State of JavaScript 2021

#116

Post by [deleted] »

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…

[deleted]

Re: State of JavaScript 2021

#117

Post by bretnsug »

seumars wrote: post #104
rembrant wrote: post #63

Proxies are cool. I use them in github.com/thebinarysearchtree/artwork which I haven't released. That libraries tag line is "you wanted less javascript and more html, so we delivered - artwork, the 100% javascript and css front-end framework". Anyway, I use proxies when I want a bunch of divs with classnames. You just do const { container, heading } = divs; and then container is assigned to an HTMLDivElement and the…

Your comment makes no sense without you specifying what the "divs" variable value even is.

> because divs is a proxy for an object with getters that can figure out the name of the variable you are destructing into and create a new element with that class name

A never ending well of new divs that have the class name of the variable name

Re: State of JavaScript 2021

#118

Post by topicseed »

slim109ya wrote: post #65
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.

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

Golang also has a rich ecosystem of external community libraries but

1) the standard library is often enough to get work done (http server, sql, etc)

2) external libraries often would simply sit atop the standard library which is easier to standardise and swap things around

3) the language is quite bare and simple, I was weirded out by the "for" in Go but I now like it. Need to map, filter, or increment counters? Use "for".

4) No need to hesitate between 5 linters or testing libraries, "go" does it so again it's standardised.

As for Svelte, I'm not loving it as much as Go but for frontend, it's just the most "JS/TS" of all without added layer of magic. There is still some, but it's graspable.

Re: State of JavaScript 2021

#119

Post by samwillis »

seumars wrote: post #105
samwillis wrote: post #73

When choosing a framework to build with now, I always look at how the project is funded and increasingly want to see a business backing it where it's a core part of their business model. That's what's so appealing about Svelte, now its effectively funded by Vercel, they need it to thrive as they want people to host their Svelte app on their platform. The other one with an even more explicit in its commercial support…

"a core part of their business model" means actively look for vendor lock-in. I have to say I don't get it.

Ok, so an examples of what I mean:

Ionic (the company) have the Ionic Framework and Capacitor for mobile development. They also provided consulting services, paid plugins, and build automation for it, all very much optional. It’s open source and they give every impression of maintaining it for the long haul without going closed sauce.

I means they are actively invested in it for the continuity of their business but also committed to it being an open source platform that doesn’t require the use of their paid services. But they are there is you want them.

That’s what I like.

Re: State of JavaScript 2021

#120

Post by twomoonsbysurf »

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…

No post body was provided.
Post reply on HN