TLDR: This post is made to rave about repo I found called json-schema-form-element a lit-based component library for form generation that works wi...
For further actions, you may consider blocking this person and/or reporting abuse
In 2006 I bet on jQuery to be the future of the Web
And then the browser vendors implemented things like
querySelectorIN the Browser...So what happens when Apple, Mozilla and Microsoft do not implement Google Lit syntax into the Web Component standard?
Those 4 might be working together in the WHATWG; but they are still competitors. And I presume none will let Chromium grab 100% Browser market share (We would all be stuck on AMP now)
In jQuery days there were some 20 alternatives. I have worked at 2 companies where they bet on the wrong horse.. and had to ditch 1/2 million euros.
There are 60+ Alternatives to Lit; have you tried them all?
I picked up jQuery at the same time. Even though browsers implemented a lot of ideas and JS itself also adopted ideas, there's no doubt jQuery made it much easier to develop sites.
I think Lit is also the winner in the long term because it leverages web components, which are also being built into the browser. Over time you might not need Lit, but everything you've picked up and learnt will still be relevant.
I'm observing that companies like Adobe and Microsoft are increasingly adopting Lit, which challenges React's dominance. While jQuery remains prevalent, Lit is likely to persist similarly.
The paramount concern is SSR (Server-Side Rendering). Until there's a native web component-to-string browser API that runtimes—and ideally other languages—can utilize, we're in a standstill. I doubt native browsers will prioritize server needs, particularly SSR/SSG. There might always be a need for third-party intervention to bridge this gap.
I'm receptive to any web component libraries or frameworks supporting SSR/SSG or "HTML stringification" (and ideally hydration).
Comparing jQuery to Lit isn't accurate. The web is gravitating towards servers. For evidence, consider what Next.js/Vercel has achieved with React.js. The way forward appears to hinge on a web standard, and currently, web components are our best bet and it's up to libraries like jQuery and Lit to invent what the APIs and interfaces should look like and pave the way for standardization.
SSRG isn't something new.
The Internet is on a 15 year cycle favoring Servers versus Clients.
30 years ago I did Gopher, 15 years ago SharePoint
I didn't say it's new I said getting browsers to care about it is.
SSR is a minor issue, has been done for over 30 years, just needs to be implemented.
The WHATWG recently started discussing about Web Component persistence between browser sessions.
That is a biggie.
Thoughts?
Tomas well done !!
Thanks for your kind words @reggi ☺️ Just found out your article after an unrelated Google search (about Lit SSR, for Gracile).
I'm happy that this project gave you more confidence in the interoperable web.
One of the main block I see right now is the ability for React to distinguish between attributes and properties. Actually, the lines are blurred, and consumers lack flexibility.
Solid, with its namespaced prop:/attr:/on:/… has the nicest approach to keep Custom Elements declarative in JSX, e.g. accessing their internal events, etc.
Thanks for the link to jsfe.js.org/ - I'm going to add it on my experimental stack:
I feel Web Components and html are ways to make things lighter, not bulkier (I never wanted to dive in react / vue / angular and the like and spend months, if not years, learning them).