24 ms·

Comparing Svelte and React

293 points by feross 6y ago

k__ 6y ago
Half-OT: Svelte seems to be the pinnacle of the "bundling era" of frontend frameworks. What do you think comes next? XYZ-to-WASM? Back the roots with (non-)bundlers like Skypack? Anyone heard of next-gen experiments in that directions?
- hypermachine 6y ago
  We are actually going the other direction. Currently I am experimenting with making a Blazor/Liveview (HTML over wire) runtime that can support many programming languages. And a GUI builder.
  - sali0 6y ago
    This sounds fascinating. Anywhere I can read about it?
    - hypermachine 6y ago
      The UI builder and libraries are still heavily WIP. Previously we were focused on making a VBA interpreter. For the HTML-over-wire part we are experimenting with a protobufs-based protocol so the backend runtime can support as many languages as possible. The most challenging part is that client-server UIs have fundamentally different assumptions about state, concurrency, and session handling compared to traditional desktop/mobile GUIs that operate on callbacks. Most of the design patterns used for your typical WinForms/Cocoa UI fail horribly in web scenarios (unless the entire app is running client side in WebAssembly) because state must be held in a DB, global variables are completely not allowed and multiple users may simultaneously access a service so any form of long-running loops or blocking code is very problematic. Serverless could help here but you will need long-running serverless containers. The current pricing models of AWS Fargate and Google Cloud Run are not compatible with this. This is additionally complicated by the fact that many languages have async/concurrency "bolted-on". It is hard to integrate a WebSockets server into the language if there is already another event loop to deal with. This is especially problematic for feature-fragmented languages like Python where async is a relatively new concept. (See https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...) Go is basically the gold standard here. Overall, we are still working on how to build the language-agnsotic backend SDKs without too much duplicate code. If you see similar systems like Streamlit and Plotly Dash, they avoid the problem entirely by making proxying the default way of embedding in third party applications. The integration is not as tight as traditional UI frameworks but avoids many of the problems with state management. For deployment, the Blazor/LiveView/HTML-over-wire format would also require CDNs that are as close to the end user as possible for lowest UI latency. Think Zeit/Vercel or Fly.io. There's a mailing list link below where you can be notified for when we launch: https://hypermachine.org https://hypermachine.org
- fragile_frogs 6y ago
  > XYZ-to-WASM There is yew (https://github.com/yewstack/yew https://github.com/yewstack/yew) which is a React inspired Rust framework that compiles to WASM.
pitaj 6y ago
I recently rewrote a small UI from Preact to Svelte and while it was certainly a learning experience, I have to say working with Svelte is fantastic. My only complaint is that the Typescript support isn't quite perfect yet, but it's already very functional.
- Palmik 6y ago
  I use Svelte + TypeScript in my personal projects, what issues did you run into?
  - dhucerbin 6y ago
    Last I checked it was impossible to parametrize component type. In React you can write `<MenuSelect<User> users={...} />`.
    - patwoz 6y ago
      Please don't. It looks awful. And I think it's not necessary. Typescript should inherit it's type depending on what you are passing into "users".
      - efrafa 6y ago
        There are valid reason to do that. Like a component that takes render function and item that is passed into it that can be anything.
        patwoz 6y ago
        You can do that, but you don't have to. See my example here at line 26: https://codesandbox.io/s/clever-neumann-89tnx?file=/src/App.tsx https://codesandbox.io/s/clever-neumann-89tnx?file=/src/App.... Typescript will inherit the type automatically.
        kecupochren 6y ago
pier25 6y ago
> I love Firebase Authentication, it's such an easy way to add auth to side projects. It's easy to use but it adds 55kB gzip to your project. https://bundlephobia.com/result?p=@firebase/auth@0.16.4 https://bundlephobia.com/result?p=@firebase/auth@0.16.4 A couple of comments on the Svelte code. 1) It doesn't makes much sense to use onMount() with listenForAuthChanges(). Just modify the currentUser writable whenever onAuthStateChanged() has an update. Now simply import and use $currentUser in your components. 2) You don't need to use currentUser.subscribe() from your .svelte files as you can use the reactive $: notation for this. You can, if it makes more sense to you, but I wouldn't say it's idiomatic.
- ampdepolymerase 6y ago
  Re 1) Where should you put the code to initialize the SDK? Code that ideally should only be ran once in the entire lifecycle of the page. For Firebase, will ES modules help with code splitting? The new Svelte kit framework is built by Vite (runs on ES build underneath).
  - pier25 6y ago
    If you have code in say store.js it will triggered whenever the file is imported the first time. I also trigger init code from my entry point (eg: main.js).
  - akiselev 6y ago
    I use a dynamic `import()` in the login form submit handler with an initialization flag. Code splitting is handled by the bundler
Greek0 6y ago
The author praises Firebase Auth for its ease-of-integration, but I'm leery of depending on Google products due to its support horror stories. Can anyone recommend good, easy-to-integrate alternatives?
- dimgl 6y ago
  I've always wanted to try Auth0 and I've heard great things! I would love to hear if anyone has had a positive experience with Auth0 as well.
  - maxrev17 6y ago
    Positive exp with auth0, though if you can afford to control this stuff yourself maybe I'd lean that way.
  - tehbeard 6y ago
    Another positive experience with Auth0, if a little finicky in my usecase (using it as a SAML IDP for testing). They have recently been bought out by Okta... Which by some accounts might not be a good move.
  - presentation 6y ago
    My experience is that if you use it how they want you to use it (as a separate page hosted by them) then it’s simple and easy to use, but if you want to embed it they go out of your way to make your life painful. We took the latter route since we care about our UX and probably would have been better off if we just rolled it all ourselves.
- nicoburns 6y ago
  Do you need social logins? If not (and you just want email/password login) then implement it yourself. Auth isn't hard, and Firebase Auth doesn't provide you much in terms of managing roles/permissions or anything like that.
  - movedx 6y ago
framecowbird 6y ago
Javascript n00b question... is there any difference between onMount(() => { return listenForAuthChanges() }) and onMount(() => listenForAuthChanges()) ?
- oplav 6y ago
  No, they are functionally the same.
- rahulpadalkar 6y ago
  no
- jfengel 6y ago
  They are the same. It's a matter of style. For that matter, you could also write: onMount(listenForAuthChanges) which is technically simpler -- you're not constructing a new anonymous function. But if you wanted to extend the code (to say, add a console.log), you'd need to do the top version, which already has the braces. It's up to your judgment of what's clearer and likely to be more maintainable.
  - brundolf 6y ago
    This is a utility function I carry around between projects for the "logging within a pure expression" case: function log(expr) { console.log(expr); return expr; } onMount(() => log(listenForAuthChanges()))
  - M2Ys4U 6y ago
    That may be visually simpler, but if onMount were to start passing a parameter to its callback in a future version (for whatever reason) then that will be passed to listenForAuthChanges. Using the anonymous function means that wouldn't happen.
  - hoten 6y ago
    That should work in the provided example, but in general `fn(cb)` is different: you lose the implied `this` binding unless you do `cb.bind(something)` beforehand. There's also some unexpected trouble due to potential extra parameters. Consider the output of ['1', '2', '3'].map(parseInt) gives: [1, NaN, NaN] So yea, fn(() => cb()) is the same as fn(() => {return cb()}) – just syntactic sugar when the anonymous function has just one statement. but fn(cb) is semantically different.
