Thoughts on Svelte(Kit), one year and 3B requests later
claudioholanda.ch
claudioholanda.ch
I felt like fighting this fight alone for years in the golden years of node, webpack and react where everybody was creating crazy stacks and adding GraphQL and so on, to basically get what Django + jquery did 10 years ago in a tenth of the time and code.
So far I also survived:
- xml is the future
- let's use nosql for all the things
- you must use the same language at the back and front
- yes, you site must have an AMP version (ah, you forgot this one, didn't you? It was sooo imporant, and then pouf, it was gone like tear in the rain)
- yes, your home page must be an SPA
- you can't code anything without async
- you can't live without a message queue
- everything must become a micro service
- of course you need a container for that
- of course you need a orchestrator to organize those containers
- of course you need the cloud, it would be crazy to deal with those containers and orchestrators yourself
- dude, why do you have a server? Use a serveless backend!
- dude, why do you have a backend? Just call saas from the edge!
Every year, some generation of engineers have to learn the concepts of "there is no silver bullet", "use the right tech for the right problem", "your are not google", "rewriting a codebase every 2 years is not a good business decision", "things cost money".
When you have that experience, you subsequently apply for jobs that demand you be up-to-your-elbows in the over-hyped and over-marketed tech.
The industry, eagerly lapping up any and all shiny-marketing and advocacy, financially incentivises bandwagon-jumping over listening to experience.
It was completely unnecessary, and most importantly, cost the industry a fortune. If you are older, you have been wondering why you need to work more to achieve less. To me this has been demoralizing, and actually put me through some tough cycles of depression. I no longer enjoy this job. I used to DO things and walk away from my desk every day having a sense of achievement. Now it takes 3 days to set up your microservices locally just to reproduce a bug, apparently because your system with moderate traffic needs to look like Shopify.
Bad example - Shopify is a monolith.
This is great! ...in theory. But why do so many teams seem to have these kinds of problems? I think we have to come into these conversations with an over abundance of good faith that people are trying their best. Something in this microservice architecture conversation of the past decade isn't working as elegantly for a huge portion of the devshops that try it.
People should do lots of things, but that doesn't mean they always get done. There is merit to the argument that you may do things in a simpler way and adopt a different approach to cross team communication and complexity management. Your final sentence reads as a moral judgement equivalent to "your doing it wrong" without offering a solution.
We've had a decade of telling people they're doing it wrong and it's still being done with the same problems over and over and over again.
The fact that setting up your dev env takes such complex rituals and incantations that need to be prepacked in a spellbook is itself a red flag.
i've always thought a micro-service architecture should be decided and defined by the org chart and not technology.
Why do you need all microservices locally? Why wouldn't you set up just the relevant one, and proxy the traffic to the rest of the services already deployed? Or, failing that, why don't you have a docker-compose file that has already pre-configured your services to run locally?
And when I tried, it went nowhere. After months of work on my side project with Electron, Typescript, and Vue, I was in the same place because every time I opened IntelliJ, it seemed all of my effort went into just having it build again.
Now I chose ArrowJS for my project, and it's been a delight. Look, I get it, but I would refrain from accusing the other person of laziness in this case.
Learnings from 5 years of tech startup code audits: https://kenkantzer.com/learnings-from-5-years-of-tech-startu...
The very first two points prove that it's not just me.
On indeed.com I get 311 Django jobs and 3421 React jobs so in that sense it looks like "everybody" moved from Django to React.
On an intuitive level software seems like a tool to me. Latin had much more gramatical rules than todays English but that doesn't mean it "devolved" or that English isn't as powerful as Latin.
Blockchain is a mathematical idea and software the tool to use it. And LLMs are much more about statistical problem solving enabled through more computing power than about inventing something new.
And correct me if I'm wrong but aren't virtual threads fast enough also because of more computational power? A virtual machine is usually 1/3 times slower than the native machine it runs on.
Svelte bakes itself fully into your code in a way that you can't do without the compiler and still be using svelte.
JSX is an essential, yet entirely optional, concept in React. The output of the transform is incidental to the actual behavior of React, the library.
As such, I wouldn't think it warrants the term "JSXscript" or whatever the post I replied to used.
Depending on how your tool chain is set up, you don't need a custom file extension like ".jsx" for files that need the transform, and React doesn't care about file extensions at all.
Svelte, on the other hand, pushes you to use the ".svelte" extension, mixing and matching tags, changing scoping rules, and so forth. If you were to write by hand what it puts out, you're not really using svelte anymore. It is, in this sense, elevated itself to a language superset.
I'm not arguing one is better or worse, just pointing out why I think they are sufficiently different to quibble over semantics.
Not sure what exact use case sveltekit would be good for, that can't be solved with htmx + alpinejs.
Sveltekit does a lot more stuff and is accordingly bigger.
I mean, reductio ad absurdum:
s/sveltekit/<anything>/; s/htmx + alpinejs/assembly/;
The only thing that I would single out here as actual progress is the container thing. This really has helped me a lot, with local dev and deployment. I havent touched any orchestration like k8s yet though, so I am still on the “lite” side.
I absolutely love them when they do, but they have wasted so much of my time when they don't that I just skip them now. It takes me 5 minutes to set up a local env, and with a staging env at parity with production to test on there's never any issues.
- Simple syntax
- Convention over configuration, but gives you the ability to configure it when you need too
- Standards compliance
- Has state management, routing, validation, Fetch client and translation packages
- Completely written in TypeScript, so everything is strongly typed
- Great docs
- HTML templating syntax is standards compliant, so everything looks similar to native HTML. None of this weird curly, banana in a box, square bracket and weird symbol nonsense that is not intuitive.
People always ask, "Why not React?", "Why not Vue?", "Why not Svelte?", etc. People think you need to use the most popular option like it's a popularity contest. I find it laughable to build a React application in 2023 you don't just `npm install react`, people tell you to use something like Next.js which is a framework built on React (the very thing developers tried arguing for years you didn't need to build apps and that libraries were enough). I can guarantee that most of the people in this comments section either tried Aurelia years ago when it was v1 or have never heard of it. Then you would have some that won't use it because it's not big or popular enough.
I can build an app using Aurelia faster than most developers could using React or any other convoluted framework or library. Even Vue used to be nice and basic, before Vue 3 where they decided they would become React Lite and introduce complexity in the way you build things because everyone bought into the myth everything has to be functions and classes are bad.
At the end of the day the safest strategy is to use what works for you and ignore everything else.
I think Aurelia 2 still has the potential to make a comeback. Maybe not popular like React or Vue, but still. The beta has been quite good. It just needs more awareness.
I'd like to understand what you mean by this. As soon as you introduce network requests in a system, don't you need to deal with asynchrony?
Asynchronous code should be intentional and deliberate in my opinion, but in modern JS/Node it is the default which leads to all kinds of crazy workarounds, callback hell and race conditions. Node has the same issue PHP had now, where green devs will crank out code without realising they need to be watching out for these things.
Is it cool that a .forEach loop could be async? Heck yeah, should it be the default? The shit people write around .forEach loops suggests, maybe not!
Callback hell? When was the last time you gave an honest effort into JavaScript?
My team and I don't write callback hell, it's just a very common pitfall and you still see it all the time. You can't bubble wrap everything I suppose.
Ah, yes, the wheel of time. I've been through all of the things you've listed and more. My first job programming was in 1996 and involved HTML/JS/CSS and SQL. JS came out in 1995. CSS in 1996.
First it was cgi-bin, ASP, then ASP.Net and ASP.Net MVC, now I work with SPAs. When I hear the term "SSR" it instantly throws me back 20 years, when everything was server-side rendered.
As you mentioned, it's the same with things like SQL. When JavaScript exploded, we got NoSql, because it's easy to toss JSON into a KV store. Then a few years later, you see many more posts about people discovering how powerful relational SQL is, or awesome SQLite is, etc. It's the next generation realizing that things may have been done a particular way for a reason.
On the front-end, I work with enterprise Angular now. I have no desire to move on to the next shiny object/framework, because if it's bleeding-edge, that means the community is small. And if it doesn't explode in popularity, that community will disappear and you'll be left with an application running on something nobody knows. I try to keep pace with Angular's 6 month cadance and so far, so good. My current project has gone from 13-16 without any issues.
And don't get me started on microservices. Get off my lawn.
Heh. "The Wheel of Time." It's a very good name for what Alan Kay called, "not quite a field." In the modern era, fields of knowledge aren't supposed to forget what they learned every 5 years or so.
Then it turned out that data actually is just complicated, and managing that complexity is off and easier with a relational database.
Sometimes simplicity can be an illusion.
Of course, serverless is a misnomer. But it does mean you have to think of the server much less.
Isn't that what htmx and alpine.js are essentially based on?
What if I told you jQuery was itself a "crazy stack"?
Recently I spent a couple days building the same web app in Next, Nuxt, and SvelteKit just to get a feel of how to build a web app today. The web app was pretty basic. A couple of pages showing data from different apis and auth with user setting page.
My favorite by far was SvelteKit despite being the one with the smaller community. It was actually enjoyable compared to the others. It was very easy to feel like I was actually building something. You feel productive right away. The app automatically felt well organized with how the file layout was. Everything belong in a specific place. Layout goes here, Server stuff goes there, pages go here. Even form processing with nice. Building components was like building components in regular JS.
Next was my least favorite mostly due to the syntax and how you had to build the application. I really didn't like the whole style of Next and React. Just felt dirty.
I would highly suggest people to try SvelteKit. The file names might be a bit weird but it will teach you to use file finder in your IDE.
> I would highly suggest people to try SvelteKit.
I feel like this is a good summary of tech trends these days.
When the beginner's critique of the competition is that it felt dirty: Next was my least favorite mostly due to the syntax and how you had to build the application. I really didn't like the whole style of Next and React. Just felt dirty.
.... then I don't know that I trust their suggestion.
More importantly, technologies like programming languages and frameworks tend to shine at different levels of app size and complexity. Novice building a demo app says nothing about how the developer experience and code complexity will scale as you evolve your app or add more developers to the team.
And us greybeards: "I have built 50 different web apps across 20 years and I'd rather poke my eyes than work on client-side Javascript again. No, your new framework isn't any better."
BTW, is noticeable that you were careful to omit the `I have always been on the server side` part.
Yet, the only people who usually are carefully evaluated are the engineers. The rest get a pass based on personality and character.
I like them both, but tend to lean more toward Nuxt for the modules ecosystem and layers/extends. I also find composing reusable props with typescript to be nicer in Nuxt, but that's more of a Vue vs Svelte thing than Nuxt vs SvelteKit.
Eg. I would say involving TypeScript 100% loses at ease of building something simple quickly but with some experience I would not start a significant project without it anymore.
This is the key to making framework churn go away. The DX of using vanilla JavaScript is getting better every day. And is a much better experience than it was a decade ago.
> Islands architecture and partial hydration can help you render static HTML with just a small portion of JavaScript for those components who need it
I'm doing this with Hugo for rendering the static parts, and htmx for loading hydrated partials. The HATEOAS approach simplifies state management in the application. There is no client side "routing", just links and the back button.
In addition to vanilla libs, I include one "app.js" bundle. This file is created with esbuild and linted with deno. My "business logic" can be written in TypeScript in VSCode with the Deno extension and LSP server.
It is easy to put your nose up towards bloated frameworks when you’re doing small (static) stuff but as soon as you need the bloat you’re just reinventing a wobbly wheel without one.
There’s always an air of disdain against front end frameworks on HN but people often project their own not-needing-a-framework on the tool itself.
In an MPA, modules https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... can be included on the pages that require them with a script tag. Errors (and new features) are limited to a specific page, and the rest of the site remains unchanged.
> suspense (or another form of components loading their own data)
The htmx lib https://htmx.org/ mostly takes care of this: "gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML". The hx-boost tag can also be used for progressive enhancement.
> as soon as you need the bloat you’re just reinventing a wobbly wheel without one
When building a rich client, using a framework could be productive. For example a photo/video editor app. For a news site and CMS I would probably stick to the approach I've described above.
The only main frustrations I have are:
- Library support is pretty lousy. You need to fudge things around to get working. I.e, with leaflet and others I have vendored in the libs and redone them.
- Incremental static refresh with svelte kit is not really there. I'd like a web hook or api callback that allows me to refresh certain static pages as I know that changes are made. Right now I'm doing a janky refresh using a file lock notifier & it's a blemish on an otherwise great framework.
- The URL routing in svelte kit is... a little ugly. It's really hard when you have an editor open with 5 `+page.svelte` files. I wish they re-introduced file name routes, rather than folder name routes. It is entirely a personal preference I know, but I have seen a lot of negative things around it.
[1] - https://github.com/cetra3/divedb - deployed at https://divedb.net/
Next 13's app directory and React Server Components is killing library support in React, so that's not such a big problem.
It's a short term problem because most popular libraries will get updated eventually, but some won't and they'll only ever work on the client side.
In the case of Next, maintainers need to package their libraries differently to support ESM modules, or you need to configure your project to use the experimental.esmModules=false flag. Again, it's not a particularly big problem but it does reduce the size of the available ecosystem a bit.
At best you're getting SSR support since client components actually run on the sever as well, but there are already cleaner solutions for SSR react components that rehydrate in the browser.
That feels like a ton of refactoring just to have the same and result for a user, but maybe I'm missing some important gains of the app directory.
+1. I've been pushed to change tabs using `Ctrl+P` instead (search tab command) and write its route (folder's name). But it's still a bit painful
Some people have mentioned liking to set the label format to short under File > Preferences > Settings and then search for Label Format.
But I'm 100% with you on the routing. It's weird. One thing I had a lot of trouble was with "sub routing", like being in a route, opening a modal and having the url change so it can be linked to.
I had to implement some ugly workaround in the layout to catch hasthag # navigation.
around the 7:00 min mark
I'm hoping https://github.com/microsoft/vscode/issues/41909 will get implemented so we can make the problem go away entirely
I just looked through your repo. I'm still relatively new to SvelteKit and rewriting a similar content based site from React.
What led you to use the SSG adapter vs the node adapter (which uses SSR)?
How long does the build take to pre-render all of your content pages like the sea life?
Was there a particular reason you didn't want to use Form Actions?
Not criticizing your decisions by the way, I'm mostly just curious about the decisions others make to learn something myself :)
- I am using a rust backend for the static files and didn't want NodeJS part of the request workflow. Most pages aren't changed all that much, like maybe once every few months & so having yet another service as part of the connection flow just adds resources/delay when it's not needed. It's a lot faster/easier/cacheable to serve a static file.
- The prerender doesn't take all that long, maybe a minute or so, it's fast enough for the site as it stands, but if it got super massive it'd be a different story. I throttle how often it happens currently, so that there is a bit of time between pre-renders.
- The frontend communicates to the backend via GraphQL & the backend is not part of svelte kit, it's an entirely separate service, and so things like `page.server.ts` won't apply.
Cheers
Our desktop app builder is also built on Svelte (not SvelteKit).
I agree with pretty much everything in this article. I wouldn't put "Reactive declarations and statements" in the "Ugly" section though. They are definitely a bit tougher to fully grok than the rest of Svelte (Svelte is incredibly easy to learn compared to other frameworks) but once you learn how they work they are incredibly powerful and concise.
I also feel like "Svelte’s lack of protagonism" is a bit off the mark. Rich Harris is a great communicator and tends to be pretty public but the focus is more on community. Svelte Society's Youtube channel [2] does a 1 hour long "This week in Svelte" video every week and it is all killer content with no filler.
[1] https://www.todesktop.com [2] https://www.youtube.com/@SvelteSociety/videos
The svelte documentation is already great. This evengleism is good for commercial products. For technical open source, subjective evaluation is all that is needed. You evaluate whether it fits for your needs, you adopt or not.
Not everybody is walking into conferences and sticking swag on back of their notebook lids.
Rich Haris seems a humble great guy and he's doing good enough IMHO.
Now I always keep my reactive statements below my regular js statements, to remember.
Also I think it would have been clearer to call onMount, afterMount
Spoken like a true developer. Trash the old system, reinvent the wheel, prioritize the delight of the devs, leave the client with something that is totally obsolete and nobody else knows how to work on in a couple of years.
If that's not contract development in a nutshell I don't know what is.
Maybe i’m dreaming but i’m starting to feel a new « let’s stop with the fashion addict attitude to tech » vibe on HN, which i really really like :)
Some companies spend hundreds of thousands of dollars a year for terrible CMS websites. I've seen this situation 3 times in my career and for all three a re-write was the best long term option when balancing all the pros and cons.
Layouts, passing difficult props to components, passing state up and down in the tree (i.e. refs)
Feels like SvelteKit has a major - just use whatever SvelteKit offers, which is generally enough for smaller projects.
Just curious, I have no experience in svelte. It does sound like a major limitation.
I didn't have a problem, so I'm curious what the previous poster ran in to.
the only thing I can think of is that it doesn't impose much structure on the "lib" folder -- that's where code/components that aren't directly in the route files go. But there's nothing keeping you from keeping that organized yourself. So that's not really a problem, but something you might want to think about early if you plan to build out the app in the future.
I'm curious why?
From inspecting the html:
- sanity for cms
- tailwind for css
- partytown for running script in web worker
- most of the icons on the footer are just unicode emojis, no separate library just for icons....nice!
Only feedback I have:
- the sticky footer looks like what you would see in a mobile view and looks a little odd in desktop (I am not on a phone atm)
- Home page drop down in top left and some footer items are redundant, I would nix one (if I had to choose, nix the footer links, keep drop down)
- Super minor, but for the nav drop downs, implement animation for the up/down arrow icons to indicate open state
Overall, very clean. I'm going to follow your twitter and steal the styles from your html to apply to my own projects (bc I am bad at design, so thank you).
Our frontend codebase at OKcontract is implemented with Svelte, but we had to build some low-level libraries (including a wholly new implementation of Stores) to make it worthwhile. We're very busy with our main launch now, but plan to open source these libs asap.
PS: We're not using SvelteKit
We kept the same interface as the Svelte store, but with different semantics:
- special management of undefined values
- error management
- promise managementSpend an hour, a day, or a year (depending on how broad you want your "introduction" to this topic to be) reading the various blogs and docs on state management systems if you want to see how crazy this gets.
interface Book {...}
export const selectedBook = writable<Book|null>(null);
Works fine.
Namely, unavoidable TS errors in the Svelte parts that require tricks mostly because the full TS syntax is not supported inside components.
I wish they got into more of that; I've heard of stories but I've never run into this after several years of building Svelte projects, so I'd love to learn so I don't make those mistakes myself
> Svelte’s lack of protagonism
This doesn't look like it reflects on the system itself? I'd rather have something that works well and doesn't focus on flashy-ness. I guess the real downside is that there are such few plugins / tools for Svelte compared to React, but with Rich Harris working with Vercel on Svelte, I can only see things go up from here — like Vercel AI having out of the box Svelte support.
>>> But once you leave this path you may (and more likely will) get into trouble at some point. And sometimes there are projects where you don’t want (or can’t) risk getting in trouble because of the tool you’ve chosen for your UI development. There simply isn’t any room for that.
(I know that at least Django was written for a news site)
however the activity in svelte genuinely has picked up year to year. you can follow Svelte Society on Twitter and YouTube to see the many projects going on, in particular https://twitter.com/SvelteSociety/lists for people building and teaching and evangelising Svelte. they're out there! just necessarily smaller because they got started later + have less funding from Facebook.
That's interesting, because one thing I'd discovered in Svelte, which I didn't even dream of seeing ever again was a legible stack trace. It literally goes all the way down to the very change that caused all the mayhem.
> Svelte’s lack of protagonism
I see this as a good thing. My main gripe with React isn't even its design(which I also dislike, but acknowledge the fact that the market decided on a solution), but the social aspect of being a React developer. You have to accept everything Dan Abramov says as gospel, or else you'll be ostracized.
The frontend space would use less celebrities and more focused problem solving.
I remember when hooks came out - everyone jumped on the bandwagon and started rewriting normal, working components to this new paradigm. Net effect of course was unpredictable performance, because hooks are only simple on the surface.
I've never even thought about the social aspect of being a react dev - is there one? Frontend sure, but react specifically? It's just a tool, nothing to get ideological or bent out of shape over.
Couldn't give a shit what Abramov says beyond what is useful in my day-to-day. There are probably a lot of junior devs who are starstruck but I've never seen any hint of ostracization (lol). There are tons of junior web devs (and more everyday) though so I can understand how one could form that perception.
Yes to less celebrities and more problem solving.
Hooks are fantastic and so much more composable than the class methods. I use 100% hooks and functional components in my code nowadays and it has never been easier to build and understand my UIs - especially those with non-trivial logic and state. Never had a problem with them being "simple on the surface" but ymmv I guess.
I've dipped my toes professionally in all the popular frameworks and only in React are people this hyped for every little thing.
Case in point: there was a demo on Twitter - of some new feature which I don't recall - that showed how React "renders 3000 components in real time" - components being 3D polygons.
Many comments praising the performance.
Then an outsider asked "is 3000 polygons really that much?" And he had a point.
> Never had a problem with them being "simple on the surface" but ymmv I guess.
Yes, you specifically. But if you look at your typical junior to mid developer, you'll see them get into hard to debug performance issues bery quickly.
It's the same issue as with RxJS in Angular - many praise it, but most understand it only just enough to get by, making a lot of mistakes along the way.
I think the phrase for this is "footgun".
I agree that hooks are great, but a lot of people disagree and claim it's overly complex.
If it's a couple folks and you work well together and you want to use Svelte, I'd use svelte. If it's a larger team or a large project that will be iterated on for quite a while, probably Vue. I like Vue quite a lot more than React at this point.
I don’t hear any arguments against react here strong enough to justify not choosing VueJS or React.
It’s not in the interests of your client.
I feel like Vue would be a better fit for this role, especially since now they have a Composition API that's as pleasant to use as React, except that they do lifecycle hooks better than React (no messing about with dependency arrays): https://vuejs.org/guide/extras/composition-api-faq.html
There's also Pinia which is a lot simpler than trying to use Redux, it's closer to MobX: https://pinia.vuejs.org/
There are also plenty of component libraries, like PrimeVue: https://primevue.org/
Seriously, the only actual complaint I have about Vue is that the 2 to 3 migration wasn't all that pleasant (albeit not as painful as what Python dealt with hah).
Oh and for more complex use cases (like what Next provides), there is Nuxt: https://nuxt.com/
Next is so much more refined compared to that.
Vue also takes a lot of inspiration from compiler first frameworks and will be implementing an optional API to bring those optimizations to core in a coming point release.
I agree with you that hooks are a great feature that many React devs would probably enjoy using.
The only downside to Vue atm is the lacking comprehensive community support for libraries like `react-aria` and `framermotion`. I think the community is working on ports, but we all know that sometimes ports make compromises that might miss the nuance of the primary library author thinking about those problems directly in relation to the target client.
There was a psychological term for it, making a decision first and only then finding supportive arguments in favour of the decision?
This sounds like the opposite of a nice DX for anyone but the engineer who wrote the original code.
Would be more interested in how your work flow was managed.
The point about it being more efficient in terms of performance certainly rings true but to claim that it's 2x as productive (twice as fast to get something out in svelte) than react, to the extent you've graphed it in the introduction, is a fabrication. I've seen 2 year old actively-developed svelte projects with so much shimming baked in to support common components that the dev teams essentially have their own toolkits just to work with it. That is not what I would consider 2x as productive. It is an age-old paradigm of "less features = quicker" that at some level of required complexity does invert.
It's not a static "this is universally faster" equation.
(also wouldn't mind a follow up article on hosting such a busy site!)
Svelte has been around for years, and in my opinion it won’t really gain that much traction anymore. (It’s just an opinion, let’s not be religious)
even react is shifting more from CSR to SSR,I wonder when I will just switch back to Django with htmx and leave react all together if SSR is what I need.