Posted by mdhb 5 days ago
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 efforts on improving JavaScript the language. That has a much greater and more lasting return on investment.
There is no value this provides over making a tagged template function and exposing it as a library. If that library is stable with ubiquitous adoption for 5-10 years then maybe there's something to talk about.
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.
It's not. It's a custom HTML-like syntax with lots of custom and weird rules.
"Similar enough" is a far cry from "It’s just html, in strings, in JavaScript"
> anybody familiar with html and JS can pick it up
Just like JSX. But no one calls JSX "just HTML" (and in React, with rules of hooks, it's no longer "just JS"). In Solid JSX returns actual DOM nodes btw.
> it mostly just feels like building a huge html string.
Because that's what you essentially do. lit runtime parses your custom string, converts it to proper HTML, concatenates that into a string, and then dumps into the document with innerHTML (it does set up data bindings etc. , so it's more than just thay of course)
Now you have to find a way for javascript to interact with your template language.
While functions are sufficient. That doesn't look like orthogonal language design.
One reason why things like this have never happened before is because the people who need this are only barely capable of working with HTML. The DOM supports a wide variety of technologies far outside and unrelated to HTML.
There are no parts of DOM APIs that are functional. It's all 90s-era Java OOP-style.
DOM API is 90-s era OOP
setHTML() is already implemented in Chrome/Edge and Firefox so this point is a bit outdated - there is a safe alternative to innerHTML.
> 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.
The answer to this is both "never gonna happen" and "you already can."
You already can ship a React app in pure JS and even import modules via ESM in the browser from CDN. Performance will suck but you can.
You'll never be able to actually have a complex web app that you can just drag into the browser. As the base API expands, so do the ambitions.
Heck we've had PHP 4 years after HTML just to fill in some blanks, people will always want more than static code.
XUL was beastly back then though.
Out of curiosity, what does that app do to convince people to jump through such hoops? Would you mind sending a link to it?
There are still 3 companies that use it (since 2008), so their employees don't have a choice really. The app does a lot, so to stop using it the companies would need to hire and migrate to 3-4 other services. I reckon SAP and the kind could do everything as well, but these companies are too small for that.
There isn't a website or anything anymore for me to show, and I haven't been involved in it for over 10 years.
https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...
Good old time.
I didn't understand this part, can anyone shed light? What is different between what's being described here and what React does with event listeners, etc?
https://react.dev/reference/react-dom/components/common#reac...
We can nitpick this point because react has had a ref API for at least 5 years now. Given a ref, all DOM API are available. For events, SyntheticEvent will refer to a native event if it exists.
The SyntheticEvent abstracts vendor discrepancy. Under the hood, react can apply some optimization too.
https://legacy.reactjs.org/docs/events.html https://react.dev/reference/react-dom/components/common#reac...
It's like creating regulations which require a specific solution before that solution exists.