Glench 6y ago
Great concrete comparisons in this article. I no longer use React in my projects and only use Svelte and it feels great. I'm very happy with it.
alfonsodev 6y ago
> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local state (useState) Then using Controller pattern, within the controller I use 4 types of hooks, 1 navigation (useHistory), 2 read global state (useSelector), 3 dispatch an action (useDispatch), 4 useEffect() to execute on props change or component mount. That's it, that's where the realm of React and UI ends for me, everything else is in Ducks, Ducks are single file or folder per module that contains Actions, Epics (Obervables) or Sagas (generators), Reducers, initial state of store and Typescript types. I really like this separation of concerns: - dumb components: to worry just about the looks and local state. - controllers: to worry about data in, actions out, life cycle and navigation. - Ducks: Management of data fetching and global state. I wrote this from the top of my head, but if anyone is interested I'm thinking about writing a demo repository and document this approach, maybe others have done it already this is not new, but practices that I've been collecting along the way.
- deleted 6y ago
  [deleted]
- protonimitate 6y ago
  > a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. As an fyi for anyone not aware, there are eslint/tslint plugins for this to help avoid it.
  - wbobeirne 6y ago
    100% this, I often find myself getting tripped up when reading people's complaints about the JS / React ecosystem until I remember that TypeScript and the ESLint (and typescript-eslint and eslint-plugin-react) recommended config isn't standard in everyone's projects. It saves you from a ton of these headaches. Not that the answer to a complaint of a complex toolchain is more tools in the chain, but it's a wonderful development experience once you develop a collection of tools you really like.
tubbyjr 6y ago
There needs to be a 'fun' in 'svelte' somewhere, because it actually makes front-end devving... dare I say, fun and enjoyable.
deleted 6y ago
[deleted]
zem 6y ago
i'm just getting into front-end programming, and my (perhaps unfair) impression of react was that it was "bloated", so i stayed away from it. i've played a tiny bit with svelte and loved it though, i'm hoping to get a PWA up and running with it and invest a lot more heavily into learning the ecosystem if that's a good experience.
trafnar 6y ago
Is it necessary to use a worker for the timer? If you just record the start time, then inconsistent setTimeout calls aren't a problem because each call calculates the duration from start time to current time. Or am I missing something?
- akdor1154 6y ago
  You can work out that your 25 minute timer actually took 30 minutes this way, but you can't fix it to make it actually take 25 minutes.
- dceddia 6y ago
  Yeah, but I think putting it in the worker was about making the timer able to “go off” at a specific time, while the page is backgrounded.
