loading...

re: The Cost of Investing Too Heavily in a JavaScript Framework VIEW POST

FULL DISCUSSION
 

I recently started a new job that was looking to begin building a universal design system of UI components. In the past, building a system locked into a framework end in crippling technical debt and problems. Sometimes, we were completely blocked from upgrading to new and needed features, because the expense and breaking changes to our supported applications was simply too costly.

With all of that in mind, I did a bit of digging this time, trying to find an answer to this costly problem. LitElement was promising but required more integration that I'd like. (For instance, getting litElement into a WebForms app...oh goodie).

Ultimately, we decided on Svelte for our org's component design system because we can distribute compiled javascript packages that expose a simple API for other apps, stacks, and teams to consume. It certainly requires some technical hurdles to distribute, but the payoff is huge, as we can incrementally update, change, or upgrade components (bulk or individually) and push them out to consumers. And, because they are compiled to straight-up javascript, the other teams require no dependencies, other than some basic configurations.

Plus, Svelte's architecture is very simple and straightforward. You get a lot out of the box, and it doesn't require a huge amount of overhead to get going with. Of course there are weaknesses to this approach, as all things have trade-offs. It's all a bit more bleeding edge than I am typically comfortable with. We have already started to compile a list of best practices, and things to avoid. But because Svelte's components are compiled, what is delivered is technically framework agnostic.

Thus far, we are pretty happy with this choice, but are still early on in the journey. I'm not a Svelte pitch-man, but it has helped to answer this difficult question for now. I'd love to hear if anyone else is moving in this direction.

Code of Conduct Report abuse