Good to understand, but most likely better to stick with react for production stuff anyway
Yup, the 2000 libraries you depend on when you run npm install react won’t have any bugs and will always work together.
/s
Plain Vanilla Web
21–30 of 715 posts
Re: Plain Vanilla Web
#22I support the general idea here but just because something is in a browser doesn't mean it's a good formalism.
Notably, Web Components. They're fantastic for distributing components - after all, a Web Component will work in every framework (even React, the IE of frameworks, finally added support), or even in vanilla HTML. So you can build a component once and everybody can use it. It's fantastic.
But for internally composing a web application, Web Components are simply awful. They add nearly no helpful features that vanilla JS doesn't already have, and they add bucketloads of extra complexity. You got attributes and properties, and they're mostly the same but kinda not always and oh by the way, attributes can only be strings so good luck keeping that in sync. You got shadow DOM which is great for distribution but super restrictive if you want any sort of consistent global styling (and a total pain in devtools, especially once you go 10 levels deep). You can turn that off, of course, but you gotta know to do that. And plenty more quirks like this. It's just.. It makes lots of easy things 5x harder and 1 hard thing 1.5x easier. Totally not worth it!
If you really want to not use a big clunky framework, but at the same time you have a complex enough app that composition and encapsulation is important, you'd be much better off just making your own object hierarchy (ie without extending HTMLElement), skipping all that awkward web component luggage and solely doing what they do best (tie an object to an element).
Or, better yet, get over yourself and just use a framework that does this for you. Your future self will thank you (and your colleagues even more so).
ps. rant time: If only the web browser people had gotten off their high horse and not proposed the word "Web Components"! If they would've just been named "Custom Elements", which is what they are, then we wouldn't have had 5+ years of people mistaking them for a React competitor.
Re: Plain Vanilla Web
#23Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely.
I run sites that serve hundreds of millions per day and we pour a ton of resources into these projects. We're trapped in a framework (react) prison of our own creation. All failures are those of complexly. Highly coupled state machines with hacked, weaved, minified, compiled, transpiled, shmanzpiled etc. into unreadable goop in production. Yes I know source maps, but only when needed, and they are yet another layer of complexity that can break - and they do. How I long for the good old days before frameworks.
Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework.
Re: Plain Vanilla Web
#24Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!
Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.
Re: Plain Vanilla Web
#25Any attempt to show that vanilla web components are somehow a viable solution always read like a parody.
The boilerplate, the innerHTML strings, the long list of caveats, the extra code to make basic things like forms work, manually attaching styles etc. etc.
Re: Plain Vanilla Web
#26Very cool overview and a great article—it’s fascinating to see how far web components have come. Data passing, interactivity, and state management still seem pretty tedious in vanilla, though!
Data passing seems inherently broken in web components, because all HTML attrs must have string keys and values. Such a model just can't be built on top of.
Web Components can have properties too, and in fact this is the norm.
Re: Plain Vanilla Web
#27Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely. I run sites that serve hundreds of millions per day a…
At 100s of millions I’m assuming you have something closer to a static site than an application?
Re: Plain Vanilla Web
#28I think routing components are mostly out of date now that CSS View Transitions exist.
Re: Plain Vanilla Web
#29I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.
I have seen more broken SPAs than MPAs, by far. Ironic, considering SPAs are supposed to improve conversion rates and user experience. Even from big companies with no excuse - Reddit is almost unusable on phones, X was straight up broken for a month straight with image loading on mobile.
If you’re writing an SPA, and it isn’t Twitter or a content consumption platform, and it isn’t necessary to be API-driven, seriously just stop. You’re not clever, you’re not improving the experience, you’re only appealing to the tastes of other programmers. If billion-dollar companies can’t get them working perfectly, you certainly won’t.
Re: Plain Vanilla Web
#30Question - why would you do this in current year ? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!
Frameworks are fine when you just need to get a job done quickly. And they're ideal when you're in a typical corporate code factory with average turnover, and for the same reasons Java is ideal there. React is the new Java. But when you need something the framework can't provide, good luck. Yes, high performance is typically one of those things. But a well engineered design is almost always another, costing maintaina…
> React is the new Java.
Overly hated on and conflated with frameworks, yes.
React requires very little from you. Even less if you don't want to use JSX. But because Facebook pushes puzzlingly heavy starter kits, everyone thinks React needs routers or NextJS. But what barebones React is, at the end of the day, is hardly what I'd call a framework, and is suitable for little JS "islands."