You can't, but as the author I can assure you that I'm very trustworthy lol
I've been thinking about a standalone version for a while, but haven't gotten around to it. You could use the vscode/codium extension and disable auto updating for a similar effect.
In my view it's the other way around. If you stick to a state machine for your app logic, you'll end up with an unintentional half built reimplementation of a general purpose programming language.
The fact these state machines aren't the mathematical constructs from CS, but "extended" versions with "context" (this is where all the actual app state goes), should be the giveaway that they aren't a sufficiently capable model for the demands of UI programming. After you add extensions for every possible need, what do you end up with?
I understand the appeal though. UI development is a complicated mess, and people want a formula to make sense of it all. I've went through several iterations of these cookie cutter patterns form MVC to MVVMC++ to flux to redux to redux-saga to immutable.js to Recoil and so on. At best these marginally improve the situation, at worst they end up adding complexity on top of the inherent mess.
At the risk of missing out on the One True Way of doing UI development, I'll pass on this latest installment. I keep open the possibility that state machines "marginally improve the situation" though.
With Vue and Pinia, one doesn't even have to bother with patterns. Frankly, I think Redux does more harm than good. Their borderline incomprehensible documentation is a testament to that.
Hi, I maintain Redux and wrote most of our docs (including our current tutorials).
Can you give some details on which parts of our docs you feel are "incomprehensible"? I'm curious which specific pages you've been looking at, and for what purpose.
We've tried to organize the docs using the "Documentation System" approach described at [0]: Tutorials for teaching step-by-step, Explanations and How-To guides for specific topics, and References for API details.
Generally we want people to go through our "Redux Essentials" tutorial [1] as the primary way to learn how to use Redux correctly. It teaches "modern Redux" patterns with Redux Toolkit as the standard way to write Redux logic (including RTK Query for handling data fetching), and React-Redux hooks in components.
I'm genuinely interested in feedback on what explanations aren't clear and how we can improve things!
Redux shines when you have an actual "app" with a large dynamic "global" client-bound state that pops up in different places and needs undo/redo (Like a video editor, Blender,etc).
And even then you preferably need some small helpers to make the experience smoother (slices from redux toolkit is a good example).
For most people doing a small CRUD pages that's just woefully overkill.
Some people are really creative at creating dozens of boolean flags with lots of possible and impossible combinations. And some don't even correspond to screen in your figma file from designer (but can actually happen due to race condition... etc). You will really want a state machine that just list every possible state and transition in that case.
I agree with you, the “extended” version of state machines with “context” is the problem with xstate. Modelling state transitions deterministically is great, but context and actions are too closely coupled to machine transitions, making it very hard to write generic or reusable state machines when you actually make use of these features. Had xstate focused on only transitions (like regular FSMs) and left context/data and actions/effects to other application-level abstractions, xstate would be widely compatible with many projects instead of requiring a heavy-duty paradigm shift in terms of how you model your application logic.
I agree that state machines alone are probably not sufficient, but they are frequently a useful way of modelling at least part of the interaction flow. Honestly they should probably be used more in all areas of programming (but they should not be used exclusively).
I think the sweet spot are state machines that don't take "context" as inputs but have richer effects in their transitions (if we're talking about Mealy Machines).
This way, the internal behavior of the machine is still deterministic and easy to reason about.
I found this tiny two lines in the erlang state machine docs that I've kept around for years because it's such a precise definition of how they need to work in practice:
"State(S) x Event(E) -> Actions (A), State(S')"
"If we are in state S and the event E occurs, we should perform the actions A and make a transition to the state S'."
The fn needs to yield both the new state and a collection of side effects of that transition that need to be handled somehow. You'll need side effects no matter what so might as well formally describe them in the SM, then handle them outside of it in a way that fits the language/framework/runtime. I think this is basically exactly what elm does and how a couple of the redux extensions work too.
While that's true, there are also limitations and gotchas of Web based UIs that make state management very complex and messy. There are layouts that you _cannot_ express (with HTML/CSS/JS) without intermediate rendering steps and the whole paradigm of separating state and representation (React etc.) falls apart very quickly.
And before anyone asks: Yes, this comes up surprisingly often. Yes, alternatives have always been explored first. Yes, I'm up to date with browser capabilities. No, you can't say "no" to these designs when you're hired specifically because you can make things work.
If you can do with an even leighter-weight client, you can try my very own https://sqliteviewer.app. It's all browser/wasm-based and works offline, but has some important shortcomings.
Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable.
It offers nothing in way of ensuring that custom elements behave like builtin HTML elements. Half the elements I've come across will break or perform no-ops when you update an attribute or set a propety after it was attached to the DOM. Nevermind detaching and reattaching to the DOM, which will break virtually all of them (including my own sad contributions to this space).
The exception to this are those built using a 3rd party library like lit-element or stenciljs, which fill in the obvious omissions of these specs. Perhaps in another 10 years, a mangled version of half of one of them can be standardized? In the meantime, each component shipping its own frontend library or inlining the same core functions over and over again does nothing in the way of interoperability. You can bundle every popular JS framework and mix their components today. The reason you don't do it then or now is bloat, not the lack of a minimally viable shared component interface.
Besides, if you're going to use a 3rd party library and associated bundler/compiler, you might as well pick a good one such as React, Vue, Svelete, Solid or even jQuery UI. Using any of these, you can design and build an entire app faster than the bikeshedding commissars from goog and aapl can agree on whether "open" or "closed" should be the default for attaching a shadow DOM (at the risk of ruining the joke: there was no agreement; the developer has to provide a value in each instance...)
I used Web Components (HTMLElement) recently and did not encounter any of these issues. I found it more snappy and reliable than frameworks like React or VueJS in terms of adding and removing components dynamically.
I did find that it provides a lot more flexibility than front end frameworks (more ways to make mistakes?) and the code was more verbose.
If I had to start a project from scratch today, I would consider going straight for Web Components.
Are you serious? Using vanilla Web Components is just god awful and I can't recommend them to anyone with a straight face. Not having had experience with "normal" web frameworks like Svelte, React or Vue.
You have to invent all your own wiring and passing of events, state-management et cetera if you go that route.
it's not that much to invent. have frameworks really made it so easy that we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects? gp says there's a performance objective, sometimes it's worth building a solution that only does what you need
edit: no one is saying a purpose-built framework needs to do everything that a mass-market framework ecosystem does. it's disingenuous to think there aren't circumstances it would make sense, not all of us make forms for a living.
> we can't bear to work with native events, manage the dom, or build reactivity with proxies or subjects
I mean, you can do all that. And either spend your time writing tons of boilerplate code, or reinventing half of those frameworks and libraries anyway.
And still having to deal with issues like having to remember that they don't participate in forms (more JS to each component), that a11y can suddenly be broken (when your label references an element inside shadow dom), that wcs are not extensible to SVGs (which is important if your field is data visualisation) etc.
I wouldn't say that you need to reinvent any framework. I was able to build a simple application using HTMLElement directly.
I just had to define a handful of utility functions to do things like escape HTML tags for user-generated content...
The main critique I can think of is that Web Components provide many ways to do things; for example, you can create elements using vanilla JS or using template strings (or even a combination of both)...
When it comes to event handlers; you can also define them using vanilla JS or inline inside the tags as part of the template string (or both).
There is no single standard way to do anything so that was the real challenge but this can easily be solved through project-based coding style guidelines. There aren't that many gotchas.
> I wouldn't say that you need to reinvent any framework.
You do, when you need at least slightly more complex.
> The main critique I can think of is that Web Components provide many ways to do things
Nope. The main critique is that Web Components is 2010s tech solidified in the platform when the rest of the world has moved on and is now exploring fine-grained reactivity and trying to remove components as a unit of work/ui. That they are 12 years in the making and still have issues that no framework has (see links here: https://news.ycombinator.com/item?id=34346269). That their design now poisons the rest of the platform that needs to add countless new workarounds for their shortcomings, and seemingly unrelated standards (like scoped CSS) now have to take them into consideration...
Well, there is not just one main critique, there are many main critiques
> There aren't that many gotchas.
Just because you haven't run into them it doesn't mean there aren't any gotchas. And there are plenty.
Hah hah. You make me laugh. Sure boss, not much. If you're doing it for fun and on your own time, okay. For real work, don't know who wants to pay you to invent your own framework.
There's also a lack of standard server-side-rendering support. From last I looked at it, some of the web component libraries have their own SSR support, but that only works with web components authored with that specific library, negating the supposed universal compatibility of web components, and they involve using heavyweight simulated DOM libraries on the server. I'm not going to bother with something that doesn't take SSR seriously when React aces that so well (especially with the newer server components support) among other things (like giving you a code model that ensures by default that updating a prop at runtime causes the same result as setting it on creation).
> faster than the bikeshedding commissars from goog and aapl can agree on whether "open" or "closed" should be the default for attaching a shadow DOM
Because very few of the people developing web standards are web developers. And of those who are very few have done anything of note in the past 20 years or more.
I got tricked into following a standard (something something about data) and had read their github issues for 2 years! Omg such a waste of time they barely ship anything. Yes, they also write mediocre (or terrible) codes. I have to stop whining I'm getting mad .. was losing my years.
In almost a decade I never understand why anyone would use Shadow DOM. What's the point of scoped style solution here. Why can't I just™ <tag adoptedstyle="style.css">styff</tag>? .. admittedly I never scope style because I never have to add 3rd party components with style in it.
One of the key goals in components is the ability to use it anywhere. Shadow DOM helps with that but also feels like a big thorn in the side for a lot of designers and developers to operate within. It makes more sense to design components this way when you're starting fresh and creating a library to be used anywhere. Controversially, I'd say it's often easier to just write CSS rules that fixes these conflicts and that the Shadow DOM is not really worth bending over for if you're designing within a controlled environment like your own product.
From the POV of a user, I consider Shadow DOM a menace, as it creates areas of the DOM that cannot be reached by CSS from outside - defeating my ability to fix UI blunders and bad design with a tailored userstyle.
I hadn't considered that at all because they're so little used, but it would be an issue if they became so. I'm using Stylus for user styles nowadays which provides an option to allow you to target the CSS within an IFRAME using
Yeah, I don't see Shadow DOM often, but there are couple sites I use that employ it - most notably Gerrit. Since I use it almost every work day, I wanted to fix a bunch of UX annoyances it has. Those fixes would've normally been trivial, but Gerrit UI has everything wrapped in multiple levels of Shadow DOM, making those fixes near-impossible instead to do in Stylus alone.
Some combination of Tampermonkey, MutationObserver and IntersectionObserver almost always gets there in the end, but despite having a default user script template with this exact skeleton it's a lot more of a pain in the arse to achieve what a simple CSS selector and some properties does in a few lines...
Exactly. And for me, that difference in PITA is the difference between fixing up websites in Stylus incrementally, spending a couple minutes for a CSS rule or three when something annoys me, vs. making a note on my TODO list to write the necessary code later, and never getting around to doing it.
Even as a 3rd party, somehow reusability here strangely is in form of unconflict instead of shared functionality. Reusable should include customizable style, headless is probably even better. I think Custom element's light DOM with Bring-Your-Own-Style is better for party interop.
>Just awful. 10 years in the making (if you can call endless bikeshedding committee meetings the "making" of anything) and still barely usable.
This seems like the norm for tech now days. A lot of meeting and work and nothing major or significant really gets done. Seems like the the whole industry is about making it easier and simpler for new developers to get develop.
Regarding React, ES should just stick and simplify E4X that would just really make all these front end lib not necessary.
I don't get this comment. I don't care if a usable web component is built with stencil, lit or not, what I care about is that I can use that same library WHETHER I'm using React, Vue, Svelte, Solid or whatever.
I've been working with webcomponents for a while. I agree that ergonomics are horrible (particularly when it comes to state management and style inheritance) but it is still better than being in a continuous churn of UI frameworks.
Unfortunately, it is the same churn that has vastly improved the ergonomics for many UI frameworks while we're stuck with the terrible workflows for authoring web components.
> but it is still better than being in a continuous churn of UI frameworks.
Is there a continuous churn?
React is 10 years this year. Vue is 9 years. Angular which feels positively ancient is 7 years (if we only count Angular 2.x).
Yes, there are newcomers like Svelte and Solid, but it's hardly a churn. Besides, they explore valuable corners that are left untouched and unexplored by other frameworks. Things like granular reactivity and removing components as a unit of UI in its entirety.
Meanwhile the "non-churn" in web components has already resulted in two deprecated standards (custom elements v0, html imports), and is rapidly churning out dozens of new standards requiring more and more javascript to paper over their egregious design (form participation, constructible stylesheets, declarative shadow dom...)
There's definitely a churn in the frameworks like React, Angular, Vue, etc. New APIs, breaking changes, etc are certainly a thing every year. But as always, this is both downside and upside: you get great features and valuable advances at the cost of such rapid changes.
The good news is that the tooling around the Web components is evolving even when the standard itself may moving at glacial pace.
> The good news is that the tooling around the Web components is evolving
You mean web components are growing their own frameworks at the same pace :) With new APIs and breaking changes
In 12 years web components had:
- original lib, polymer. Breaking changes 1.0-> 2.0, then completely deprecated
- lit is 4 years old, already had breaking changes in each version update 1.0->2.0->3.0 (and "potential breaking changes" even in patch releases), and adds new APIs with every release
- stencil is 5 years, has already had breaking changes in 1.0->2.0, but is probably the most stable of them all
etc.
Looks on par with the rest of the industry :)
The sad thing is that web components as a standard don't allow is for actual iteration of ideas. While Solid, S, Marko et al are exploring granular reactivity, web components are stuck in 2010. And all the tools around them are doing what the rest of the tools have been doing for the DOM since time immemorial: invent new, better ways that are only hampered by the underlying platform.
This is wrong on so many levels :-) As of now, React is probably the only major frontend framework that doesn't interop well with web components, requiring various hacks for doing so. Proper support is hopefully coming in version 19. What you have with React is its own, React-specific way of encapsulating parts of UI into stateful functions that helps to think about them as components.
And to have web components support built-in would mean to have them in the browser anyway, not in a third-party library.
I've once built a vscode extension. I didn't expect much, but was still suprised at the complete lack of feedback, reviews, etc. despite many downloads. One day I've added a popup asking for reviews. Virtually all my reviews come from the period I've left it up. My takeaway was, letting people know what to do goes a long way.
No sure if I’m missing something, but you can tap directly into the readable stream of fetch which should be at least as good as progress events? I’ve used it here (https://sqliteviewer.app/, click “load a sample”) and it works as expected.
Sounds like a service worker, for which there's only one active at a time for all tabs (and can communicate with them) could help with your client side issues.
I've been thinking about a standalone version for a while, but haven't gotten around to it. You could use the vscode/codium extension and disable auto updating for a similar effect.