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…
Why Svelte is our choice for a large web project
71–80 of 136 posts
Re: Why Svelte is our choice for a large web project
#72I 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.
Re: Why Svelte is our choice for a large web project
#73I 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…
Re: Why Svelte is our choice for a large web project
#74I 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…
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
#75I 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
#76There 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
#77I 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.
Re: Why Svelte is our choice for a large web project
#78Having 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…
Re: Why Svelte is our choice for a large web project
#79Having 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
#80Svelte 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.
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.