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

Why I don't miss React: a story about using the platform

jackfranklin.co.uk

Post reply on HN
Print view View original

271–279 of 279 posts

Re: Why I don't miss React: a story about using the platform

#271

Post by dtagames »

dmitriid wrote: post #262
dtagames wrote: post #261

Earlier quoted context omitted.

I do understand that string concatenation and DOM rewrites are happening under the hood. How could they not be? But the point of using an abstraction like Lit is that I don't have to worry about that part. Are you suggesting that Lit is updating .innerHtml when it doesn't need to? And are you sure about that? Because that should be entirely under my control by setting properties or state of the component, not by Lit…

> Are you suggesting that Lit is updating .innerHtml when it doesn't need to? Literally nowhere did I say that. I was responding to a specific thing.

So what exactly is the complaint? You said that tagged templates require needless updates to .innerHtml and that "string concatenation" is the only thing they can do. Now we are agreeing that that's not true? :-)

How is it "objectively false" that Lit mixes regular HTML with data binding? That is exactly how it works. I have several Lit apps and they use regular HTML as well as custom components and both have access to Lit properties and state that are dynamic.

Are we talking at cross-purposes or are we trying to say the same thing two different ways? I use this tech every day and I feel like you're saying something about it that's not true -- or maybe I'm not understanding your view.

Re: Why I don't miss React: a story about using the platform

#272

Post by dtagames »

TAKEMYMONEY wrote: post #256
dtagames wrote: post #244

Earlier quoted context omitted.

There is no doubt that, when using Lit, you're going to re-write portions of some existing framework. That's the big selling point: You're going to write them your way, and only the ones you need. Instead of inheriting and learning React (or Angular, or Vue), you decide what syntax and behavior your components will have -- all the way down to "bare metal" of when and if they render and with what contents or results.…

> create all kinds of new behaviors that React doesn't understand Care to expand? (I'm working on SVG-as-React-component stuff.)

Sure! What I mean is that, since the web components are bare metal, they can be very specific to my game. I have SVG components that return graphics, change colors, move themselves around, etc. based on properties and state in the app. Because they aren't based on canned components, I don't have to worry about shoehorning what I want into a React component that's really made for something like text or a dropdown, etc.

Re: Why I don't miss React: a story about using the platform

#273

Post by ratww »

interlocutor wrote: post #260
ratww wrote: post #210

Earlier quoted context omitted.

This whole article is about an edge case where components have an internal "draft" state and an external "final" state, where both represent the exact same thing , and you want internal state to change when props change. This, in itself, would be an anti-pattern in any kind of programming, reactive or not. What the author is trying to convey is that using getDerivedStateFromProps is not the best idea, and there are t…

Nothing has changed in the last 4 years. Any time you have props and state, updating props is best done by replacing the component by changing the key. If you think hooks has fixed this, you are welcome to point to an article or code that demonstrates that. All of this complexity is completely unwarranted, which is the point of the article at the subject of this thread. You can do it with simple vanilla js and it is…

> Any time you have props and state, updating props is best done by replacing the component by changing the key

No, it isn't. This is a ludicrous statement.

Replacing the key will RESET the internal state of children objects. Meaning you can't use this workaround for any component that has any kind of internal state does not come from props.

See for yourself: https://codesandbox.io/s/compassionate-williamson-qezsw5?fil...

On the other hand, it is completely trivial to update props that don't affect internal state. This article is only about updating props that affect internal state of components that don't have any other internal state.

> All of this complexity is completely unwarranted

No. All of this complexity you're complaining about exists for one very specific edge case, and this edge case exists in non-reactive frameworks too. You're just extrapolating the complexity of one single edge case to the whole framework.

Re: Why I don't miss React: a story about using the platform

#274

Post by dmitriid »

dtagames wrote: post #271
dmitriid wrote: post #262

Earlier quoted context omitted.

> Are you suggesting that Lit is updating .innerHtml when it doesn't need to? Literally nowhere did I say that. I was responding to a specific thing.

So what exactly is the complaint? You said that tagged templates require needless updates to .innerHtml and that "string concatenation" is the only thing they can do. Now we are agreeing that that's not true? :-) How is it "objectively false" that Lit mixes regular HTML with data binding? That is exactly how it works. I have several Lit apps and they use regular HTML as well as custom components and both have access…

> You said that tagged templates require needless updates

I never said needless

> that "string concatenation" is the only thing they can do

It's not what "they" need to do. It's what you, or the library using them needs to do.

> Now we are agreeing that that's not true

If you invent something that I never said, then yes, we can both agree it's not true.

> How is it "objectively false" that Lit mixes regular HTML with data binding?

Once again that is not what I said. The objectively false statement is that it's "regular HTML". Lit is a HTML-like DSL because none of this is "regular HTML" because those attributes are invalid in regular HTML:

   html``

   html``

   html`Go`
And, on top of that it even adds constraints to tagged literals themselves:

   // Valid JS, and valid tagged literals. Invalid Lit
> Are we talking at cross-purposes or are we trying to say the same thing two different ways

