Live data from Hacker News

State of JavaScript 2021

2021.stateofjs.com

201–210 of 245 posts

Re: State of JavaScript 2021

#201
post #171

Earlier quoted context omitted.

After a read, I guess it does. A developer I respected claimed it was not easy to pass components down like this. Now I no longer respect him. Also, I still don't respect vue. Look at this abomination {{ text }} {{ count }}

You can respect that developers you respect are humans who make mistakes and misunderstand things. As you've done, you've made an inaccurate claim and learned from it. Hopefully you still respect yourself. Also (and I'm not familiar with Vue to know if this is the case), the state of software is such that you can make a claim and have it invalidated a few days later after an update comes out.

> You can respect that developers you respect are humans who make mistakes and misunderstand things

No I can't.

Seriously, it was a joke, he's my best friend, but I guess I misunderstood his claim or he misunderstood render props!

From what I can see reviewing Vue's 2.x docs, they seem to have had this "slots" idea for a while. I get a little bit ill from looking at that syntax though so I think I'll refrain from arguing about the library again!

Re: State of JavaScript 2021

#202

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…

> has growing pain with typescript and esm support. I'm curious - what do you mean by this? Been using Jest in multiple codebases with typescript and ES Modules and never ran into an issue.

My experience has been that basically every time you need to change your Babel/typescript/webpack configuration you have to do it a second time, with a different set of quirks and constraints, for Jest. It's not a blocker but it's a persistent pain

Re: State of JavaScript 2021

#203
post #200
post #183

Earlier quoted context omitted.

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

Aren't desktop solutions typically vendor locked?

Yes. So I paid money for tool that works nicely and saves me from the insanity web front end is (on desktop obviously). On a browser it is to the point that I prefer plain Java Script with couple of libs instead of those frameworks that supposed to make my life easy but look like abomination when I compare to something like Delphi

Re: State of JavaScript 2021

#204
post #156

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…

Oh cool, that's very clever! Probably a little too clever for me, though :P I think the code is misleading, and you can't handle classes with hyphens in it (and if you do, that's even more misleading!). But it's a neat application of proxies! For folks wondering, here's how it would work: const htmlClasses = new Proxy({}, { get: (target, prop, receiver) => document.querySelector('.' + prop) }); // Get element with cl…

Yes you can definitely argue that it is misleading, but given the alternative I was faced with (React) whose entire world is misleading and unknown, I decided I liked this option better. I write less code, I understand my code more, and it is native hand-written performance. You can also argue that these are all features of JavaScript, and so if you think that is misleading, getters are also misleading because the getter could be doing all kinds of things even though it looks like a standard property access. So it has to be put into perspective with Vue/React/etc, where your code doesn't even correspond to anything and the React engine underneath recreates the dom, diffs it, updates when it wants, etc, and the setState stuff relies on declaration order and all kinds of ridiculous garbage.

Anyway, I just think it is cool kind of for the same reason it is misleading :)

You can do a loop like:

  for (let i = 0; i 
and cool is actually a new div each time, even though you would think it was the same cool from divs (divs.cool). It also caches the div, so it is faster than even if you wrote the manual version with createElement.

I could get rid of it, because my other approach to element creation would is:

  const cool = div({ className: 'cool' });
which isn't too bad, but when I have a lot of divs, it is just nicer to do:

  const {
    root,
    headingContainer,
    userContainer } = divs;
Also, yeah, it actually creates hyphened classes. so headingContainer goes to .heading-container. That is just how I work and so it is a convention.

Re: State of JavaScript 2021

#205
post #180

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…

How badly do proxies affect performance?

They don't at all, at least in my implementation. I read that they affected performance greatly, but all of my real world and bench mark testing says they don't at all, and in fact allow me to cache partially created elements to improve performance.

Re: State of JavaScript 2021

#206

"Popularity contest" describes the front-end community in a nutshell. I've been in software development since before the web was a big deal. Never have I seen any language have more "high school popularity" style personalities hawking whatever the "best" library is... without any knowledge or wisdom. Any attempt to point out why some of these technologies or approaches are a "bad idea" leads to massive downvote train…

As a person new to web development, I feel the same as what you have described. Since I'm not that long in I.T. I would ask... What could we learn from the past?

Re: State of JavaScript 2021

#207
post #147
post #136

Earlier quoted context omitted.

Well, if developers would approach their task with knowledge and wisdom, then the abomination that is Node.js would never have been unleashed on the developer community. But here we are: "yay, Google has written a blazingly fast JS engine, so now we can use JS in the backend!" - never once stopping to question if this is really a good idea...

I miss the days when bundling was just dumping a couple of JS scripts into the scripts/lib directory and that was it. Guess what is my approach when having side gigs.

>Guess what is my approach when having side gigs

Webpack?

Re: State of JavaScript 2021

#208
post #136

Earlier quoted context omitted.

Well, if developers would approach their task with knowledge and wisdom, then the abomination that is Node.js would never have been unleashed on the developer community. But here we are: "yay, Google has written a blazingly fast JS engine, so now we can use JS in the backend!" - never once stopping to question if this is really a good idea...

I almost spit out my coffee. I had completely forgotten that's how we got here. It developed like pretty much everyone thought it would.

Is it that bad? I'm kinda new to web development.

Re: State of JavaScript 2021

#209

Earlier quoted context omitted.

I believe React is inherently terrible, rather than your reason. I think all libraries that try to abstract an underlying technology into something that it is not, and then also have to provide escape clauses for the abstraction because the user actually has to know how the underlying stuff works, are inherently broken. I also think state-based reactivity is a terrible way to reason about things because sometimes you…

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…

>it doesn't sound like you are offering an alternative.

Actually, I create a library github.com/thebinarysearchtree/artwork which I use but haven't documented for public use. You can probably see some earlier versions of actual components in the history with the initial commit. I think I created a login component or something. The essential concept behind it is that html is no longer necessary in a component world, where everything is broken down into little pieces and spread out inbetween loops and so on. Removing html and having access to the live dom elements, and using modern JavaScript and dom API features is now a better alternative than all of these ridiculous libraries that are just variations of React or Vue or insane with their own compilers and virtual doms and god knows what else.

>State updates -> View updates

state updates -> query updates

state updates -> url / history updates

>A library that let's me focus on business logic rather than boilerplate or implementation details is one that I want to continue using.

From my experience, these implementation details are important. The library I use is less code than React and shows the implementation details so you know what is happening.

>The [rules of hooks][1] that React provides is just two items

That definitely isn't correct. It is missing the warnings about dependencies, where async methods can run, and a lot more. There is a list of eslint warnings somewhere. There are a lot of rules of React and hooks and the different types of hooks and they are all in the documentation and not visible in the code. The order of your setState calls is important, you can't use async in certain places, the state has to be assumed to be stale unless you do setState(a => a + 1) etc. It is quite frankly ridiculous. There is so much happening that is all hidden in magic.

Bluntly, I think it is all complete garbage that is more complex than it should be and there are now so many people writing incompatible React instead of standard JavaScript that works for everybody. I just find it hard to believe that there is anybody who has written a large project in React and has come away with any conclusion other than that React is complete and utter garbage. It is a failure and it will not stand the test of time. The only people who could think otherwise: have some kind of cocoon set up by a large tech company and they basically just write demo code all day, or they haven't worked with React long enough.

My library, which I have used to rewrite a large application with, is less code, faster, and easier to understand. I proved that React is complete garbage to myself by doing that.

Re: State of JavaScript 2021

#210
post #185

Earlier quoted context omitted.

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/

Lit is just react with web components. It uses all the same magic, and a whole bunch of documentation is needed (is this state reflective, reactive, blah blah). It does the same "let me figure out updates in the background and you don't worry about it" as React, just without a virtual DOM.
Post reply on HN