5 ms·
Web Components have got to be the single most overrated web feature I've ever witnessed in the many years I've been messing around with browsers. You know, even
by jchw 3y ago
Web Components have got to be the single most overrated web feature I've ever witnessed in the many years I've been messing around with browsers. You know, even WITH React and no Web Components, there was already a pretty reliable way to integrate third party libraries into React without a ton of glue: the DOM. Like for example, if you want to integrate a text editor like Monaco or Quill, basically all you have to do is give it a DOM node and tie together whatever props/events/bindings you want. You don't really need monaco-react, which is not even a large library to begin with.
The main reason why React is still popular is, drum roll please... The programming model. JSX is not an antiquated idea, it is still one of the better ways to integrate the UI part of a JS application into the JS part directly. I greatly prefer JS logic inside of my HTML versus a bespoke template language specifically because it's easy to compose and construct complex logic in.
I've been messing around with Svelte a bit in spare time. I really like Svelte and will probably continue to use it, but the two things I will note is:
- The integration with Web Components is imperfect and doesn't really hit me as something I would seek out.
- The templating logic in the HTML feels decidedly inferior versus just being able to use JS logic and JSX. Try doing a for loop where you count up; the best answer I could find on the internet was to construct an Array using `Array(number)` and enumerate over it...
What I really want is actually more like React's programming model with Svelte's "compiling down to nothing" mantra.
But this Web Components fervor, I know people get very heated about it, but I strongly believe that in 10 years it's going to be one of those grotesquely complex legacy features nobody can get rid of.
- TehShrike 3y agoThe shadow DOM is a great alternative to using iframes to get style isolation from the larger app, but everything else about custom elements/"web components" has better alternatives in user-land.
- diordiderot 3y ago> React's programming model with Svelte's "compiling down to nothing" mantra. Solid JS!
- deleted 3y ago[deleted]
- arve0 3y agoEach loops over anything with a length property: {#each {length: 3} as _, i} https://stackoverflow.com/questions/58213585/svelte-3-how-to-loop-each-block-x-amount-of-times https://stackoverflow.com/questions/58213585/svelte-3-how-to...
- jchw 3y agoThat's not really a huge improvement over just making a sparse array though, is it? Looks more confusing to me. Could be wrong but I'm pretty sure e.g. Array(1000000000) does not actually allocate much.
- arve0 3y agoI'm not up to speed in JSX, how is it be better there? Don't one normally map over an array to loop? You cannot use for-loops inside JSX? Or do you create an array of JSX-elements, like let elements=[] for (let i=0; i < 10; i++) { elements.push(<li key={i}>I'm number {i}</li>) } return <ol>{elements}</ol>; Does not seem like an improvement to me.
- jchw 3y agoIt's just JS: You can do that, or you can use any helper method, or write your own helper. Can't really do that in Svelte.
- jimmont 3y agocaptain obvious here, Polymer became LitElement which became the invisible Lit.dev (branding direction on par with twitter becoming x); pretty much state of the art on top of web components; not that anyone noticed, as I said--meetup.com keeps prompting me to take over one of the web component meetups where the (or one of) lead of the project can't seem to muster the effort. a bit frustrating when the lack of awareness is so profound and extensive--as evidenced by many of these comments, over many years. I'm sure many more projects will make the mistake of choosing React and Svelte before the conclusion mentioned here bubbles up.
- gabereiser 3y agoWhile JSX is very well suited for programmatically defining your UI, it's about all that React is worth these days. You know about string literals right? You don't need JSX and in-fact can get away with: render(props) { return( `<div> {props.value} </div>` ); }
- text0404 3y agoyou know about injection vulnerabilities, right? if you really want to spaghetti code your app with string representations of html, you can also use `dangerouslySetInnerHTML` in React.
- kwkelly 3y agoYou would do it as a tagged template literal rather than with plain string templating, similar to Postgres.js
- tehbeard 3y agoFor your div demo, sure, heck even the "todoapp" might work well enough with it. But please, build something proper with just that and presumably a .innerHTML = ... Let us know how it goes :)
- gabereiser 3y agoI have many times and you've probably seen it in the wild but I won't give myself away that easily. A Fortune 50 does this with great success.
- matsemann 3y agoThe point is you're susceptible to XSS attacks with that code. But with a "tagged template" it should be easy to treat the variables before actually doing the templating, without making the code ugly.
- 3y ago
- aatd86 3y agoHow does one "react" to changes in a foreign element? Mutation Observers?
- horsawlarway 3y agoThose other tools you're using almost always give you a set of callbacks or events they will fire. Just use the normal event handlers. If you're tied into a store (ex: redux/zustand/recoil/context/etc) just update the store from the non-react library and things will work themselves out just fine. You can watch the DOM with mutationObservers, but if you own both pieces (react and non-react) why would you bother? They can both coordinate just fine. MutationObservers really shine when you happen to missing an eventHandler you want in a library, or you're running on someone else's DOM so you don't control both sides (ex: you're an extension content_script).
- aatd86 3y agoI don't know.. Imagine you have a react component that needs to interact with something written in svelte... I'm not convinced that people are building integration APIs for consumption by external code. That means no JS events (redundant since it uses stores or signals and whatnot) and minimal callback availability to hook into a component state. One might not control the code if this is from an open-source library for instance. Maybe the premise is "don't do that" , but then people still wanted WebComponents at some point. So seems there exist use-cases for component interaction. Or were people mistaken in the first place?
- text0404 3y ago> I don't know.. Imagine you have a react component that needs to interact with something written in svelte... this doesn't happen in practice... like at all... is your implicit assumption that anything written in react will automatically work just fine with svelte but not the other way around? why would react -> svelte be any easier than svelte -> react, and why is the burden on React to solve interoperability problems between competing frontend frameworks?
- Izkata 3y agoOnce upon a time, I remember one of the plans for React was the ability to compile components into web components. Your code wouldn't have to change at all, but it would mean CSS couldn't leak in/out of the component boundaries like it does now. I think it would've also made it easier to use a React component in other frameworks, since all they'd see is the common web component interface instead of the React interface?
- troupo 3y ago> I remember one of the plans for React was the ability to compile components into web components. This was also the case (-ish) for Vue, Svelte, Solid. Their authors were really bullish on web components in the beginning. Now they are all on the scale from extremely negative towards them to completely indifferent.
- plopz 3y agoI think JSX was a mistake and just using hyperscript would have been better for the ecosystem. I think frameworks peaked with mithril and have been downhill ever since.
- FireInsight 3y agoSolidJS sounds exactly like what you want https://www.solidjs.com/ https://www.solidjs.com/
- jchw 3y agoThat looks great. It doesn't mention compiling down to nothing, but it definitely offers the programming model of React Hooks without needing a virtual DOM, which is already a good innovation, and probably something I'd like more than Svelte.
- MrJohz 3y agoI'm a big SolidJS fan, it's pretty much become my default framework for little things, and I highly recommend it. It is very small and very quick - one of the fastest frameworks out there - but also not too complicated or lean. The signals system takes a bit of getting used to, particularly if you're coming from the React world (e.g. there are no render functions, rather each attribute is reactively updated when its data dependencies update), but it's also incredibly powerful once it clicks. Also, once you get down to it, almost everything is just native browser elements, so if you need to integrate with another tool or library, it's usually really obvious how that should work.
- nerdyadventurer 3y agoProblem with Solidjs is lack of mature ecosystem.
- AlexErrant 3y agoI find Solid's model pretty damn close to "compiling down to nothing". I chose Solid for my project because I wanted to support plugins that used other UI frameworks. I recently got a Svelte plugin working with the SolidJS router. I could probably make it prettier... but it's literally a call to Solid's `createComponent` with the Router and an anchoring div to which the Svelte component is mounted. Ezpz. https://github.com/AlexErrant/Pentive/blob/main/example-plugins/svelte/src/index.ts https://github.com/AlexErrant/Pentive/blob/main/example-plug...