71–80 of 256 posts
The author was a core contributor of Google's Lit project: https://github.com/lit/lit
God I love lithtml’s tagged template literals so much more than react’s JSX or Vue’s 3-in-one thing. It’s just html, in strings, in JavaScript. Lit is just a way to make custom elements easier. Man it’s gonna suck when I have to move on from my current gig and get my hands dirty with react again.
* always unnecessary
* always artificial
* only vanity
* only desired by insecure persons not familiar in the technology
* only qualified as bad idea but necessary because people were just going to do it anyways
So far the DOM has managed to escape this stupidity only because it is not a part of JavaScript. Java people ignorant of JavaScript desirous of features to make JavaScript feel more like Java has no bearing on the DOM, for example, because they are separate technologies managed by unrelated organizations.
None of the ergonomic reasoning mentioned in the article are qualified. Just because many people lack confidence in the technology and knowingly make poor design decisions doesn’t mean a familiar vanity layer will fix anything. Declarative comfort, for example, is not a resolution to performance and security problems just because other knowingly bad design decisions are worse. Two wrongs don’t make a right.
Furthermore the DOM already has a slow unnecessary declarative abstraction layer insecure people cannot live without called querySelectors. In other words this proposal is to React as querySelectors are to jquery, and classes are to Java. These are/were trends and trends die over time. We really should move past vanity as an alternative to an absence of training.
What exactly is the problem with having the higher levels of web development supported through libraries (React, Vue etc) rather than directly in the browser? Why does this need to happen?
> Developers need to reach for a library, and thus tools like npm or a CDN, to do many basic things. This adds to the overhead of getting started. It makes simple static files and devtools less useful than they could be. There's no fundamental templating knowledge that's portable between stacks, and native DOM creation APIs like innerHTML are unsafe by default.
Remember when you could just drag an html file into your browser, and it would work? No build step, no package install, no web server, just vanilla html+css+javascript?
It would be nice to get to do that again, and the more we move things like .querySelector out of libraries like jQuery and into native browser APIs the better, imo.
That should ideally be the highest calling of frameworks like Lit and packages like Lodash - to be so good that they prove indispensable, and ultimately go native.
Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop. Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is…
The article fails to accept that performance and security aren’t addressed by vanity layers. This is a mistake repeated by web technologies when popular demand eventually crushes common sense, because hiring is more important than training/maintenance when the lowest levels of the work force can’t tell the difference and drives all design decisions.
If you want better performance or security you have to measure things, not wear a pretty dress and look the other way.
The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible. I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one. But these abstractions have a huge mental / implementation cost. The problem, as with most engineering things is a tradeoff problem. The r…
> The react model - where you just update the global state and re-render everything - is slower but easier on the brain. The signals model is faster, but so much effort. there are multiple frameworks now that do fine-grained diffing without relying on signals, proxies, or any other reactive primitives. they basically have the top-down react model but much faster and without the weird concepts like hooks and manual/wa…
One of the most useful features that could make a lot of incremental computation problems easier is "value types"[1], but unfortunately it seems that isn't going to happen anytime soon. The biggest constraint when developing an efficient UI framework with good DX is JavaScript. Also, it would be nice to have `Node.prototype.insertAfter()` :)
I would argue that the proliferation of frontend frameworks is evidence is that we -don't- know what the optimal abstraction is for building frontend applications. We're all still trying to figure that out. Just look at what happened with Web Components. It didn't take over or become the foundation of everyone's software. It just became yet another competitor [0]. I wish the standards committees would focus their eff…
The part about Signals is telling and illustrates well why the idea while laudable is practically unfeasible. I get why OP likes signals. In every large enough project there is a half baked implementation of a DAG calc tree and it makes sense that a language could standardize one. But these abstractions have a huge mental / implementation cost. The problem, as with most engineering things is a tradeoff problem. The r…
I would gladly take easier on our hardware, bandwidth and planet even if a bit harder on the developers' brains. (as a developer).
> Most apps out there don’t need to be crazy fast
I wish we recognized that we need apps to be lean.
> and people will choose react because it’s just simpler.
I think you are right, and I dislike React for this.
Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. Is why dreamweaver and such was so successful back in the day. And why so many designers learn with tools like photoshop. Also hard not to feel like this is reaching hard to try and recreate xslt. :( It is…
> Also hard not to feel like this is reaching hard to try and recreate xslt. I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the ecosystem. And it's still widely supported in browsers! It was such a shame that XML caught on where it sucked--configuration, IPC, etc--but languished where it shined, as a markup language with an amazing transformation capability in XSLT. I think where XSLT fell…
I choose to look at this a little differently.
An XML application using XSLT is so much better (faster load times, faster to write, easier to make correct) than a JavaScript application with a JSON api, that XML is basically a secret weapon.
I only care enough that it stays in browsers, but otherwise I'd prefer nobody know about it because it means less competition on things that matter (faster load times, faster to write, fewer bugs, etc). And I've got a half-baked JavaScript-based "renderer" I can finish in case some Google VP asshat goes looking for things to delete...