No. You're inventing things that I never said or implied and arguing against those inventions.

Re: Why I don't miss React: a story about using the platform

#275

Post by ricardobeat »

srcreigh wrote: post #105
ricardobeat wrote: post #63

Earlier quoted context omitted.

React doesn’t offer any render optimizations by default, so not worrying about it sounds like blissful ignorance - you’re just ignoring a ton of unnecessary renders because they don’t visibly affect performance (on your development device). After a certain level of complexity the issues will start to show.

React offers tons of optimizations for not re-rendering. useEffect, useMemo, useCallback.

Not true. Even if you memoize all the values and props used, your component will still execute, generate vdom and go through reconciliation. You must use React.memo in addition to memorizing everything in order to completely prevent a no-op re-render.

Re: Why I don't miss React: a story about using the platform

#276

Post by xtalx »

I think React is great. In Some instances of useEffect can seem inscrutable. I believe svelte is a great counter to a lot of the ceremony in React and I see it as the most compelling “framework” available. I sorta miss JSX with it but it’s not that important after a while. I find all the tech and rhetoric that comes from Google Dev Rel people (excluding a few gems) to be either pretty damn good but evangelized distastefully or just straight up incoherent. I find everything thing with web components and shadow dom and all that abhorrent. Yeah it’s the “platform” but the APIs are super complex, convoluted and filled with caveats all to not use a framework. I also believe the narrative that big JS bundles are ruining the web is a diversion. Google, and more specifically, monetization and advertising is ruining the web directly. Large JS bundles are secondary. Advertising and ad revenue ruined the web before the much aligned SPA.

Re: Why I don't miss React: a story about using the platform

#277

Post by dtagames »

dmitriid wrote: post #274
dtagames wrote: post #271

Earlier quoted context omitted.

So what exactly is the complaint? You said that tagged templates require needless updates to .innerHtml and that "string concatenation" is the only thing they can do. Now we are agreeing that that's not true? :-) How is it "objectively false" that Lit mixes regular HTML with data binding? That is exactly how it works. I have several Lit apps and they use regular HTML as well as custom components and both have access…

> You said that tagged templates require needless updates I never said needless > that "string concatenation" is the only thing they can do It's not what "they" need to do. It's what you, or the library using them needs to do. > Now we are agreeing that that's not true If you invent something that I never said, then yes, we can both agree it's not true. > How is it "objectively false" that Lit mixes regular HTML with…

I still don't understand the objection. Your example of invalid Lit is something I would never write. Lit is perfectly helpful without it. What makes you say the .value and @click attributes are invalid? In some older HTML spec, you mean? They certainly work correctly in modern browsers.

You can definitely mix data binding with regular HTML. It might be "invalid" according to a spec that makes no difference. The point of all of this is to write apps that work and can be debugged.

What is the rallying cry against Lit, exactly?

Re: Why I don't miss React: a story about using the platform

#278

Post by dmitriid »

dtagames wrote: post #277
dmitriid wrote: post #274

Earlier quoted context omitted.

> You said that tagged templates require needless updates I never said needless > that "string concatenation" is the only thing they can do It's not what "they" need to do. It's what you, or the library using them needs to do. > Now we are agreeing that that's not true If you invent something that I never said, then yes, we can both agree it's not true. > How is it "objectively false" that Lit mixes regular HTML with…

I still don't understand the objection. Your example of invalid Lit is something I would never write. Lit is perfectly helpful without it. What makes you say the .value and @click attributes are invalid? In some older HTML spec, you mean? They certainly work correctly in modern browsers. You can definitely mix data binding with regular HTML. It might be "invalid" according to a spec that makes no difference. The poin…

> I still don't understand the objection.

Please re-read what I wrote in my very first comment

> What makes you say the .value and @click attributes are invalid?

Just checked the spec, you're right they are valid. Hm, I was sure they weren't. Won't dig through the history to see if this changed :)

However, "Authors must not use elements, attributes, or attribute values that are not permitted by this specification or other applicable specifications, as doing so makes it significantly harder for the language to be extended in the future.", https://html.spec.whatwg.org/multipage/dom.html#elements

So I'd say they are still not okay on existing HTML elements

> It might be "invalid" according to a spec that makes no difference.

That is a very bad stance to take. "Invalid to the spec, but who cares".

> What is the rallying cry against Lit, exactly?

There's no rallying cry against lit. Stop. Inventing. Words. And. Meanings. I. Never. Said. Or. Implied.

There's a single very literal comment I made with links to support that statement.

I'm out of this discussion. I have other things to do with my life than keep saying "I never said what you think I said" over, and over, and over again.

Re: Why I don't miss React: a story about using the platform

#279

Post by Izkata »

semiquaver wrote: post #130
zelly wrote: post #49

The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like ). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't sc…

Every real world use of Web Components that I’ve seen uses elements and/or imperative DOM methods to implement rerendering. These are blazing fast and exactly what React uses. It’s possible to build a slow app using Web Components, but that’s true of every library, including React.

Same here; I suspect they've mixed up defining the component (where some examples do use innerHTML) and using the component (which don't).
Post reply on HN