DEV Community

loading...

Discussion on: Why I moved from React to Svelte and others will follow

Collapse
mikenikles profile image
Mike Nikles Author

Hi Luciano,

Thank you for taking the time to provide your feedback.

In a scenario where a web app's design is based on MaterialUI, I agree that using an existing component library is the best and most efficient approach. For Svelte, there's sveltematerialui.com/ as a starting point.

The use cases I encounter most often is where web apps are designed by an in-house design team and the web developers develop according to the design specifications. While there are many open source calendar components for example, they often provide features that are not needed. In my experience, this can add complexity, unnecessarily increase JS bundle and CSS file sizes and make it more complicated to add features that are unique to a business. On the flip side, developing custom components requires more testing (e.g. cross browser compatibility) so it is a bit of a balancing act on a case by case situation I'd say.

As for my comment on being too reliant on npm install: Imagine a situation with 15 frontend developers working in 3 teams. What I think tends to happen is that developers' first instinct is to search NPM for a component, install it and use it. Each component often comes with its own dependencies (both direct & transient) and sometimes developers on different teams add different npm packages to solve similar needs. This slows down the build pipeline & potentially increases the final bundle size. With good internal team communication and a share component library, this kind of duplication should be kept under control.

As with many things in tech, whether Svelte is the right decision or not depends on many factors. In my case, so far, I've had a good experience.