> Reactive declarations and statements are useful features, just remember not to abuse them, otherwise you may end up switching Svelte’s productivity by headaches and infinite debug sessions
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.
It was a replacement for an existing website (requirements are well known), so a custom CMS being part of what they were hired to build and an MVP of that CMS being what they're talking about isn't so irrational.
As the author states, ... Svelte Stores are rough. Beyond just missing usage patterns and documentation, we found that several features are lacking, especially when used with native reactivity (`$:`). Another area lacking is TypeScript support.
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.
stores are nice (i’ve found the transitions especially useful) but very much optional. i’ve used redux with svelte with good results and as the article says, it’s easy to get svelte to work with any pure js libraries
I find this a bit confusing, because stores are one of Svelte's answers to react's state, and React's state is a hot mess once you go beyond component-local state
Briefly speaking, it's because the mechanisms for dealing with complex state structures which are either global, or shared between multiple components which are not direct ancestors/ descendents of one another, are really complicated, due to how changes within that state need to be managed and propagated through the component dependency graph.
Spend 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.
I've moved my little hobby website to SvelteKit[1] from react and I am not regretting it.. yet.
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.
It means that library maintainers are having to make changes to their libraries to get them to work on the serverside, and a lot of them aren't not really doing that very quickly.Consequently moving to RSC reduces the number of libraries that work with your React code.
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.
Before, there was only client-side. Server-side is opt-in. So all the libraries you used client-side, you can still use client-side by using client-side components
Pretty much every library I have tried to use with Next App Router (and therefore RSC) doesn’t work with RSC. I’m sure it will change but we’ll be sticking for Next Pages for a while yet.
What's the point of using RSC if you have to mark everything as client components?
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.
You're not using RSC if you're marking everything as a client component. The point is that you can do that and continue to use your old components while also able to use the new app router infrastructure.
Can you clarify how you would normally switch tabs and why that's difficult? If I open up a bunch of `+page.svelte` files I see them as "+page.svelte ../docs" or "+page.svelte ../blog" and so it's fairly obvious which one is which to me. Longer-term, I think we can tweak VS Code to get rid of the duplicate "+page.svelte" part as it is duplicative and unnecessary, but I don't find it unworkable at the moment. I'm wondering if it's simply that we have different tolerances for this or if there's something else going on in some cases.
Some people have mentioned liking to set the label format to short under File > Preferences > Settings and then search for Label Format.
Haven't had that refresh issue because I don't use that.
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.
I haven't had much trouble in VS Code since it shows the directory name just after the file name. Some people have mentioned liking to set the editor tab label format to short. Go to File > Preferences > Settings then search for Label Format.
Thank you! I've tried to address your questions below. Most of these decisions stem from having the backend written in Rust, & using GraphQL. That decoupling in the end made it a lot easier to port from react.
- 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.
This is the vaguest argument against react I’ve heard. Not the basis for any rational decision making:
>>> 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.
as someone close to the Svelte community, i think the "lack of protagonism" comment is due to the relatively loud voices of those mentioned names.
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.
Standards-based is really the only thing that challenges react these days, i.e. raw JS with es modules, web components, and no build step/bundling. It only works in certain situations though, but when it does work, it's so much better than the giant web of black boxes and indirection that is the React universe.
> Standards-based is really the only thing that challenges react these days
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/
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/
I like Vue as much as the next guy, but comparing Nuxt to Next doesn't really do Next justice. Nuxt is pretty much a glorified blog engine, a conceptually broken tech demo. Its performance is abysmal, the developer experience frustrating, and many things that seem convenient when you read the docs turn out to be a hassle in production.
This description of Nuxt 3 couldn't be further from reality. Performance is on par with anything else I've tried (SvelteKit, Remix, Next) and the DX (module ecosystem, layers, auto imports, vite, etc ) are actually what's made it my default.
Vue 3 is seriously an amazing piece of tech. Nuxt is going after the same DX of Next but without all of the big company IPO baggage behind it.
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.
Of course it could have been done without Svelte. Thats the only stack their team know and/or wanted to work with. Nothing wrong with that, but would be nice if they were more upfront about that instead of "impossible for a different solution to exist".
There was a psychological term for it, making a decision first and only then finding supportive arguments in favour of the decision?
Often choosing the most popular is like "Million flies cannot be wrong, shit is good." New technology is created to improve things, so it would not exist and people would not use it, unless there is something to improve.
> by wrapping a vanilla lib to a component or an action, you’ve essentially created basic Svelte version of that lib
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.
This is all fun and games until you work on a platform that requires dynamically loaded modules, error boundaries and suspense (or another form of components loading their own data) and then the no-nonsense approach falls flat.
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.
> 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 hx-disable attribute can be used to disable htmx for parts of the DOM that load user generated content, is that what you're referring to? https://htmx.org/docs/#security
- 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).
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.
I like the fact minimalist approaches, like svelte, htmx and alpine.js are getting more and more traction.
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".
Unfortunately it takes time and experience to filter out the hype and marketing but hype and marketing usually acts against good experience. I thought something is wrong with me when a thought came to mind that (early) no-sql really really could use relations. People said I'm silly for trying to make no-sql sql-like.
I think (or rather, hope) that this is a symptom of the low interest-rate era, and companies may be less willing to waste money and development cycles on chasing the latest shiny.
It's the second, younger generation of devs who are realizing that "complexity kills". Those of us who started in 2000's have already seen this. It's a natural cycle. We are seeing a spring-back to monoliths and away from micro-services and crazy tooling chains.
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.
I think technology choices should be made depending on the team. If you have 5 teams with 10 people each, then it is a great idea if your service is comprised of 5 microservices that talk to each other across team borders through well defined APIs. If it takes you 3 days to run your microservice locally, then you somehow didn't set up your development environment when you should have.
> then you somehow didn't set up your development environment when you should have.
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.
A well-tooled environment does not just spring out of an ether. Maintaining proper tooling in a distributed system often requires more work than the system itself. In a lot of cases, the business does not even consider this kind of time commitment, pushing the team to churn out features, and who eventually just bog down in insane complexity.
This strikes me as a, "poor carpenter blames his tools" situation. Obviously if a business does a bad job considering the needs of their engineers then the needs of their engineers won't be met, but that doesn't mean that the modern development environment is the problem.
> it takes 3 days to set up your microservices locally
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?
This sounds like a symptom of you falling behind the technology curve more than a problem with the technology curve. Most people are achieving vastly more with newer tech than ever could have been done in the early 2000s. You've gotta be looking through some densely rose colored glasses if you think that that the web in the 2000s was just as powerful as the web of today.
I resisted learning a lot of it knowing that there will be a snap-back to simpler designs long-term, and it's happening now.
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.
I don't think there is laziness in falling behind the technology curve - the things that worked ten years ago still work today and if you're shipping code then what you're doing is working. But new technologies aren't overly complex and they generally make a developer's life easier, not harder, but they all come with a learning curve. And the landscape evolves quickly, so in order to leverage them you have to stay on top of it.
Your parent comment definitely came off as arrogant, but your reply doesn't come off any better. If it's objectively incorrect, then you can contribute to discussion by explaining how and why. A low effort drive-by dismissal isn't appropriate for HN.
This is anecdotal, but I have been in the industry > 10 years now and worked for a lot of employers. What they have required of me for the frontend has pretty much been the same more or less throughout. But recently, with the large amount of funding, companies have had a large blow up in payroll and a talent shortage. The talent shortage has resulted in some juniors getting hired that would not have gotten hired during the great recession. These juniors, on average, need to know a lot more now than back then due to the complex stack. This has resulted in a lot of breadth of knowledge but not a lot of depth. Over time , large teams of inexperienced people have turned what could be a simple frontend created by 1-2 developers in a large 15 developer behemoth that is difficult to maintain and keep secure. It is difficult to reason about for most newer developers so a lot of the time is spent handling edge case bugs instead of getting the job done. Usually their needs really aren't different. It's often just an intranet app or b2b. These don't have scaling needs and you can create reactive asynchronous websites without the complexity here and without reinventing the wheel. Sometimes, the complexity introduced by this complex stack is required (i.e. the app being created is complex). Everyone thinks their app is complex. It almost always is not complex, at least on the frontend, and it could have shipped earlier and with less bugs if the complex stack was not introduced.
There's a HN world of what's gaining traction and what "everybody" is using, and the real world reality. If I search for Django jobs on indeed, I get way more results for Django than if I search for Svelte (183:11). If I ctrl+f on "Who is Hiring?", the ratio gets a lot closer (13:4).
I think sametmax was saying that "everybody" is using React for usecases that Django could do long ago, and that Svelte is in the "gaining traction" category.
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.
I hear the argument being made, it just doesn't make any sense. We are using React to do things vanilla JS could do eyears ago. That doesn't mean React doesn't make doing those things easier. I like Svelte as well, but it likely wouldn't exist today without lessons learned from other frameworks like React.
This reflects my experience from the 00's onwards. Survived and avoided most of these—except the nosql bandwagon. A worn out and wiser man, ended up switching back to relational DBs several years later.
Software itself hasn't "evolved" over the last 40 or 50 years. It only ever gets better because the hardware becomes better. There is no true innovation in software development. Folks that "innovate" either reinvent the wheel or capitalise on hardware improvement.
Look at all the fascinating runtimes that have evolved. Erlang, Haskell, Go, Rust, and include any other. You don’t consider any of these evolution? Back then, programmers were still using threads for everything. Now we have “green threads”. One example of a pretty great evolution. Albeit it does feel like software evolves slower than hardware.
I talked about my statement with a friend the other day and was able to consolidate my stance.
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.
JSX is, imho, more akin to a macro; the syntax is replaced with simple expressions. Technically, the JSX syntax isn't even necessary to use React, though most people prefer it.
Svelte bakes itself fully into your code in a way that you can't do without the compiler and still be using svelte.
The point is that Svelte is a full compiler- you cannot "use svelte" without it.
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.
htmx, alpinejs + golang is the exact stack I've been thinking about. I'm not a front-end developer, but want to be able to prototype things quickly. Are you aware of any public examples of this stack that go beyond "Hello, World!"?
I'm not actually, but I found it very easy to learn. The documentation really is enough. Htmx is used for requests and replacing content. You just need to figure out when to replace what. Alpine is used for on-site interactions. You can hit me up on twitter if you have questions, love to help other people with that stack! https://twitter.com/andinfinity_eu
The list is not complete without mentioning the site has a total number of users equal to or less than the amount of people you can spam and still consider you a friend
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.
Totally agreed on containers but I’ve noticed so many developers promptly ignore using the containers that are set up for them when developing locally. Then days are wasted again on deployment issues down the road.
The issue I always run into is that containers don't get maintained. I have never encountered a project where a container "just worked".
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.
One of the exact reasons I've been working with Aurelia as my Javascript framework of choice since 2015. Aurelia 1 has served me well and I have apps that have been in production for eight years untouched. They just keep running without fail and they're so simple. Similarly, Aurelia 2 (currently in beta) is even better and as stable (same templating syntax, DI, etc). I tend to avoid all of the hype in the front-end space. The only thing clients and companies care about at the end of the day are results.
- 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.
2015 was when I used Aurelia, too. As someone who used the first version of Angular, it was a breath of fresh air, and I agree that you can get results quickly using Aurelia. I left that company so haven't been using it, but I've secretly hoped people would catch on and switch to it somewhere down the road. But as you say, it's fine that it's not popular--quite often, the best things are not the popular things.
Sadly, Aurelia didn't quite catch on like other options. But, it's funny when you look at libraries like Svelte, many of their touted features like reactivity not only existed in Aurelia, but in Durandal before it. I think it comes with age. I'm in my mid-thirties now, so I just use what I want to use that gets results. But I remember being young and hungry as a developer in my twenties, you used what everyone else used because of job prospects.
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.
Everything in JS started with callbacks, then promises came on to the scene with libraries like Bluebird, then the async/await syntax was added to the spec. The language was always able to handle concurrency but it was a long road to the current state.
You can just wait for the network request to finish before continuing. Many actions require it anyway.
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!
He still has a point. Go code and similar languages hide the concurrency. You write synchronous looking code most of the time, but underneath, libraries and runtimes ensure you’re running concurrently.
Most libraries are async and some standard lib stuff is unexpectedly async as well, so you are often handling async concerns even if what you're writing is better syncronous.
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.
> 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".
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.
> Ah, yes, the wheel of time. I've been through all of the things you've listed and more.
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.
But that was the line that noSQL advocates were pushing. You don't need this big complex relational database, just make everything simple JSON and call it good.
Then it turned out that data actually is just complicated, and managing that complexity is off and easier with a relational database.
Nice list; I am not a primarily front-end dev so I can't say I've lived this but I've been around long enough to remember all of these; sometimes painfully.
My org uses serverless to great success. I highly recommend trying it out if you haven't. It's just so nice to create a function and know we don't have to configure any part of the server to know it'll run, and then the true benefit comes from the almost infinite-feeling scale we can get at a super low price.
Of course, serverless is a misnomer. But it does mean you have to think of the server much less.
> 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
What if I told you jQuery was itself a "crazy stack"?
We have recently moved our website[1] to SvelteKit. Previously we were on Sapper. Previous to that we used a custom Webpack + React setup to output a static site.
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.
I don't want people preaching hooks as the greatest invention since fire talks anyways. Such code if spotted anywhere in a backend would be slammed for being horrendous and violating almost any intuition definition of maintainable code.
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.
Rich Harris is definitely not a humble guy. He pretty much can't talk about Svelte without framing it as the savior to modern web. And I would say some of the things he pushes are blatantly false
The things that bit me with svelte's reactive statements is that they are run at the end of componenent initialization (but they are part of it, unlike onMount's arg)
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
I never built a web app in my life. I have always been on the server side.
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.
> A beginner suggesting something to try seems fine to me. They have something no amount of study can give, a fresh perspective.
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.
Then there's "I build one web app in my life. Typescript is the best thing ever."
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."
Then there's "I've been writing frontends since Javascript was a thing and I think developing for the frontend with anything but Typescript is more effort than its worth and a little bit ridiculous, but maybe I'll give something with WASM a try when it's more mature"
It goes all the way upstream. People build SAAS companies offering services based on best practices while the product/engineering have had zero prior experience with the subject until their current project. People found companies selling themselves to investors as experts in the field that they have no experience in. Investors sell themselves as experts of the industry that they just invested in these founders for. Pension managers investing in the VC funds sell themselves as investment managers who practice a disciplined investment strategy.
Yet, the only people who usually are carefully evaluated are the engineers. The rest get a pass based on personality and character.
Just curious why you preferred SvelteKit to Nuxt? Literally every single thing you said of SvelteKit is also true of Nuxt.
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.
Ease of building from scratch and long term maintainability are different concerns and maintainability can require higher complexity at first.
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.
Tangential but is anybody doing SSR using Django or any non-js framework? What is your setup? Wish Django had a library that allows `return SSRResponse(bundlename, context=['foo', 'bar'])`.
> Reactive declarations and statements feel like powerful magic, and they are, but it’s very easy to hurt yourself by writing code that is almost impossible to debug,
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.
Full stack dev going on a decade here. Stack traces and errors in React are pretty awful, fully agree there.
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 never even thought about the social aspect of being a react dev - is there one?
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 have used both SvelteKit and React. Dev velocity was great in the beginning with SvelteKit when everything was super simple but decreased drastically as the project grew. Went back to Next. Apart from devs, none really cares if you wrote it in Svelte, React or bare HTML/CSS or if your site loads double digit milliseconds slower.
I have tried to use sveltekit once and turned around in 20 minutes as routing is severely limited. All I wanted to do was to route based on domain, with a different set of routes for one of the domains. Not exactly complicated or uncommon, but not something you can do with the sveltekit router.
As for routing, I guess that gets unmanageable pretty fast. Just in the sample blog tutorial here [0], you get confused with the number of files and nested folders that has same file names as level above.
This is gone over in the github threads about such a feature - basically, as two different projects semantically, the best thing is to create two different projects physically, in a monorepo. All the code-sharing with none of the additional complexity.
My app had about 50 routes (by the design there were about 80 pages, but of course some common patterns emerged). I wouldn't call it large, but it's past "toy" and probably not "small" for most.
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.
> After several meetings, we came to the conclusion that the best approach was to simply halt the old website development and build a new one from scratch using the best technologies and practices.
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.
They mention that the legacy system was scaled vertically and expensive. Sometimes a complete re-write makes sense.
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.
I really appreciated this article. No framework is perfect. Svelte always looked like the right approach for a modern component framework, but modern Vue borrowed a lot of its better ideas and ran with it.
Could you give an example of this or point to an article that does so? I feel the pull between "framework I'd most want to use (svelte)" vs "framework that is more popular, more docs, more devs (vue)". If Vue is getting more Svelte goodness that's a consideration.
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 agree at all with the fact that productivity is that far ahead on svelte - much of the react productivity lift is with the extensive support from other libraries and platforms.
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.
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.
reply