Hacker News Reader

Comment by beau_g | Hacker News Reader

Has anyone worked on a very large Svelte project yet? I work on a large React app in real life, but have been learning Svelte in my off time - there are some nice aspects like the out of the box state management, the syntax and structure is a bit easier to learn than React, but my intuition is a Svelte project would become unwieldy for a very complex app (React class components that are hundreds of lines long with dozens of props/local states are easy for me to read/digest but maybe I'm just used to it, it just doesn't feel to me like this would stay well organized in a .svelte file).

View on HN

Not sure if this satisfies your question, but I'm the creator of the Skeleton UI library: https://github.com/skeletonlabs/skeleton

Our documentation is all Svelte and dogfoods our own UI components. We've got dozens of pages and components here. Scale is from small to large. All open source so give it a go.

I come from a background in Angular over the last 10 years. Built several large SaaS apps and admin systems. I'd have no hesitation using Svelte in it's stead. In fact I'd probably get it done in half the time and half the code.

We built Roomlio entirely with svelte. Large app and many components. Having used react and angular on production apps in the past, I much prefer svelte. That being said, I am sick of framework fatigue and going forward I would probably choose raw web components and a simple template literal based template library like lit-html (not lit element). Write all the other bits ourselves.

Have you considered open sourcing the component library? I feel like lack of this kind of tooling is one of the main things holding Svelte back.

If you are sick of framework fatigue, why not sticking with the framework you know ?

It seems to me that using raw web components you would end up writing your own custom framework, which would be yet another framework but with probably less support

> It seems to me that using raw web components you would end up writing your own custom framework, which would be yet another framework but with probably less support.

Come on, why even ask this, you already know the answer.

Writing frameworks (or text editors, or...) is fun, and the original dev will be long gone when the warts of the framework become obvious and drag down the project (5+ years from the initial launch date).

Its a good question. I should have said I have "dependency fatigue". If we do stick with a framework, it would be Svelte, it has a great Dev UX. Over the years, I have came to the conclusion every dependency is a future problem, especially if pulled in w/o giving it much thought. It takes two hands to count the number of times we had to refactor an app because some client side router changed their API _again_. Writing a small client router that does only what we need is an event listener and switch statement. Javascript/CSS itself has came a long way in the last years as well. I have no plans of building yet-another-framework. Leverage what the browser gives us as much as possible, any annoying boiler plate can be a snippet or generator. Avoiding the complexity that a bundler adds is also a bonus. Tucking logic away in dependencies, whether written by ourselves or others can complicate things.

I am a founder first, and a developer second. My biggest goal is to build products that solve problems and load extremely fast and are as lightweight as possible. The less tech involved the better.

Lastly, this is just one person's opinion, and I am often wrong.

notable companies now using svelte not just for internal apps but customer facing, critical stuff: huggingface (for everything, including gradio), alaska airlines (entire customer flow), razorpay (payment dialogs), schneider electric (many things), ikea (ecomm experience), riot games (league of legends client), Brave (search page), Square (developer portal), several YC startups, and basically every notable data journalism outlet on the planet (Bloomberg, the Economist, Reuters, Les Echos, german and japanese publications, pudding.cool, and of course the NYT)

IKEA uses Svelte in a couple of places, but we’re majority React (mostly server-rendered) for customer facing pages.

We rewrote our fairly large React app in Svelte and compared to React, Svelte is an absolute dream. Developers are no longer afraid to make changes to the UI. Making changes takes less time and it's easier to get them right first time resulting in fewer bugs.

Our application frontend is in SvelteKit and open source.

We are hosting ~2.5 million pages.

You can find the code here: https://github.com/tradingstrategy-ai/frontend/

One one the latest additions for making managing large applications easier is folder based pages, with +page.ts and +page.svelte and all of their children compnents in the same folder.

Generally, folder based routing makes code much more manageable than React routing solutions, as React has too many solutions and is not enough opinionated for large projetcs.

People seriously need to stop with this idea that small frameworks are only good for small projects.

The counterintuitive reality is that the best tool for big project is a small framework.

The bigger your project is, the more likely that framework will be getting in your way. The more likely that complexity of the project will be multiplied by complexity of the framework and result in an unmaintainable mess.

There’s a very complex open source low code project called Budibase that you can look at: https://github.com/Budibase/budibase

Reply on news.ycombinator.com