Adapt a new frontend framework for ARCsoft - SolidJS
Last updated: 2025-04-24
Archie ToARCsoft recently decided to add SolidJS as a new frontend framework to their tech stacks. We have implemented SolidJS on several projects and the results have been promising. In this article, we’ll explore why we needed a frontend framework and what SolidJS offers as a solution.
A need for client-side rendering
Some background - CSR vs SSR
First, let’s define client-side rendering (CSR) vs server-side rendering (SSR):
- CSR: In short, your website is rendered on the browser. The server returns an HTML file, which in many cases, is a body containing only a simple
div
tag. Your browser runs the JavaScript, which fetches the data and builds the webpage dynamically. - SSR: The server does all the heaving lifting. It gets the data from the database, builds the HTML, plugs the data into the right places, and sends the HTML to the client.
For simplicity, think about CSR as a shop that sends you ingredients for a meal then you have to cook for yourself, while SSR is like a restaurant that sends you a ready-made meal.
A need for a CSR frontend framework at ARCsoft
We at ARCsoft have always used Django for our applications. And don’t get me wrong, Django is awesome. It’s a robust web framework with most features you need. Unfortunately, one of the missing features is CSR. Django does SSR for all of its templates. The only way to do CSR is to write huge JavaScript files. However, who’d like to debug 2000 lines of vanilla JavaScript, or even jQuery?
You might ask: “What’s wrong with SSR?”. Well, SSR is pretty cool actually, except that the server would have to take on a huge processing load when your user base is massive. Say if you app has 100,000 users (congrats by the way, that’s quite an achievement), the server would have to fetch the data from the database, render the HTML dynamically and send it to the client for every single request made by every single one of those users. CSR helps remove the second step, dynamically rendering the HTML, and takes that load off of the server. I don’t know how many operations are involved in that step so let’s call it x. For 100,000 users, that would be x times 100,000 operations saved. That would immediately benefit ARCsoft in two ways:
- Faster server responses, as the server doesn’t have to handle as many processes.
- Lower resource consumption (memory, CPU, bandwidth, etc) which may or may not translate to money.
SolidJS Introduction
After some dedicated research made by our awesome team members as documented here, we’ve decided to pick SolidJS.
I can’t explain SolidJS any better than this Solid in 100 Seconds video, though I can try for those of you who are familiar with React. SolidJS is like React, except that it updates the real DOM instead of the virtual DOM. It’s lighter and faster, executes in order, and it doesn’t require hacks to make some features work. If SolidJS gets more attention from the dev community, React’d better be concerned about getting fired from corporations.
So why did we choose SolidJS? If you have a look at the Gilab discussion I linked above, you’d see that we were also considering different options at the time: Svelte, React, Angular and Vue.
- Angular 2.0 only supports TypeScript so we crossed it out since we weren’t sure if we were ready to write fully TypeScript code yet.
- Vue got some attention but didn’t stand out so we just pretty much ignored it
- React had a few technical issues - performance concerns for large DOMs, some footguns that most developers aren’t aware of, etc
It came down to Svelte and SolidJS. And I decided to go with SolidJS mostly because I was into JSX and wasn’t a big fan of Svelte templating system. I found out later that many others dislike it too.
Benefits of SolidJS
Beside adding CSR to the mix, SolidJS also brings about some benefits, compared to the good old vanilla JavaScript and jQuery:
1. Component’s separation of concern and reusability
So for example, if you have a card component that displays a user’s name and age as follows:
export default function UserCard(name, age) {
return (
<div class="card">
<h1>{name}</h1>
<p>Age: {age}</p>
</div>
)
}
The code that renders the card is totally separated from other codes because it is defined within a function. Now, you can import this component and reuse it everywhere you like.
import UserCard from "./path/to/UserCard.jsx"
export default function App() {
return (
<main>
<h1>Welcome to My App</h1>
<UserCard name="John Doe" age="30"/>
</main>
)
}
2. AJAX / Smooth UX
A perk of CSR is an interactive and smooth UX. It allows users to submit a form and see a response right away without a bulky page reload. It allows displaying a loading screen and a placeholder skeleton while user data is being loaded the first time. Interactions like those provide instant feedbacks to users and notify them of what’s happening without causing any confusion and frustration. These small details might keep users coming back to your site.
3. Built-in features that provide a better frontend development experiment (DevEx)
Developers are just as important as users. It’s true to say that SolidJS was born to provide a superior DevEx to React. Some SolidJS notable features that I want to point out are:
- Signal: A variable that gets updated at every place that it’s used on value change.
- Effect: A function that executes on value changes for all signals used within it.
- Tonnes of easy-to-use built-in components for flow control in rendering
There are many more awesome features that you’ll find once you dive deeper into SolidJS.
Conclusion
SolidJS is awesome. Period. It has everything you need for a frontend framework. It’s really easy to learn, especially for those who already have a React background. And it’s extremely fun to write SolidJS apps due to its amazing DevEx.
There is just one drawback that I’ve felt with SolidJS after a few months working with it. Due to not being as popular as other frameworks mentioned above, there are limited online resources and 3rd-party libraries for SolidJS, though they are still growing. So if you’re not a master at debugging frontend issues yet, you might struggle a little. Or probably not, who knows?