61–70 of 279 posts
> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…
Are these now useable on any contemporary browser? Or do you use some kind of polyfill? Anyone have a good from-zero tutorial for the approach OP is talking about?
> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…
Earlier quoted context omitted.
> Web Components is it's slower than React or other vDOM implementations > To re-render, you have to manipulate the innerHTML--usually replacing the string every update "Usually" is relative, I guess, but nothing's stopping you from using the imperative DOM APIs to update the component's contents; I daresay this would be the typical thing to do. These APIs will be just as performant as anything else out there. What y…
If you're using a framework like lit-html as the author recommends, it will replace the string every update. Most people will prefer that way since it's more ergonomic and similar to React. You could do imperative DOM updates, but that'd be like going back in time to jQuery.
This video is a few years old, but the core concepts remain the same.
Earlier quoted context omitted.
Anyone know what is going on with lit-? Their TypeScript starter is painfully bloated and outdated and never seems to keep pace. I actually ended up looking at microsoft/fast for my use case but that seems to be stale in some way. I kind of feel that given the "simplicity" of a single class wrapping custom elements, everything is pretty boring. Note: I cannot do better.
I feel like google does web component frameworks like it does messaging apps. Each new one is the silver bullet. I wouldn't build on any google web framework personally, even if it claims to be oh so simple and lightweight.
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…
Is this actually how people pass props with Web Components? I've only used web components for a few years but I've always created a new instance of the class and I pass props using the constructor like:
`${new ExampleComponent(props)}`
Then in the constructor it's just this.state = {...this.state, ...props}
If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…
This is a classic red-herring argument from developers who have not built anything complex with vanilla js. You can build rich interactions with or without a framework, you’re just making different trade-offs (conventions, learning curve, flexibility, tooling).
There is a much larger amount of man-hours put into browser APIs, and web components is one of them. I don’t see anything wrong or that warrants a “you’re wasting your time” warning in his argument. And note, he’s talking about the chrome dev tools everyone including the react team use daily, not “basic forms”.
> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…
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.
If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…
The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.
Earlier quoted context omitted.
What is a reactive data source?
RxJS aka the reason so many websites take 100MB of memory nowadays Don't use it