Videos
Development - Where the Plan is Put Into Place
Why Switch?
For the past six years, RedSky Engineering has been a strong advocate and implementer of the React library, with over 90% of our projects utilizing React. Throughout this period, we have created a wide variety of projects, ranging from live video e-commerce apps to 3D mapping websites similar to Google Earth, and even self-driving lawn mower applications bundled using Cordova/PhoneGap. The common thread in all these applications is the use of the ReactJS library.
Initial Experiments with Other Technologies
Before settling on ReactJS, we experimented with several other technologies. For instance, we built jQuery-based websites with index.html files exceeding 3,000 lines. We also explored Framework 7, which allowed us to mimic iOS and Android native controls in conjunction with Apache Cordova, making the apps feel just like native ones. However, when we were first introduced to class-based ReactJS and its componentization structure, it was clear that this approach provided a much better way to organize our code and eliminate the cumbersome, large index.html files that had been a challenge for larger projects. Additionally, Framework 7 offered an equivalent component library with a router already bundled into React, making the transition even smoother.
Unfortunately, we found that using a framework became problematic when we started attempting to code scenarios that the original library authors never intended. We spent countless hours trying different workarounds, often having to abandon them or fork the library to add customizations that never made it back to the main branch. It became so problematic that we vowed to build everything in-house from then on.
Building In-House Solutions
Thus, we built our own web router library, ignoring the existence of react-router. We also developed our own framework UI library, humorously named Framework 996 (in reference to the Chinese working hour system of 9 a.m. to 9 p.m., 6 days a week). All our components included Storybook examples. The great thing about React was that it was simply a library and didn’t impose any restrictions on how we did things.
Up to this point, we had built mostly web or mobile applications that relied little on SEO optimization or page rank. When we encountered our first project where SEO mattered—with OpenGraph tags, JSON-LD, meta descriptions, and dynamic content from CMS integration—we ran into the challenges of using only client-side rendering with React. While Google and Bing typically render these pages before indexing, this wasn’t the case for other popular sites and systems like Slack, Facebook, LinkedIn, etc.
We tried using prerender.io to render and statically cache the page for these crawlers, but it seemed fragile and didn’t provide the ultimate solution we were looking for. At the same time, people were raving about Next.js and its capabilities, including server-side rendering with client-side hydration, static site generation, and more.
Exploring Next.js
We created a sample application to try out Next.js as a potential replacement for our homebrewed solution. At this time, Next.js had just released version 13 with a whole new App router system, including files and folders to store pages and routes. It sounded intriguing, but the experience was less than stellar. The system, in our opinion, and from what I’ve read from many others, was not ready for prime time. While it has improved since then, there are still many negative comments and lots of people choosing to stick with the old page router system.
Transitioning to Svelte
Around the same time, a former co-worker suggested that we try out Svelte, as he had found it to be a dream and extremely easy to get up and running. Just like with Next.js, we created a sample application in Svelte (technically SvelteKit) and found it to be an all-around positive experience. We enjoyed being able to write less code than our react counterpart. We found things were simple to understand and easy to work with. For example the two way binding present on input forms made it so much nicer than having an onChange() handler with a setState() method. The stores that Svelte by default provided gave us the state management reactivity throughout our app without having to reach for third party libraries like Recoil or Zustand.
We soon faced a crossroads. We had a new application that needed to be developed for a customer within a short timeframe, requiring deployment on Web, iOS, and Android simultaneously with a small team. We could either stick to our tried-and-true homebrewed ReactJS system or take a leap of faith and try something brand new with Svelte.
In the end, we chose Svelte/SvelteKit. In addition to leveraging SvelteKit, we decided to use some of the other popular ecosystems being praised by YouTubers, such as TailwindCSS, ShadCN (Svelte edition), and Superforms. All of these proved to be fantastic libraries created by authors who take pride in their work. We have since donated money to these projects, contributed to issue tickets, and participated in Discord discussions whenever possible.
We recently completed the project and have significantly grown our in-house Svelte knowledgebase in the process. While this mobile application relied on a Node.js backend, we also completed another project that utilized the backend capabilities of SvelteKit using the node-adapter deployment. Having both the frontend and backend in a single Svelte codebase has provided an excellent developer experience. I believe we will continue down this path for small to medium projects. Large projects or those that require websockets will likely still be divided between a SvelteKit frontend and a Node.js backend for the time being.
TLDR;
Pros:
- Server-Side Rendering: We have found a solution to the server-side rendering issues we faced with React alone. While Next.js could have addressed this, the complexity added by server-side components versus client-side components was not ideal.
- Community Support: The Svelte community has been amazing, especially the Discord channels.
- Efficiency: We generally write about 30% less code.
- Ease of Use: Even without much experience in Svelte, we find that things just work with little hassle.
- Layout System: The layout system in SvelteKit is an excellent way to think about breaking up common code elements.
Cons:
- Ecosystem Size: The Svelte ecosystem is not as extensive as React’s, but we have been able to find almost any library we need since integrating vanilla JS is straightforward.
- Versioning: When RedSky started the Edify Sports App in December 2023, Svelte 5 seemed to be on the verge of release, but we decided to stick with Svelte 4. With Svelte 5 still in Release Candidate mode, it was a good call, but we are eager to upgrade once it's released.
- Client Assurance: We often need to reassure clients that Svelte is a production-ready framework, as many have only heard of React.
- Training: Most job applicants and new hires have never heard of Svelte, so we go through a training period. By the end of the first week, almost all new hires are ready to ditch their old personal projects using other frameworks.
In a future blog, I will discuss the specifics of how we achieved fast performance and bundled our project into an iOS/Android application using CapacitorJs, along with simultaneous deployment to a web server.
