SvelteKit has been my go-to frontend framework for the past few years. It was a breath of fresh air from React land, providing a simpler more streamlined experience (esp wrt routing, templating, and data management).

But I never felt it was the right tool for building a full stack app - I'm not much of a Node-lover myself and JS just never felt stable enough for my core logic. So usually I built apps with a dual-Monolith architecture with SvelteKit on the frontend and F# on the backend handling the majority of my app logic.

Old CloudSeed Architecture with SvelteKit frontend

Over time I formalized this into a project boilerplate that made it easy for me to spin up projects with my favorite stack. That boilerplate is called CloudSeed.

With the recent resurgence of server-side rendering paradigms, empowered by tools like HTMX and Alpine, I began to wonder anew whether this was actually the best stack for me. So I did some experimenting. Ultimately I decided it wasn't and have been migrating my frontends over to F# - starting with my website and now migrating CloudSeed, my F# project boilerplate.

In the rest of this post we'll explore why I decided to move from SvelteKit to F#:

Q: Why did I decide to move from SvelteKit to F#?

Answer

Ultimately a pure F# codebase led to numerous wins all stemming from the simple fact that it's simpler. Simpler to build, simpler to scale, and simpler to maintain long-term.

As I'm in the business of building (and then writing about it) this simplicity leads to a better fit for my projects and my life.

New CloudSeed Architecture - Pure F#

In the rest of this post we'll explore this decision from several different perspectives:

• Simplicity
• Scalability
• Flexibility

Simplicity

F# is my favorite language and has been the core part of my tech stack for several years. The move from SvelteKit to F# makes it an even bigger part of that stack.

1 is simpler than 2. While SvelteKit is an excellent frontend framework (and way better than React imo) and I love TypeScript (it's my 2nd fave language) they're just not F#. Regardless of how good each choice is for their respective jobs, together (in my dual-Monolith architecture) they are 2 things. 2 things simply has more overhead than 1 - in terms of context switching between languages, integration work between technologies, and system designs you have to keep track of. Thus a move from SvelteKit + F# to just F# is just simpler.

Frontend with F# is good actually. For a long time I stayed away from F# frontend because it felt old and crufty. To some extent it is - server-side HTML hasn't really changed much since the old enterprisey days. But if you're into the more html-y style of templating (which is the approach SvelteKit, liquid, handlebars, etc go with) then it's not much of a jump to simply use templating libraries / building your own raw string HTML in F#. This won't get you super fancy client-side interactions but if you're building simple CRUD apps (which I mostly build and honestly most businesses build) then even these older, "slower" feeling HTML pages work pretty well and are incredibly easy to build.

The new unlock for me has been diving into the world of HTMX where we can actually upgrade our "old" HTML pages to be more interactive - getting most of the benefits of these clientside frameworks with almost none of the bloat (read: 80/20). It enables you to empower your HTML so that you can choose to rerender only parts of your HTML pages - which makes them go from feeling old and slow to new and fast.

Scalability

At my scale (small), scalability in terms of performance isn't that important. But I like to keep it in mind to ensure I'm not shooting myself in the foot later. When we focus on building Simple Scalable Systems (3S), we can typically find a solution that works well for each of these principles.

Less work means faster completion. F# is faster than TypeScript. Even if it wasn't, moving from a 2 Monolith system to a 1 Monolith system removes an entire IO hop which makes the architecture faster. So it should be no surprise that my F# sites run faster than my SvelteKit sites (though SvelteKit does have a lot of neato tricks which make it competitive). My apps never reach a scale that performance is a bottleneck so this doesn't really matter but it does make me feel good.

Less work means faster completion. So if performance isn't the bottleneck, what is? For most apps it's time to build. In almost all cases the bottleneck is how fast we can build / maintain the app, not how fast the app actually runs. By improving the Simplicity of my tech stack, I've found my own productivity skyrocket. Scalability is often about solving for bottlenecks, in this case it was me. I'm the problem, it's me.

Flexibility

Simple Systems are more Scalable to more usecases. I like building Simple Scalable Systems (3S). It's part of my personal motto - 1% better via 3S. The reason I like 3S is it's the only paradigm I've seen that seems to be a silver bullet for most cases. The simpler your systems are and the more robustly they're built, the more useful they are for composing together to build high quality systems for various sizes and purposes. It's not the best choice in 100% of cases but it's a competitive choice in 90% and that's good enough for me.

What I'm looking for in a project boilerplate like CloudSeed is to make my life easier. What I like to do is build things. So my goal is to build that thing as easily and robustly as possible so that I can test it, iterate on it, and / or move to the next thing (I'm a big fan of the Cult of Done).

I think it's pretty clear that moving from SvelteKit + F# to just F# makes this a more appealing solution for this usecase. If we were trying to sell CloudSeed (a good thought exercise for finding gaps in your solution) this becomes apparent:

• F# + SvelteKit - I'd need to convince someone to try both F# and SvelteKit, both niche technologies. Selling them on one is hard enough but to sell them on both at the same time? Next to impossible.
• F# - The market is still small but it's much larger than the intersection of F# and SvelteKit.

Next

I've been having a great time building and experimenting with F#. It's a great language that I think is tragically underhyped. I'll keep building with it until it dies / something better finally comes along.

If you're looking to get started with F#, you might be interested in:

• Migrating my sites from SvelteKit to F#
• Build a simple F# web API with Giraffe
• Build a Simple Markdown Blog with F# / Giraffe

And if you're looking for a simple, scalable project boilerplate to kick off your next F# app - might I suggest CloudSeed?