- fragile_frogs 6y ago
  HTTP 203 has a great video about counters (https://www.youtube.com/watch?v=MCi6AZMkxcU)which https://www.youtube.com/watch?v=MCi6AZMkxcU)which goes into more details about why counters/timers are a bit more complex.
Vinnl 6y ago
How's unit testing in Svelte today? That's the main worry I have with template-based systems (well, that and TypeScript support, but I hear that that's quite OK now).
- dfrsol 6y ago
  It's still the glaring hole in the ecosystem.
- dceddia 6y ago
  There’s svelte-testing-library [0] which follows the same approach as the React flavor. It emphasizes testing the app “as the user would use it”, which boils down to rendering components and inspecting the DOM. They intentionally don’t give you visibility into the internal state of the component, which can be weird to get used to if you’re used to doing things like “click the button; assert that state isClicked became true”, but it tends to result in less brittle tests. 0: https://testing-library.com/docs/svelte-testing-library/intro/ https://testing-library.com/docs/svelte-testing-library/intr...
  - Vinnl 6y ago
    Thanks, that looks pretty good, and testing-library is excellent. I couldn't find it in the docs, but do you know how this "renders" the Svelte components - in memory using e.g. jsdom, or by firing up a full-fledged browser? (The former would be highly preferable.)
    - dceddia 6y ago
      Testing-library uses jsdom across the board, as far as I know. It might support running in a full browser too but I haven’t used it that way. For end-to-end tests with a real browser, Cypress is a good option.
      - Vinnl 6y ago
        Cool, sounds like it should be in a usable state then.
beaconstudios 6y ago
The svelte approach of implementing better paradigms using compilation rather than using abstractions just seems infinitely better, and a better way to scale up a program in general. I do wonder why this idea never caught on; I think Alan Kay was investigating building a programming platform based on this idea but that's just academic.
- amelius 6y ago
  It's kind of funny that a NYT graphic designer (Rich Harris) outsmarted so many CS academics in finding the right software engineering tools.
  - beaconstudios 6y ago
    Experts seem to suffer so often from myopia. Sometimes all it takes is a fresh perspective to glean a new idea.
  - raihansaputra 6y ago
    I think it's an academics vs practitioners thing. Rich is willing and can use Svelte and Svelte/kit in actual production workloads in NYT. Kind of similar in how most Rails abstractions are pulled out from Basecamp's implementation. Doesn't hurt that Rails HEAD is directly used (in % deploy) by Shopify etc too.
- preommr 6y ago
  Because these tools were made in a time where people were using libraries like jquery. People were building js apps by including libraries directly in the header. Before webpack, and even gulp, when having a build process was a novel thing in web dev.
IshKebab 6y ago
No mention of Typescript. You'd be mad to consider writing a significant app without it, and React has really great Typescript support - even templates are type checked properly thanks to JSX/TSX, and basically all tools support JSX these days. Vue doesn't come close to that, but it does look like Svelte is at least a bit better: https://svelte.dev/blog/svelte-and-typescript https://svelte.dev/blog/svelte-and-typescript I'd still be wary that there are big caveats though. React was designed for Typescript. Javascript projects that bolt it on later tend to have issues.
- nsonha 6y ago
  > React was designed for Typescript this isn't true but JSX was made to be "just js" (obviously isn't true either) which contributes to it.
- presentation 6y ago
  The one place where react typings are disappointing to me is that all elements are typed as JSX.Element, meaning you can’t assert a specific type of child element. Usually not a big deal but would be useful in a number of cases.
  - nsonha 6y ago
    It's a limitation of TS, not react. Flow for example can type elements more accurately.
- jansan 6y ago
  >No mention of Typescript. You'd be mad to consider writing a significant app without it, Thanks for calling me mad :)
- brailsafe 6y ago
  > Vue doesn't come close to that > thanks to JSX/TSX, and basically all tools support JSX these days I haven't used TS and Vue together, but Vue 3 seems to have been written with TS, as well as having supported JSX for quite a while. What are the limitations?
deckard1 6y ago
I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed their mind at least 3 times on the API and none of it fits together today. Hooks and classes don't mix, lifecycle methods are still out there and just as confusing today as they were years ago. Mixing state and functions. It's just a horrible bag of half-baked bad ideas. And it's not even batteries included. Svelte has it all built-in. It has the equivalent of CSS modules. It has global reactive state and an incredibly simple state protocol that seems almost stupid if you're coming from Redux. You step out of your daze and realize you don't need all the rituals and boilerplate. The things I've seen built on top of that simple protocol can be incredible. It's not magic. It's just JavaScript. I dare say that Svelte is a joy. But I hesitate to even leave this comment here. Because I know the architecture astronauts are listening, eager to sink their claws into this simple elegant new thing and fill up their Github profiles with soon-to-be abandonware cruft which they will use to pad out article after Medium article which will all pour down upon Hacker News like a shit typhoon. Prodding us to join their cult of Svelte+RxJS. Or Svelte Sagas. Or their random dogma they toss into a giant bucket labeled "Svelte best practices." And, of course, "Ten ways you are doing Svelte wrong." I might be a little bit cynical.
- Aeolun 6y ago
  Have you ever worked on very large React applications without Redux or Saga? I just cannot imagine any other way of keeping my application sort of understandable.
  - buzzerbetrayed 6y ago
    You should look at svelte stores if you haven’t already. They are amazing, and make redux seem so needlessly complex and ineloquent
- alfonsodev 6y ago
  I think many people adopted React because Facebook was behind it, and using it in production, the ecosystem is huge, there is a react- package for everything you can image, there is also react-native, I don't like it, but there it is, you can reuse the knowledge to build native mobile apps. Now Svelte, I haven't been following, but I think the creators are working in what's going to be next and even better framework[1], to your point of things in Svelte not changing as much as in React, maybe it just a matter of time. Here is the video I had in my bookmarks for a while, I still couldn't make the time to watch, so I hope my comment is not too far from reality. [1]https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s
sandreas 6y ago
Since svelte does a lot of compile time stuff, I would like to mention Routify, which is compile time SPA routing. For me it worked awesome to accomplish projects with many routes and the need for hash based routing. See https://routify.dev/ https://routify.dev/ and https://routify.dev/guide/installation/install-to-existing-project https://routify.dev/guide/installation/install-to-existing-p...
davidwparker 6y ago
I wrote my first decent size Svelte app (with a Rails API app backend) last year: https://www.listenaddict.com/ https://www.listenaddict.com/ Of course, what you see is just a tip of the iceberg, having implemented a nice admin and moderator dashboard, keyboard shortcuts, animations, 12 different color themes (in light and dark mode), and more. Svelte just made it all so easy to do. Having done a good bit of React and Angular professionally, and tinkered with Vue, I can safely say (for now) that all I want to do is Svelte. The rest just seem so heavy handed in comparison. Self promotion: I also run a YouTube channel where I'm slowly building out a Svelte app with Rails API backend. If you're interested in Svelte, please check it out: https://www.youtube.com/user/iamdavidwparker https://www.youtube.com/user/iamdavidwparker
- abraxas 6y ago
  Your site is brilliant and works really well. I’m also going to check out your YouTube channel.
  - davidwparker 6y ago
    Appreciate it!
  - gonzus 6y ago
    Seconded. I am a back end developer and had a lot of fun watching your Svelte Sapper series; thanks for your work! Quick question: which color scheme are you using in VSCode? It looks a lot like jellybeans for vim, which I love.
    - davidwparker 6y ago
      Thanks! I think I'm just using the default dark color theme. (dark+)
- rikroots 6y ago
  Same here. I've used Svelte on two reasonably hefty personal project sites[1][2] and was pleasantly surprised by how easy they were to build and (now) maintain. The one issue I had with Svelte was Sapper - I didn't get on with it (it wasn't a good fit for either of my projects). SvelteKit was released in beta a couple of days ago - I've no idea how much that changes things. I'm hoping I don't have to relearn a whole bunch of stuff to use the new shiny. [1] - https://rikverse2020.rikweb.org.uk/ https://rikverse2020.rikweb.org.uk/ (Warning: Poetry!) [2] - https://scrawl-v8.rikweb.org.uk/ https://scrawl-v8.rikweb.org.uk/ - I was quite proud about getting my canvas library to play nicely with Svelte
jeswin 6y ago
I think it's a misunderstanding that Svelte is fast because it is "compiled" into imperative DOM updates. This is partly because the documentation says so, and the early blog posts emphasized this aspect. Compilation actually has nothing to do with it. Svelte is fast because it doesn't do all the Virtual DOM stuff, and the DOM diffing. You could very well build Svelte as a library without the compiler, and it would be just as fast. But the compiler helps a bit with the ergonomics - it's cleaner to do count+=1, rather than setState({count:count+1}).
- TehShrike 6y ago
  The compiler turns 20 lines of runtime code into 2 lines of runtime code. The performance effects are real!
- leeman2016 6y ago
  Due to compilation, bundle size gets a lot smaller which will boost start-up/load time.
- hajile 6y ago
  I believe infernoJS complete with vdom still matches and even exceeds on most metrics. Last I checked, svelte compiled different code paths for every single component. This means that most DOM manipulations in real-world applications (not micro benchmarks using the same components repeatedly) won’t ever optimize in Svelte. Meanwhile, the vdom code runs constantly and is hand-tuned to help ensure deopts don’t happen. Likewise, potential optimizations to reuse old nodes and other “garbage” are much easier to implement with a unified DOM implementation. Finally, once you implement the vdom once, you don’t do it again. With Svelte, your code is recreated for every component. This may give smaller component in the short term, but there’s an inflection point (and it’s in the small-medium range) where svelte starts shipping more code for the same work.
alphachloride 6y ago
Svelte and React each have their advantages and they make a convincing case each for the #2 position for a Javascript framework.
- jrib 6y ago
  I'll bite: what's your #1?
  - alphachloride 6y ago
    Plain ol' vanilla javascript, of course.
wzy 6y ago
When compared to Svelte, it's like React developers wake up every day and choose complexity.
- nsonha 6y ago
  It's actually very simple. React devs choose to write code in code. People of other frameworks write code in code and templates, which, to react devs, is complexity.
kushan2020 6y ago
Great comparison writeup! However, I do feel some of the points made are weak and seem to be rushing to conclusion. In the React hook worker code you do not really need to use the `ref` and you can do something like: ``` function useWorker(currentUser, setCurrentPom) { const [worker] = useState(() => new Worker(workerURL)) useEffect(() => { const onMessage = (event) => { if (event.data.name === 'tick') { setCurrentPom((currentPom) => ({ ...currentPom, secondsRemaining: event.data.counter, })) } else if (event.data.name === 'start') { // More branches removed here to save space... } } worker.addEventListener('message', onMessage) return () => { worker.removeEventListener('message', onMessage) } }, [currentUser, setCurrentPom]) return worker } ``` The reason it works is that `useState` allows you to lazy load something. You mention two points which make svelte easier, but I would challenge you on those: > We don't have to keep the worker in useRef, and can just assign it to a variable. As per my thoughts above you do not need useRef, in fact you just separated the whole worker logic into a separate function which gives us separation of concern and better readability. > We can pull the event listener code out into a function more easily, as that function won't then become a dependency to a useEffect - at which point we will have to wrap it in useCallback. I am not sure I fully understand this. But if you are talking about wrapping the event listener code into a function, you can do that and you do not need to wrap it in a callback. Though, I am not sure what we gain out of abstracting the event handling part.
anonytrary 6y ago
1. Community support. Svelte I think is the "more technically correct" approach, but React 16+ is good enough, concise enough, and it has thousands of community packages already. Svelte still needs way more buy-in for it to be a serious option at our company. We actually implemented a small part of our app in Svelte, but moved away from it because Svelte is still sort of a tinkerer's tool[0]. I really hope it gets more adoption, though. Until then, we're going to be using React 16+. [0] https://trends.google.com/trends/explore?date=all&geo=US&q=svelte%20tutorial,react%20tutorial https://trends.google.com/trends/explore?date=all&geo=US&q=s...
wyqydsyq 6y ago
I really do not understand the appeal of Svelte, it seems to be making all the same horrendous mistakes as Vue (bad templating/DSL that shoehorns control flow and bindings into DOM representation, esoteric lifecycle hooks etc) and the only advantage it clearly has over other frameworks that I can see is simple components can generally be written more concisely. Are there actually any tangible benefits to using it over other frameworks, or is this all just a heap of people getting excited because it's "new and shiny" (compared to React, Angular etc)?
- voiper1 6y ago
  Tangible benefits? It's simple.
  - wyqydsyq 6y ago
    I would argue requiring your whole team to learn a new framework-specific templating language and patterns is not simple, compared to using something that is plain JS/TS which the whole team already knows. It also complicates hiring, as programmers who know JS/TS and can pick up React/Angular/etc are a dime a dozen, in contrast to trying to hire programmers to work with a niche framework which has a lot of domain specific knowledge.
    - voiper1 6y ago
      It sounds like you are claiming that it's easier for a javascript Dev to learn react than svelte. Sure, there's more devs who currently know react. But "easier to learn react" is crazy. The svelte tutorial is short and awesome.
- madacol 6y ago
  - Instead of virtual dom + diffing, svelte applies direct DOM manipulation exactly where needed - Smaller code size. No loading of general runtime library, and I've heard people argue that each component(or page) has its own runtime (I may be wrong in the details) - Many common tools are built-in, like stores and animations, and since there's no general runtime, if you don't use a particular tool, it doesn't get included - For beginners, the tutorial is a blessing, they can pick up the framework while learning Js on-the-fly (I'm doing this with my nephew)
fermienrico 6y ago
What are the downsides or criticisms of Svelte? This whole thread is like a giant bandwagon. Typical of JS crowd. 3 years later, everyone is going to jump on the next one.
himujjal 6y ago
Svelte gives us a host of possibilities because of it being compile time. Its the perfect UI language. Think about it. You can write anything in the script part. Lets say you have a Go UI framework. Write Go code inside script tag and use the template to produce UI elements for TUI apps, for desktop apps without even working hard to manage state, manage UI element paradigms. The simple reactive style of programming can be used. Of course a different compiler can be used. But the possibilities are open. With React and stuff that's kind of difficult. You will eventually end up writing original Go code. And currently you can compile Svelte components into React/Preact etc. Its not production quality. But its possible. (Svelte2TSX makes it possible)
kabes 6y ago
I never got the appeal of state management in React. People now seem to rave about Svelte, because you can just do 'count += 1'. But you could do exactly this already in Angularjs (which, just like Svelte, had a template language). Ok, Angularjs worked different under-the-hood than Svelte. It was a dirty checking loop instead of compiler-generated change indicators, which didn't scale as well. But other than this scaling issue, the ergonomics were very similar. But in the meanwhile the React folks started this whole idea that this mutable state was a bad idea and people seemed to blindly believe the React way was going to be the silver bullet. The widely acclaimed Dan Abramov launched Redux, one of the most cumbersome, boiler-plate-heavy state management systems I've ever had the displeasure of using. And with react hooks there are more performance pitfalls than there ever were with Angularjs. So now everyone seems to realize that they lost quite some convenience with React. React had a good run, but it's time to move on.
- padolsey 6y ago
  What perf issue have you spotted with hooks? My biggest bugbear with them is just the sheer cognitive exhaustion that comes with figuring out "when" stuff is happening -- especially if you're implementing a bunch of your own useEffects. I remember just sitting there bemused by the complexity -- and the difficulty of debugging ostensibly simple state changes. I (truly!) miss the good old days of intuitely doing count+=1 in a mess of procedural DHTML... so for that reason alone Svelte is a breath of fresh air.
  - kabes 6y ago
    For example passing down a function which is not memoized can trigger a bunch of non-obvious side effects lower in the component tree when your component re-renders. I feel like with hooks/functional components I need to think way more about stuff like that. Which comes down to your point: cognitive exhaustion. The promise of hooks and functional components was that it would make things 'easier to reason about' (among other things). But we all know now that this is just not the case in practice.
- j-krieger 6y ago
  It's because react works with immutable state. Svelte instead opts for compile-time magicks to handle state. Angular uses decorators to manage state. This has turned out to be an unwise descision because javascript decorators have changed in spec since then.
itsbits 6y ago
I have been maintaining some Svelte components. But as many of them here, my profession is in React as of now. One of things Author didn't directly point out is about JSX. I mean you can build JSX of a component incrementally in your component code. But that's something I am missing in Svelte.
- The_rationalist 6y ago
  What are some uses cases for it? I always thought that was polluting the class business logic with what should just be subcomponents? Anyway Stencil is very similar to svelte and support TSX
meekaaku 6y ago
How come I rarely see mention of Aurelia when discussing JS frameworks? Aurelia 2 will be out soon, and I find things well thought out even in v1. You basically write just html and pretty much plain javascript. It is batteries included with DI/router/Event listener/validation etc.
vavhust 6y ago
BTW https://pomod.one https://pomod.one doesn't work correctly in Safari (when the tab is inactive for a long time) - count down stops.
The_rationalist 6y ago
Would love to see a comparison of stencil and react
cluoma 6y ago
I went with Svelte for my first side-project[1], having never touched a frontend framework or used Javascript before. The experience was actually really nice. Obviously I don't know how it compares to other options out there, but it was a pretty enjoyable experience overall. I felt like I was able to do exactly what I wanted and wasn't missing anything. [1]: https://squidpoll.com/ https://squidpoll.com/
lukasbuenger 6y ago
This is meta and me venting: I stumbled upon this article a couple of days ago when it was featured on the last issue of Javascript Weekly (19.3.21) and thoroughly enjoyed reading it. The points made in this piece are soundly argued while never hiding the fact that they're ultimately based on one individuals perspective. Couple of days later and in line with my usual HN-reading MO (and not remembering the title of said article, it is quite generic) I'm looking at the headline of this post and my mind immediately goes «Yeah, I definitely want to read those comments, if only for shits and giggles». And boy was I not disappointed: It starts off with «I love X because I hate Y», continues with Y implicitly being understood as a function of «Y + 3rd party Z» (and what's not to hate about bloody Z as if that's not a self-inflicted liability) and ends with library authors digressing into low-level technicalities, which, ironically, both X and Y are trying to simplify in the first place, so that ordinary product-shipping folks like the author of the original article and myself can focus on the task at hand: Getting shit done. It really feels like everyone on here was just desperately waiting for a hook to talk about either their personal preference or their specific set of problem domains instead of adding value to an admittedly mundane but very concise piece of writing. It probably speaks volumes about my naivety that, after all these years of digesting HN on a daily basis, I still somehow assume that both the subject matter and the tone of a given piece might actually correlate with the reactions to it. Then again, as I said, I came here for shits and giggles, so, if I'm perfectly honest, I kind of knew all along.
fishbone 6y ago
I work with Vue every day at my day job and I spent about 200 hours on the side building an online Svelte course. I really enjoyed the syntax and readability of .svelte files. Local dev environment was a great developer experience and the lack of boiler plate was nice coming from a Vue background. I built an SPA with an Express backend and my biggest complaint was the lack of an official front end router. The community based router libraries had lots of issues and quirks and I didn’t want to lock into using Sapper at the time. Svelte itself was rock solid though and I look forward to trying Sveltekit (think Next.js for Svelte) in the future. Anyway, here comes the shameless self promotion: https://www.newline.co/courses/fullstack-svelte https://www.newline.co/courses/fullstack-svelte
wildermuthn 6y ago
Svelte has made the classic mistake of creating a template-based framework, which inevitable leads to a DSL, then to a miniature programming language, then to a nightmare of incidental complexity. React won for a lot of reasons, but near the top of the list is JSX. JSX is not a templating language, it’s just syntactic sugar for plain JavaScript. I never have to wonder what new features have been added to JSX, I never have to struggle with extensions to JSX that some 3rd-party library depends upon. Template-based frameworks are akin to Lisp reader macros, and this is especially true for Svelte in that it is a compiler. But reader macros will kill a language’s ecosystem quickly, in that they break composability. JSX was a clear winner over Angular’s directives for exactly this reason. Svelte has some cool ideas, but regressing back to another Handlebars or Mustache isn’t one of them.

293 points by feross 6y ago

k__ 6y ago

Half-OT: Svelte seems to be the pinnacle of the "bundling era" of frontend frameworks. What do you think comes next? XYZ-to-WASM? Back the roots with (non-)bundlers like Skypack? Anyone heard of next-gen experiments in that directions?

hypermachine 6y ago
We are actually going the other direction. Currently I am experimenting with making a Blazor/Liveview (HTML over wire) runtime that can support many programming languages. And a GUI builder.
- sali0 6y ago
  This sounds fascinating. Anywhere I can read about it?
  - hypermachine 6y ago
    The UI builder and libraries are still heavily WIP. Previously we were focused on making a VBA interpreter. For the HTML-over-wire part we are experimenting with a protobufs-based protocol so the backend runtime can support as many languages as possible. The most challenging part is that client-server UIs have fundamentally different assumptions about state, concurrency, and session handling compared to traditional desktop/mobile GUIs that operate on callbacks. Most of the design patterns used for your typical WinForms/Cocoa UI fail horribly in web scenarios (unless the entire app is running client side in WebAssembly) because state must be held in a DB, global variables are completely not allowed and multiple users may simultaneously access a service so any form of long-running loops or blocking code is very problematic. Serverless could help here but you will need long-running serverless containers. The current pricing models of AWS Fargate and Google Cloud Run are not compatible with this. This is additionally complicated by the fact that many languages have async/concurrency "bolted-on". It is hard to integrate a WebSockets server into the language if there is already another event loop to deal with. This is especially problematic for feature-fragmented languages like Python where async is a relatively new concept. (See https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...) Go is basically the gold standard here. Overall, we are still working on how to build the language-agnsotic backend SDKs without too much duplicate code. If you see similar systems like Streamlit and Plotly Dash, they avoid the problem entirely by making proxying the default way of embedding in third party applications. The integration is not as tight as traditional UI frameworks but avoids many of the problems with state management. For deployment, the Blazor/LiveView/HTML-over-wire format would also require CDNs that are as close to the end user as possible for lowest UI latency. Think Zeit/Vercel or Fly.io. There's a mailing list link below where you can be notified for when we launch: https://hypermachine.org https://hypermachine.org
fragile_frogs 6y ago
> XYZ-to-WASM There is yew (https://github.com/yewstack/yew https://github.com/yewstack/yew) which is a React inspired Rust framework that compiles to WASM.

pitaj 6y ago

I recently rewrote a small UI from Preact to Svelte and while it was certainly a learning experience, I have to say working with Svelte is fantastic. My only complaint is that the Typescript support isn't quite perfect yet, but it's already very functional.

Palmik 6y ago
I use Svelte + TypeScript in my personal projects, what issues did you run into?
- dhucerbin 6y ago
  Last I checked it was impossible to parametrize component type. In React you can write `<MenuSelect<User> users={...} />`.
  - patwoz 6y ago
    Please don't. It looks awful. And I think it's not necessary. Typescript should inherit it's type depending on what you are passing into "users".
    - efrafa 6y ago
      There are valid reason to do that. Like a component that takes render function and item that is passed into it that can be anything.
      - patwoz 6y ago
        You can do that, but you don't have to. See my example here at line 26: https://codesandbox.io/s/clever-neumann-89tnx?file=/src/App.tsx https://codesandbox.io/s/clever-neumann-89tnx?file=/src/App.... Typescript will inherit the type automatically.
        kecupochren 6y ago

pier25 6y ago

> I love Firebase Authentication, it's such an easy way to add auth to side projects. It's easy to use but it adds 55kB gzip to your project. https://bundlephobia.com/result?p=@firebase/auth@0.16.4 https://bundlephobia.com/result?p=@firebase/auth@0.16.4 A couple of comments on the Svelte code. 1) It doesn't makes much sense to use onMount() with listenForAuthChanges(). Just modify the currentUser writable whenever onAuthStateChanged() has an update. Now simply import and use $currentUser in your components. 2) You don't need to use currentUser.subscribe() from your .svelte files as you can use the reactive $: notation for this. You can, if it makes more sense to you, but I wouldn't say it's idiomatic.

ampdepolymerase 6y ago
Re 1) Where should you put the code to initialize the SDK? Code that ideally should only be ran once in the entire lifecycle of the page. For Firebase, will ES modules help with code splitting? The new Svelte kit framework is built by Vite (runs on ES build underneath).
- pier25 6y ago
  If you have code in say store.js it will triggered whenever the file is imported the first time. I also trigger init code from my entry point (eg: main.js).
- akiselev 6y ago
  I use a dynamic `import()` in the login form submit handler with an initialization flag. Code splitting is handled by the bundler

Greek0 6y ago

The author praises Firebase Auth for its ease-of-integration, but I'm leery of depending on Google products due to its support horror stories. Can anyone recommend good, easy-to-integrate alternatives?

dimgl 6y ago
I've always wanted to try Auth0 and I've heard great things! I would love to hear if anyone has had a positive experience with Auth0 as well.
- maxrev17 6y ago
  Positive exp with auth0, though if you can afford to control this stuff yourself maybe I'd lean that way.
- tehbeard 6y ago
  Another positive experience with Auth0, if a little finicky in my usecase (using it as a SAML IDP for testing). They have recently been bought out by Okta... Which by some accounts might not be a good move.
- presentation 6y ago
  My experience is that if you use it how they want you to use it (as a separate page hosted by them) then it’s simple and easy to use, but if you want to embed it they go out of your way to make your life painful. We took the latter route since we care about our UX and probably would have been better off if we just rolled it all ourselves.
nicoburns 6y ago
Do you need social logins? If not (and you just want email/password login) then implement it yourself. Auth isn't hard, and Firebase Auth doesn't provide you much in terms of managing roles/permissions or anything like that.
- movedx 6y ago

framecowbird 6y ago

Javascript n00b question... is there any difference between onMount(() => { return listenForAuthChanges() }) and onMount(() => listenForAuthChanges()) ?

oplav 6y ago
No, they are functionally the same.
rahulpadalkar 6y ago
no
jfengel 6y ago
They are the same. It's a matter of style. For that matter, you could also write: onMount(listenForAuthChanges) which is technically simpler -- you're not constructing a new anonymous function. But if you wanted to extend the code (to say, add a console.log), you'd need to do the top version, which already has the braces. It's up to your judgment of what's clearer and likely to be more maintainable.
- brundolf 6y ago
  This is a utility function I carry around between projects for the "logging within a pure expression" case: function log(expr) { console.log(expr); return expr; } onMount(() => log(listenForAuthChanges()))
- M2Ys4U 6y ago
  That may be visually simpler, but if onMount were to start passing a parameter to its callback in a future version (for whatever reason) then that will be passed to listenForAuthChanges. Using the anonymous function means that wouldn't happen.
- hoten 6y ago
  That should work in the provided example, but in general `fn(cb)` is different: you lose the implied `this` binding unless you do `cb.bind(something)` beforehand. There's also some unexpected trouble due to potential extra parameters. Consider the output of ['1', '2', '3'].map(parseInt) gives: [1, NaN, NaN] So yea, fn(() => cb()) is the same as fn(() => {return cb()}) – just syntactic sugar when the anonymous function has just one statement. but fn(cb) is semantically different.

Glench 6y ago

Great concrete comparisons in this article. I no longer use React in my projects and only use Svelte and it feels great. I'm very happy with it.

alfonsodev 6y ago

> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local state (useState) Then using Controller pattern, within the controller I use 4 types of hooks, 1 navigation (useHistory), 2 read global state (useSelector), 3 dispatch an action (useDispatch), 4 useEffect() to execute on props change or component mount. That's it, that's where the realm of React and UI ends for me, everything else is in Ducks, Ducks are single file or folder per module that contains Actions, Epics (Obervables) or Sagas (generators), Reducers, initial state of store and Typescript types. I really like this separation of concerns: - dumb components: to worry just about the looks and local state. - controllers: to worry about data in, actions out, life cycle and navigation. - Ducks: Management of data fetching and global state. I wrote this from the top of my head, but if anyone is interested I'm thinking about writing a demo repository and document this approach, maybe others have done it already this is not new, but practices that I've been collecting along the way.

deleted 6y ago
[deleted]
protonimitate 6y ago
> a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. As an fyi for anyone not aware, there are eslint/tslint plugins for this to help avoid it.
- wbobeirne 6y ago
  100% this, I often find myself getting tripped up when reading people's complaints about the JS / React ecosystem until I remember that TypeScript and the ESLint (and typescript-eslint and eslint-plugin-react) recommended config isn't standard in everyone's projects. It saves you from a ton of these headaches. Not that the answer to a complaint of a complex toolchain is more tools in the chain, but it's a wonderful development experience once you develop a collection of tools you really like.

tubbyjr 6y ago

There needs to be a 'fun' in 'svelte' somewhere, because it actually makes front-end devving... dare I say, fun and enjoyable.

deleted 6y ago

[deleted]

zem 6y ago

i'm just getting into front-end programming, and my (perhaps unfair) impression of react was that it was "bloated", so i stayed away from it. i've played a tiny bit with svelte and loved it though, i'm hoping to get a PWA up and running with it and invest a lot more heavily into learning the ecosystem if that's a good experience.

trafnar 6y ago

Is it necessary to use a worker for the timer? If you just record the start time, then inconsistent setTimeout calls aren't a problem because each call calculates the duration from start time to current time. Or am I missing something?

akdor1154 6y ago
You can work out that your 25 minute timer actually took 30 minutes this way, but you can't fix it to make it actually take 25 minutes.
dceddia 6y ago
Yeah, but I think putting it in the worker was about making the timer able to “go off” at a specific time, while the page is backgrounded.
fragile_frogs 6y ago
HTTP 203 has a great video about counters (https://www.youtube.com/watch?v=MCi6AZMkxcU)which https://www.youtube.com/watch?v=MCi6AZMkxcU)which goes into more details about why counters/timers are a bit more complex.

Vinnl 6y ago

How's unit testing in Svelte today? That's the main worry I have with template-based systems (well, that and TypeScript support, but I hear that that's quite OK now).

dfrsol 6y ago
It's still the glaring hole in the ecosystem.
dceddia 6y ago
There’s svelte-testing-library [0] which follows the same approach as the React flavor. It emphasizes testing the app “as the user would use it”, which boils down to rendering components and inspecting the DOM. They intentionally don’t give you visibility into the internal state of the component, which can be weird to get used to if you’re used to doing things like “click the button; assert that state isClicked became true”, but it tends to result in less brittle tests. 0: https://testing-library.com/docs/svelte-testing-library/intro/ https://testing-library.com/docs/svelte-testing-library/intr...
- Vinnl 6y ago
  Thanks, that looks pretty good, and testing-library is excellent. I couldn't find it in the docs, but do you know how this "renders" the Svelte components - in memory using e.g. jsdom, or by firing up a full-fledged browser? (The former would be highly preferable.)
  - dceddia 6y ago
    Testing-library uses jsdom across the board, as far as I know. It might support running in a full browser too but I haven’t used it that way. For end-to-end tests with a real browser, Cypress is a good option.
    - Vinnl 6y ago
      Cool, sounds like it should be in a usable state then.

beaconstudios 6y ago

The svelte approach of implementing better paradigms using compilation rather than using abstractions just seems infinitely better, and a better way to scale up a program in general. I do wonder why this idea never caught on; I think Alan Kay was investigating building a programming platform based on this idea but that's just academic.

amelius 6y ago
It's kind of funny that a NYT graphic designer (Rich Harris) outsmarted so many CS academics in finding the right software engineering tools.
- beaconstudios 6y ago
  Experts seem to suffer so often from myopia. Sometimes all it takes is a fresh perspective to glean a new idea.
- raihansaputra 6y ago
  I think it's an academics vs practitioners thing. Rich is willing and can use Svelte and Svelte/kit in actual production workloads in NYT. Kind of similar in how most Rails abstractions are pulled out from Basecamp's implementation. Doesn't hurt that Rails HEAD is directly used (in % deploy) by Shopify etc too.
preommr 6y ago
Because these tools were made in a time where people were using libraries like jquery. People were building js apps by including libraries directly in the header. Before webpack, and even gulp, when having a build process was a novel thing in web dev.

IshKebab 6y ago

No mention of Typescript. You'd be mad to consider writing a significant app without it, and React has really great Typescript support - even templates are type checked properly thanks to JSX/TSX, and basically all tools support JSX these days. Vue doesn't come close to that, but it does look like Svelte is at least a bit better: https://svelte.dev/blog/svelte-and-typescript https://svelte.dev/blog/svelte-and-typescript I'd still be wary that there are big caveats though. React was designed for Typescript. Javascript projects that bolt it on later tend to have issues.

nsonha 6y ago
> React was designed for Typescript this isn't true but JSX was made to be "just js" (obviously isn't true either) which contributes to it.
presentation 6y ago
The one place where react typings are disappointing to me is that all elements are typed as JSX.Element, meaning you can’t assert a specific type of child element. Usually not a big deal but would be useful in a number of cases.
- nsonha 6y ago
  It's a limitation of TS, not react. Flow for example can type elements more accurately.
jansan 6y ago
>No mention of Typescript. You'd be mad to consider writing a significant app without it, Thanks for calling me mad :)
brailsafe 6y ago
> Vue doesn't come close to that > thanks to JSX/TSX, and basically all tools support JSX these days I haven't used TS and Vue together, but Vue 3 seems to have been written with TS, as well as having supported JSX for quite a while. What are the limitations?

deckard1 6y ago

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed their mind at least 3 times on the API and none of it fits together today. Hooks and classes don't mix, lifecycle methods are still out there and just as confusing today as they were years ago. Mixing state and functions. It's just a horrible bag of half-baked bad ideas. And it's not even batteries included. Svelte has it all built-in. It has the equivalent of CSS modules. It has global reactive state and an incredibly simple state protocol that seems almost stupid if you're coming from Redux. You step out of your daze and realize you don't need all the rituals and boilerplate. The things I've seen built on top of that simple protocol can be incredible. It's not magic. It's just JavaScript. I dare say that Svelte is a joy. But I hesitate to even leave this comment here. Because I know the architecture astronauts are listening, eager to sink their claws into this simple elegant new thing and fill up their Github profiles with soon-to-be abandonware cruft which they will use to pad out article after Medium article which will all pour down upon Hacker News like a shit typhoon. Prodding us to join their cult of Svelte+RxJS. Or Svelte Sagas. Or their random dogma they toss into a giant bucket labeled "Svelte best practices." And, of course, "Ten ways you are doing Svelte wrong." I might be a little bit cynical.

Aeolun 6y ago
Have you ever worked on very large React applications without Redux or Saga? I just cannot imagine any other way of keeping my application sort of understandable.
- buzzerbetrayed 6y ago
  You should look at svelte stores if you haven’t already. They are amazing, and make redux seem so needlessly complex and ineloquent
alfonsodev 6y ago
I think many people adopted React because Facebook was behind it, and using it in production, the ecosystem is huge, there is a react- package for everything you can image, there is also react-native, I don't like it, but there it is, you can reuse the knowledge to build native mobile apps. Now Svelte, I haven't been following, but I think the creators are working in what's going to be next and even better framework[1], to your point of things in Svelte not changing as much as in React, maybe it just a matter of time. Here is the video I had in my bookmarks for a while, I still couldn't make the time to watch, so I hope my comment is not too far from reality. [1]https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s https://www.youtube.com/watch?v=qSfdtmcZ4d0&t=875s

sandreas 6y ago

Since svelte does a lot of compile time stuff, I would like to mention Routify, which is compile time SPA routing. For me it worked awesome to accomplish projects with many routes and the need for hash based routing. See https://routify.dev/ https://routify.dev/ and https://routify.dev/guide/installation/install-to-existing-project https://routify.dev/guide/installation/install-to-existing-p...

davidwparker 6y ago

I wrote my first decent size Svelte app (with a Rails API app backend) last year: https://www.listenaddict.com/ https://www.listenaddict.com/ Of course, what you see is just a tip of the iceberg, having implemented a nice admin and moderator dashboard, keyboard shortcuts, animations, 12 different color themes (in light and dark mode), and more. Svelte just made it all so easy to do. Having done a good bit of React and Angular professionally, and tinkered with Vue, I can safely say (for now) that all I want to do is Svelte. The rest just seem so heavy handed in comparison. Self promotion: I also run a YouTube channel where I'm slowly building out a Svelte app with Rails API backend. If you're interested in Svelte, please check it out: https://www.youtube.com/user/iamdavidwparker https://www.youtube.com/user/iamdavidwparker

abraxas 6y ago
Your site is brilliant and works really well. I’m also going to check out your YouTube channel.
- davidwparker 6y ago
  Appreciate it!
- gonzus 6y ago
  Seconded. I am a back end developer and had a lot of fun watching your Svelte Sapper series; thanks for your work! Quick question: which color scheme are you using in VSCode? It looks a lot like jellybeans for vim, which I love.
  - davidwparker 6y ago
    Thanks! I think I'm just using the default dark color theme. (dark+)
rikroots 6y ago
Same here. I've used Svelte on two reasonably hefty personal project sites[1][2] and was pleasantly surprised by how easy they were to build and (now) maintain. The one issue I had with Svelte was Sapper - I didn't get on with it (it wasn't a good fit for either of my projects). SvelteKit was released in beta a couple of days ago - I've no idea how much that changes things. I'm hoping I don't have to relearn a whole bunch of stuff to use the new shiny. [1] - https://rikverse2020.rikweb.org.uk/ https://rikverse2020.rikweb.org.uk/ (Warning: Poetry!) [2] - https://scrawl-v8.rikweb.org.uk/ https://scrawl-v8.rikweb.org.uk/ - I was quite proud about getting my canvas library to play nicely with Svelte

jeswin 6y ago

I think it's a misunderstanding that Svelte is fast because it is "compiled" into imperative DOM updates. This is partly because the documentation says so, and the early blog posts emphasized this aspect. Compilation actually has nothing to do with it. Svelte is fast because it doesn't do all the Virtual DOM stuff, and the DOM diffing. You could very well build Svelte as a library without the compiler, and it would be just as fast. But the compiler helps a bit with the ergonomics - it's cleaner to do count+=1, rather than setState({count:count+1}).

TehShrike 6y ago
The compiler turns 20 lines of runtime code into 2 lines of runtime code. The performance effects are real!
leeman2016 6y ago
Due to compilation, bundle size gets a lot smaller which will boost start-up/load time.
hajile 6y ago
I believe infernoJS complete with vdom still matches and even exceeds on most metrics. Last I checked, svelte compiled different code paths for every single component. This means that most DOM manipulations in real-world applications (not micro benchmarks using the same components repeatedly) won’t ever optimize in Svelte. Meanwhile, the vdom code runs constantly and is hand-tuned to help ensure deopts don’t happen. Likewise, potential optimizations to reuse old nodes and other “garbage” are much easier to implement with a unified DOM implementation. Finally, once you implement the vdom once, you don’t do it again. With Svelte, your code is recreated for every component. This may give smaller component in the short term, but there’s an inflection point (and it’s in the small-medium range) where svelte starts shipping more code for the same work.

alphachloride 6y ago

Svelte and React each have their advantages and they make a convincing case each for the #2 position for a Javascript framework.

jrib 6y ago
I'll bite: what's your #1?
- alphachloride 6y ago
  Plain ol' vanilla javascript, of course.

wzy 6y ago

When compared to Svelte, it's like React developers wake up every day and choose complexity.

nsonha 6y ago
It's actually very simple. React devs choose to write code in code. People of other frameworks write code in code and templates, which, to react devs, is complexity.

kushan2020 6y ago

Great comparison writeup! However, I do feel some of the points made are weak and seem to be rushing to conclusion. In the React hook worker code you do not really need to use the `ref` and you can do something like: ``` function useWorker(currentUser, setCurrentPom) { const [worker] = useState(() => new Worker(workerURL)) useEffect(() => { const onMessage = (event) => { if (event.data.name === 'tick') { setCurrentPom((currentPom) => ({ ...currentPom, secondsRemaining: event.data.counter, })) } else if (event.data.name === 'start') { // More branches removed here to save space... } } worker.addEventListener('message', onMessage) return () => { worker.removeEventListener('message', onMessage) } }, [currentUser, setCurrentPom]) return worker } ``` The reason it works is that `useState` allows you to lazy load something. You mention two points which make svelte easier, but I would challenge you on those: > We don't have to keep the worker in useRef, and can just assign it to a variable. As per my thoughts above you do not need useRef, in fact you just separated the whole worker logic into a separate function which gives us separation of concern and better readability. > We can pull the event listener code out into a function more easily, as that function won't then become a dependency to a useEffect - at which point we will have to wrap it in useCallback. I am not sure I fully understand this. But if you are talking about wrapping the event listener code into a function, you can do that and you do not need to wrap it in a callback. Though, I am not sure what we gain out of abstracting the event handling part.

anonytrary 6y ago

1. Community support. Svelte I think is the "more technically correct" approach, but React 16+ is good enough, concise enough, and it has thousands of community packages already. Svelte still needs way more buy-in for it to be a serious option at our company. We actually implemented a small part of our app in Svelte, but moved away from it because Svelte is still sort of a tinkerer's tool[0]. I really hope it gets more adoption, though. Until then, we're going to be using React 16+. [0] https://trends.google.com/trends/explore?date=all&geo=US&q=svelte%20tutorial,react%20tutorial https://trends.google.com/trends/explore?date=all&geo=US&q=s...

wyqydsyq 6y ago

I really do not understand the appeal of Svelte, it seems to be making all the same horrendous mistakes as Vue (bad templating/DSL that shoehorns control flow and bindings into DOM representation, esoteric lifecycle hooks etc) and the only advantage it clearly has over other frameworks that I can see is simple components can generally be written more concisely. Are there actually any tangible benefits to using it over other frameworks, or is this all just a heap of people getting excited because it's "new and shiny" (compared to React, Angular etc)?

voiper1 6y ago
Tangible benefits? It's simple.
- wyqydsyq 6y ago
  I would argue requiring your whole team to learn a new framework-specific templating language and patterns is not simple, compared to using something that is plain JS/TS which the whole team already knows. It also complicates hiring, as programmers who know JS/TS and can pick up React/Angular/etc are a dime a dozen, in contrast to trying to hire programmers to work with a niche framework which has a lot of domain specific knowledge.
  - voiper1 6y ago
    It sounds like you are claiming that it's easier for a javascript Dev to learn react than svelte. Sure, there's more devs who currently know react. But "easier to learn react" is crazy. The svelte tutorial is short and awesome.
madacol 6y ago
- Instead of virtual dom + diffing, svelte applies direct DOM manipulation exactly where needed - Smaller code size. No loading of general runtime library, and I've heard people argue that each component(or page) has its own runtime (I may be wrong in the details) - Many common tools are built-in, like stores and animations, and since there's no general runtime, if you don't use a particular tool, it doesn't get included - For beginners, the tutorial is a blessing, they can pick up the framework while learning Js on-the-fly (I'm doing this with my nephew)

fermienrico 6y ago

What are the downsides or criticisms of Svelte? This whole thread is like a giant bandwagon. Typical of JS crowd. 3 years later, everyone is going to jump on the next one.

himujjal 6y ago

Svelte gives us a host of possibilities because of it being compile time. Its the perfect UI language. Think about it. You can write anything in the script part. Lets say you have a Go UI framework. Write Go code inside script tag and use the template to produce UI elements for TUI apps, for desktop apps without even working hard to manage state, manage UI element paradigms. The simple reactive style of programming can be used. Of course a different compiler can be used. But the possibilities are open. With React and stuff that's kind of difficult. You will eventually end up writing original Go code. And currently you can compile Svelte components into React/Preact etc. Its not production quality. But its possible. (Svelte2TSX makes it possible)

kabes 6y ago

I never got the appeal of state management in React. People now seem to rave about Svelte, because you can just do 'count += 1'. But you could do exactly this already in Angularjs (which, just like Svelte, had a template language). Ok, Angularjs worked different under-the-hood than Svelte. It was a dirty checking loop instead of compiler-generated change indicators, which didn't scale as well. But other than this scaling issue, the ergonomics were very similar. But in the meanwhile the React folks started this whole idea that this mutable state was a bad idea and people seemed to blindly believe the React way was going to be the silver bullet. The widely acclaimed Dan Abramov launched Redux, one of the most cumbersome, boiler-plate-heavy state management systems I've ever had the displeasure of using. And with react hooks there are more performance pitfalls than there ever were with Angularjs. So now everyone seems to realize that they lost quite some convenience with React. React had a good run, but it's time to move on.

padolsey 6y ago
What perf issue have you spotted with hooks? My biggest bugbear with them is just the sheer cognitive exhaustion that comes with figuring out "when" stuff is happening -- especially if you're implementing a bunch of your own useEffects. I remember just sitting there bemused by the complexity -- and the difficulty of debugging ostensibly simple state changes. I (truly!) miss the good old days of intuitely doing count+=1 in a mess of procedural DHTML... so for that reason alone Svelte is a breath of fresh air.
- kabes 6y ago
  For example passing down a function which is not memoized can trigger a bunch of non-obvious side effects lower in the component tree when your component re-renders. I feel like with hooks/functional components I need to think way more about stuff like that. Which comes down to your point: cognitive exhaustion. The promise of hooks and functional components was that it would make things 'easier to reason about' (among other things). But we all know now that this is just not the case in practice.
j-krieger 6y ago
It's because react works with immutable state. Svelte instead opts for compile-time magicks to handle state. Angular uses decorators to manage state. This has turned out to be an unwise descision because javascript decorators have changed in spec since then.

itsbits 6y ago

I have been maintaining some Svelte components. But as many of them here, my profession is in React as of now. One of things Author didn't directly point out is about JSX. I mean you can build JSX of a component incrementally in your component code. But that's something I am missing in Svelte.

The_rationalist 6y ago
What are some uses cases for it? I always thought that was polluting the class business logic with what should just be subcomponents? Anyway Stencil is very similar to svelte and support TSX

meekaaku 6y ago

How come I rarely see mention of Aurelia when discussing JS frameworks? Aurelia 2 will be out soon, and I find things well thought out even in v1. You basically write just html and pretty much plain javascript. It is batteries included with DI/router/Event listener/validation etc.

vavhust 6y ago

BTW https://pomod.one https://pomod.one doesn't work correctly in Safari (when the tab is inactive for a long time) - count down stops.

The_rationalist 6y ago

Would love to see a comparison of stencil and react

cluoma 6y ago

I went with Svelte for my first side-project[1], having never touched a frontend framework or used Javascript before. The experience was actually really nice. Obviously I don't know how it compares to other options out there, but it was a pretty enjoyable experience overall. I felt like I was able to do exactly what I wanted and wasn't missing anything. [1]: https://squidpoll.com/ https://squidpoll.com/

lukasbuenger 6y ago

This is meta and me venting: I stumbled upon this article a couple of days ago when it was featured on the last issue of Javascript Weekly (19.3.21) and thoroughly enjoyed reading it. The points made in this piece are soundly argued while never hiding the fact that they're ultimately based on one individuals perspective. Couple of days later and in line with my usual HN-reading MO (and not remembering the title of said article, it is quite generic) I'm looking at the headline of this post and my mind immediately goes «Yeah, I definitely want to read those comments, if only for shits and giggles». And boy was I not disappointed: It starts off with «I love X because I hate Y», continues with Y implicitly being understood as a function of «Y + 3rd party Z» (and what's not to hate about bloody Z as if that's not a self-inflicted liability) and ends with library authors digressing into low-level technicalities, which, ironically, both X and Y are trying to simplify in the first place, so that ordinary product-shipping folks like the author of the original article and myself can focus on the task at hand: Getting shit done. It really feels like everyone on here was just desperately waiting for a hook to talk about either their personal preference or their specific set of problem domains instead of adding value to an admittedly mundane but very concise piece of writing. It probably speaks volumes about my naivety that, after all these years of digesting HN on a daily basis, I still somehow assume that both the subject matter and the tone of a given piece might actually correlate with the reactions to it. Then again, as I said, I came here for shits and giggles, so, if I'm perfectly honest, I kind of knew all along.

fishbone 6y ago

I work with Vue every day at my day job and I spent about 200 hours on the side building an online Svelte course. I really enjoyed the syntax and readability of .svelte files. Local dev environment was a great developer experience and the lack of boiler plate was nice coming from a Vue background. I built an SPA with an Express backend and my biggest complaint was the lack of an official front end router. The community based router libraries had lots of issues and quirks and I didn’t want to lock into using Sapper at the time. Svelte itself was rock solid though and I look forward to trying Sveltekit (think Next.js for Svelte) in the future. Anyway, here comes the shameless self promotion: https://www.newline.co/courses/fullstack-svelte https://www.newline.co/courses/fullstack-svelte

wildermuthn 6y ago

Svelte has made the classic mistake of creating a template-based framework, which inevitable leads to a DSL, then to a miniature programming language, then to a nightmare of incidental complexity. React won for a lot of reasons, but near the top of the list is JSX. JSX is not a templating language, it’s just syntactic sugar for plain JavaScript. I never have to wonder what new features have been added to JSX, I never have to struggle with extensions to JSX that some 3rd-party library depends upon. Template-based frameworks are akin to Lisp reader macros, and this is especially true for Svelte in that it is a compiler. But reader macros will kill a language’s ecosystem quickly, in that they break composability. JSX was a clear winner over Angular’s directives for exactly this reason. Svelte has some cool ideas, but regressing back to another Handlebars or Mustache isn’t one of them.