We dropped the idea to convert React App to Sveltekit.

Our team of three developers have been creating apps using React since 2018. While we were aware of Svelte’s potential, it was still in its infancy. However, we kept Svelte in mind due to its promising founding principles. When Sveltekit was launched in December 2022, we decided to give it a try. Our plan was to pick one of the simpler web apps we have in production and rewrite it using Sveltekit. The app we were trying to re-write was an appointment booking app. This app needed to have basic form components like DatePicker/AutoComplete/Select etc. After a week of development work/discussions, we realized what Svelte offered was not worth the re-write effort.

Why Svelte/Sveltekit?

• Svelte’s core principles are robust. Opting for optimization during compilation rather than runtime, and sending minimal code to the user, are logical choices.
• Ability to accomplish tasks with less code. For e.g. ability to bind values
• If you’re used to working with HTML and vanilla JavaScript, looking at a Svelte file will feel familiar and easy to understand. Even though there are complicated things happening behind the scenes, Svelte makes it easy for you to work with the code without having to worry about the details.
• The documentation is excellent and the tutorials are world class. Other libraries should take a cue on how to onboard developers.

Why we dropped the idea?

1. Missing mature component library and packages

Svelte Ecosystem is not mature yet as compared to the React one. Material UI is one of best component libraries in React. There are other excellent alternatives available as well. We explored a few component libraries in Svelte: SMUI, Carbon Components, Flowbite and Attractions. Some of these libraries are still being actively developed or no longer maintained. The components they provide are not as customisable as MUI or other equivalent React component libraries. We realized that once you go deep into MUI, finding other component library equivalent to that is a failed exercise.

Some of the basic components are missing in these libraries. Components like Autocomplete, Date/Time Picker, Select are not present or customizable enough. Couple of features we used in our booking app were autocomplete and datepicker. The autocomplete was missing in most of the svelte libraries. The feature to disable certain dates in Datepicker was missing in most libraries.

We could not find a decent datepicker specific packages either. Most of the packages we were coming across were no longer being maintained.

We decided to build these components ourselves but as a product developer, we would prefer spending time building features for the end user. If we had to spend time building components just to accomplish features already present in our production stack, we as a team felt it was not the right use of our time.

2. Inability to define multiple/inline components in a file

We could not write components inline like we used to in React. In order to accomplish passing a component as prop, you need to create a .svelte file and import that Component and use the <svelte:component> directive. Adding more files in the project just to house basic inline components seemed like an overkill and complicated the project structure.

// You cannot do the below in Svelte
<ListGroupItem renderInput={({ text }) => <div>{text}</div>} />

// To Accomplish the same, you need to create a svelte file
import CustomComponent from 'CustomComponent.svelte';
<ListGroupItem renderInput={CustomComponent} />
// ListGroupItem has a line <svelte:component {props} this={renderInput} />

3. The nomenclature Sveltekit expects for routing

Even for a simple app, as we added more routes, things started to look messy in the directory structure. Every routing folder has a +page.svelte file or a +layout.svelte file or both. It starts to get confusing when trying to find the right +layout.svelte file or when working with multiple files in an editor.

We probably would have gotten used to points 2 and 3 had we stayed with Sveltekit for a longer duration :)

Conclusion

After a week of coding in Sveltekit/Svelte, we as a team concluded that replacing our stable production app written in (React+actual product code) with (Sveltekit+Custom code written just to support components+actual product code) did not make sense for us. We could have fought our way to production but replacing production grade react components with custom svelte components that are not battle tested was not worth the effort.

It felt that we were a little early in our journey with Sveltekit. Even when developing a relatively straightforward app, we found the Svelte ecosystem lacking (No offense to the Svelte community. We think they are doing awesome work. Building an ecosystem takes time) We couldn’t even begin to imagine how much time and effort it would take to migrate more complex applications.

We concluded that we could use Sveltekit when:

1. We are starting a new project when there is flexibility in terms of what components to use or tweaking the designs to match to Svelte component library.
2. Svelte as an ecosystem matures enough that you can find decent packages for many use cases like we do in React today