State of JavaScript 2021 • Hacker News Board

Re: State of JavaScript 2021

#241

Post by mwid » Mon, Feb 21, 2022, 8:13 PM UTC

junon wrote: post #113

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…

TypeScript is a "replacement" for JavaScript in that it has become the defacto standard for any serious project for at least three years now.

They are not two separate languages at all, TS is a superset of JS and exists within the JS ecosystem and is designed so that JS projects can be incrementally migrated to TS, it's one of the first things in the documentation.

Re: State of JavaScript 2021

#242

Post by aarpmcgee » Mon, Feb 21, 2022, 9:32 PM UTC

rk06 wrote: post #211

agumonkey wrote: post #186

Earlier quoted context omitted.

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.

Take a look at preact. It is 90% like react in technical sense, and provides missing 10% in compat package

It’s not perfect though. The only reason I’m not using preact is that my front-end library of choice, react-aria, does not work 100% with preact, though it sounds like it might now be close (unsure).

https://react-spectrum.adobe.com/react-aria/index.html

https://github.com/adobe/react-spectrum/issues/781

Re: State of JavaScript 2021

#243

Post by grissius » Wed, Feb 23, 2022, 6:47 AM UTC

searchableguy wrote: post #13

For testing, I've been exploring vitest which is missing from this list because jest looks unmaintained and has growing pain with typescript and esm support. https://vitest.dev/ It's a drop in replacement for jest. The only change you will need to make in most cases is adding an explicit import for expect, describe, and it. It works without any config with esm and typescript. It's also 5x faster in development. It in…

I've been doing some benchmarks recently and actually it is not that fast, compared to Jest. It seems to have solved the Jest unforgivable memory leaks, but overall has much greater memory consumption.

https://github.com/grissius/jest-is-a-rude-needy-clown-and-e...

Re: State of JavaScript 2021

#244

Post by searchableguy » Wed, Feb 23, 2022, 7:48 PM UTC

grissius wrote: post #243

searchableguy wrote: post #13

For testing, I've been exploring vitest which is missing from this list because jest looks unmaintained and has growing pain with typescript and esm support. https://vitest.dev/ It's a drop in replacement for jest. The only change you will need to make in most cases is adding an explicit import for expect, describe, and it. It works without any config with esm and typescript. It's also 5x faster in development. It in…

I've been doing some benchmarks recently and actually it is not that fast, compared to Jest. It seems to have solved the Jest unforgivable memory leaks, but overall has much greater memory consumption. https://github.com/grissius/jest-is-a-rude-needy-clown-and-e...

That is due to ESM. You aren't testing the same thing in your jest and vitest test. Enable experimental support for esm in jest, change your test suite template, and run it.

I'm sure that causes the bottleneck for vitest but it's a necessary evil as ecosystem moves toward ES module and no global context across tests.

You can also speed up vitest by changing config to make it behave similar to jest, I think.

Re: State of JavaScript 2021

#245

Post by grissius » Mon, Mar 07, 2022, 8:38 AM UTC

searchableguy wrote: post #244

grissius wrote: post #243

Earlier quoted context omitted.

I've been doing some benchmarks recently and actually it is not that fast, compared to Jest. It seems to have solved the Jest unforgivable memory leaks, but overall has much greater memory consumption. https://github.com/grissius/jest-is-a-rude-needy-clown-and-e...

That is due to ESM. You aren't testing the same thing in your jest and vitest test. Enable experimental support for esm in jest, change your test suite template, and run it. I'm sure that causes the bottleneck for vitest but it's a necessary evil as ecosystem moves toward ES module and no global context across tests. You can also speed up vitest by changing config to make it behave similar to jest, I think.

I tried using the globals, but it does not have much affect, so I don't think ESM has that much to do with it, see results here: https://github.com/grissius/jest-is-a-rude-needy-clown-and-e...

The benchmark covers several different scenarios, and memory and time efficiency leans more towards Jest (which is already pretty bad as it is), so I don't think it is fair to declare "A blazing fast". The project looks promising (appreciate ESM and TS support), don't get me wrong, but speed is not its strength.