Alpine.js is worth a look as well [1]. I've been working with it as part of the newly christened "PETAL stack" [2] of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView.
> "PETAL stack" of Phoenix, Elixir, Tailwind, Alpine.js, and LiveView
Oh, finally a hipster stack after my own heart. My initial stack used Web Components instead of Alpine.js, but after one year trying to make it work (using lit-element) I'm battered, bruised and I declare Web Components a failed piece of technology [1].
Alpine is interesting, but not powerful enough for my use case, which is encapsulating common UI behaviours in reusable packages. Stimulus seem to be the missing ingredient in the mix for me. Any other suggestion for lightweight rich JS components that do not require one to buy into Vue, React or other "full-stack" JS libraries?
Also, I wholeheartedly recommend Unpoly as well, fits nicely in the PETAL stack.
1: shadow DOM isn't great on your OWN components, styling isn't fun paired with global CSS/tailwind, dealing with properties/attributes/observables/reactivity in general is an absolute pain in the buttocks, good luck wrapping an <input> in a web component.
> Any other suggestion for lightweight rich JS components that do not require one to buy into Vue, React or other "full-stack" JS libraries?
Depending on your needs, you can sort of use Alpine + server-side templating to achieve this. While Alpine itself has no concept of components, you can define a template fragment that consists solely of the “component” for basically the same effect. Because the x-data directive is freshly evaluated each time it appears, you can include a fragment multiple times and get isolated “instances”.
YMMV though, I eventually found that because templating is much more simplistic than a real tree of components as you would get with Vue or React, things started getting hard to follow, especially when my “components” were nested, or involved approximating slots.
Ultimately I converted to Inertia.js, which is a very small glue library that lets me write the whole front end in Vue (or React, or Svelte) while keeping a more traditional Laravel (or Rails) backend.
Shadow dom is optional for web components, web components are still useful without it, so I hardly see how that could be a reason for "failed piece of technology".
Also, did you try with pure JS ? no lit ? I just removed StencilJS from my component to go pure-JS and it turns out I really prefer it that way, maybe it would suit you too to do WC without any additional JS lib ?
lit-element is a very light wrapper on top of the native API. The problem isn't lit-element, the problem is the native API is not that good, not ergonomic, still incomplete and so far removed from the modern way of building reactive websites, i.e. view = render(state)
You need some abstraction on top of the native API, working directly with it is even more painful. The fact I'm using lit-element is because many WC libraries force shadom DOM upon you, and only some make it optional (Stencil is one of those few, but the TS requirement is a no-go for my use case)
Not the OP, but slots are part of the shadow DOM spec, so if you don’t want isolated styles, you have to forego slots.
I tend to build my app scaffolding with wrapper components that provide layout and/or functionality to their child components via slots, so as much as I like the idea of WebComponents they’re a complete non-starter for me.
In the above stack LiveView doesn’t play that well with web components that render their own children, as it will remove those children when it rerenders. So you do kind of need shadow DOM.
React is great if all your frontend is React. Using it to create reusable components to sprinkle in your static HTML is overkill, and anyway it does not work with LiveView and LiveView is pretty cool.
IMO React has a good data model and solid foundation, but the whole ecosystem it's relying upon is bad. I'm not a fan.
Sure, but where is your data and business logic going to live? If the answer is "just write it in JS" then it's no longer a question of "just use React" but "let's replace our entire stack with Javascript".
Ya it really depends. I like redis and Postgres generally speaking for data, and Ruby on Rails generally for business logic. And you can certainly do universal rendering with that easily with react_on_rails. If you do end up needing more perf, maybe go would be interesting.
Yes but we're still going a long way from "just use React". One benefit of the "JS sprinkles" approach of Turbolinks+Stimulus is that you have a far simpler and more productive stack: Rails (or other framework) renders templates with some minimal JS on the frontend, as opposed to the inherent complexity of API + SSR + SPA. There are occasions when React is a good choice of course, but let's not underestimate the costs of the SPA architecture.
Why would the entire stack be JS? Even in server side React, it can still fetch from APIs, so presumably you have a backend to fetch from, in whatever language and database you want.
yup, and if you want to really optimize it you could use functions as a service like lambda as your react rendering layer, which forwards to heroku or fargate or beanstalk or vanilla ec2 or whatever for your backend.
and if cloudflare workers ever support metered usage you could use that too for the react layer.
and if you want hyper performance you could use lambda@edge and intelligently route to your backend running on fly.io to minimize the distance. the somewhat unsolved problem there though is multi region master master replicated databases which are cost effective.
I thought you were making joke about complexity when I read the first line, but then in the end it's not a joke. Why don't you have 1 single backend peacefully. JS sprinkles for what it needs to be interactive. (I'm tired of "complex form " argument, jQuery turned out ok back then, so does Stimulus or whatever works with server rendered html (e.g. vue))
This sounds like madness. Not cost effective to deploy, nor cost effective at all to implement in the first place. It's literally setting money on fire.
What's the equivalent of Poe's law, but for software development?
I've also been playing with Alpine, but on the also-newly-christened "TALL stack" [1] of Tailwind, Alpine.js, Laravel, and LiveWire. It's also worth a look.
I was thinking that Alpine here was referring to Alpine Linux, which I found strange in the context because often these sorts of acronyms (LAMP, MEAN, etc etc) don’t mention specific distros and I also would not expect CSS-Tricks.com to write about Linux distros. But the answer of course was that it’s not Alpine Linux, it’s something called Alpine.js.
[1] https://css-tricks.com/alpine-js-the-javascript-framework-th...
[2] https://thinkingelixir.com/podcast-episodes/021-tailwind-css...