Live data from Hacker News

Why Svelte is our choice for a large web project

github.com

71–80 of 136 posts

Re: Why Svelte is our choice for a large web project

#71
post #47

Earlier quoted context omitted.

React 16 is 2.2 KB or 34.8 KB if you include react-dom, Vue 2.4 is 20.9 KB, and jquery 2.1 is 28.87 KB. If you're using a bundler that can create chunks, your user is at best downloading this once in a blue moon. The reply page I'm using now is 10% bigger total than these packages and has to be pulled every time apparently. By what metric are these "huge runtime libraries"?

> React 16 is 2.2 KB or 34.8 KB if you include react-dom Gzipped. Uncompressed React is 6.3KB and react-dom is 114.5KB (and of course you're going to include react-dom, how else would you use it?!) Uncompressed matters because it takes a device longer to parse more code. Particularly in a world where low end Android devices are being shipped with slow CPUs and very little RAM. The real killer combination is React plu…

I use Preact for small apps and demos, works really well for that! For larger projects I still prefer the real React library because there are some edge cases where Preact does things differently (can’t remember what exactly but I remember that I ran into some problems when trying to migrate a large react codebase to it).

Re: Why Svelte is our choice for a large web project

#72
post #69

I dislike the templating pseudo language of Svelte (and many view frameworks). Maybe I am spoiled by react but I never ever want to write my view logic in anything else than JS. This is my main blocker for Svelte.

To my mind the templating language isn't that different to JSX, and all that. I agree that if and else statements feel a little less natural but for me it's more than worth the price of admission.

Re: Why Svelte is our choice for a large web project

#73
post #6

I have switched to pure HTML/CSS/Javascript for frontend. And I am very happy with it. I sometimes use external libraries. For example handlebars if I want to template something clientside. But no more frameworks. I think pure Javascript is plenty enough these days. For those who can't live without a framework: What would you miss?

Frameworks like React aren't the real headache today, for me at least. It's all the machinery of web development. Webpack, babel, polyfills, various CSS transforms and ways to utilize CSS (sass, less, CSS modules, CSS inline, the list is a mile long). My organization has tossed so many manhours into maintaining webpack and our build that you could recreate our entire site numerous times over in a bog standard LAMP st…

At the risk of sounding naive: what's the alternative?

Re: Why Svelte is our choice for a large web project

#74
post #24

I love React and I love Svelte. There, I said it. These are the complaints that standout for me with Svelte after using it for a few months: * Sub-par editor support. For me, the litmus test is whether I can use F2 to rename a variable, and it often does not work inside a Svelte template. There are other places where the editor does not know what to do with your code, because it is not pure JS. Vue is much worse with…

On your 2nd point, you can tell Svelte that your data is mutable, in which case it will do deep equality. However, the benefits of immutable data often mean it's worth just reassigning the variable.

I also wouldn't consider that a disadvantage vs React/Redux, since that also requires using immutable data.

Re: Why Svelte is our choice for a large web project

#75
For me, the biggest downside to Svelte is the lack of TypeScript support. This is a massive deal-breaker for myself as well as many other developers. I am also not a fan of the Moustache/Handlebars inspired templating, it feels outdated in the face of enhancing standard HTML or going in the direction of something more extreme like JSX.

I think Svelte is refreshing, but I would not be comfortable using it on a large-scale web application just yet given the downsides, particularly an enterprise LOB application with many moving pieces. This is why frameworks like Angular, Ember and Aurelia on the front-end lend themselves better to the enterprise and React and other more component-based libraries do not.

In terms of community size, I don't think that matters in 2020. You don't need a big community if you have something straightforward and easy to work with. Great read.

Re: Why Svelte is our choice for a large web project

#76
Having used Svelte for a couple of projects [1][2], I love it. Compared to my day job working in react/redux, it is much simpler, and feels like it has far less boilerplate.

There are certainly a few rough edges, but it's all related to the immaturity of the language. Specifically, I had a hard time understanding transitions and it wasn't at all obvious how to integrate it with D3. Hopefully as it grows we will see improved docs and examples.

Also, I'm holding out for more mainstream TypeScript support. At that point, it would be hard to convince me to use anything else.

[1] http://musetree.stevenwaterman.uk

[2] http://optimisation.stevenwaterman.uk + https://blog.scottlogic.com/2020/02/17/minesweeper-optimisat...

Re: Why Svelte is our choice for a large web project

#77
post #70

I enjoyed learning Svelte; it was fun to use when I rebuilt a personal project from scratch using it[1]. I'm trying to think of some downsides to balance my enthusiasm for the framework, but can't think of any. The article mentions the smaller community as a possible issue, but the community on Discord seem very welcoming. Re "using Svelte means adopting a new language" - it didn't feel like that to me. Every framewo…

> Re "using Svelte means adopting a new language" - it didn't feel like that to me. Me neither, but I've been around long enough to remember the handlebars.js days. To someone that's only used React I imagine that at first sight things like {#if} {/if} look ugly as hell. To those people I can only say to stick it out: it starts to feel very natural very quickly.

This was my experience. I've been working with Vue for the last few years so Svelte's syntax for loops and conditionals looked a bit funky...but after using it I realised that it's a lot more readable and enjoyable to work with.

Re: Why Svelte is our choice for a large web project

#78

Having used Svelte for a couple of projects [1][2], I love it. Compared to my day job working in react/redux, it is much simpler, and feels like it has far less boilerplate. There are certainly a few rough edges, but it's all related to the immaturity of the language. Specifically, I had a hard time understanding transitions and it wasn't at all obvious how to integrate it with D3. Hopefully as it grows we will see i…

FWIW, our new Redux Toolkit package is specifically designed to eliminate the typical "boilerplate" concerns when using Redux:

https://redux-toolkit.js.org

Re: Why Svelte is our choice for a large web project

#79

Having used Svelte for a couple of projects [1][2], I love it. Compared to my day job working in react/redux, it is much simpler, and feels like it has far less boilerplate. There are certainly a few rough edges, but it's all related to the immaturity of the language. Specifically, I had a hard time understanding transitions and it wasn't at all obvious how to integrate it with D3. Hopefully as it grows we will see i…

FWIW, our new Redux Toolkit package is specifically designed to eliminate the typical "boilerplate" concerns when using Redux: https://redux-toolkit.js.org

I do use Redux Toolkit, but it really can't compare to Svelte. There are so many moving parts in a Redux app that there's only so far it can be simplified

Re: Why Svelte is our choice for a large web project

#80

Svelte is absolute trash. It actively encourages mutability, which is a one way avenue to bugs bugs and more bugs. ie, shit like this is all over the official documentation: let mutable = 1; function f1() { onMount(() => { mutable = /* do some complex shit here */ }); } function f2() { onMount(() => { mutable = /* do some complex shit here */ }); } Complete non-deterministic state changes. Absolutely abhorrent stuff.…

I can't believe people use redux in any capacity but here we are.

Do you mind expanding on that?

I was thinking the same thing at first, why have this monstrous global state which is against every good practice you have ever heard of.

But then, if you want to keep state when switching between pages, you need to hoist up that state to the parent component. At some point, there's going to be a component near the root that keeps a lot of state for its children, that then has to be trickled down the component tree.

If you don't need to reuse those components in a different setting, then the redux solution feels quite ergonomic.

Now, this is coming from an embedded C programmer point of view, and this is my first foray into react/redux, so I'm obviously lacking context. But we're writing a front end for our embedded device, and I have to say I am pleasantly surprised with the experience.

Post reply on HN