Why Svelte is our choice for a large web project • Hacker News Board

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

#31

Post by overtowed » Tue, Mar 10, 2020, 6:28 PM UTC

mulholio wrote: post #8

What I'd hoped to see here was why use Svelte for a large web project. I get the advantages, but devising and maintaining good architecture is hard enough in the more established React paradigm. What do complex and older Svelte apps look like? This is the part that's missing for me, not pleasant DX and early-web nostalgia.

Good question, thanks for asking it. I didn't explicitly address this (oops) and I'll have to do some more thinking. My first reaction is that:

1) Svelte gives you a solid foundation and lots of flexibility

2) difficulty scaling for large apps is mostly orthogonal to the component library

3) Svelte provides flexible and sugary integration points for these orthogonal concerns

For example, since we're talking large projects, the biggest concern is state management. Svelte is like React here, in that you could use MobX or Redux with a connector library, or RxJS with Redux, or other combinations. As long as your solution is compatible with stores like RxJS is, you benefit from Svelte's auto-subscriptions[1] and sugary store dereferencing[2] that's agnostic to your underlying state management solution.

[1] https://svelte.dev/examples#auto-subscriptions

[2] https://svelte.dev/examples#readable-stores

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

#32

Post by theslurmmustflo » Tue, Mar 10, 2020, 6:29 PM UTC

Use next.js the auto routing and ssr is a game changer, plus easy access to the huge react community

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

#33

Post by skrtskrt » Tue, Mar 10, 2020, 6:34 PM UTC

nlh wrote: post #7

I'm rapidly becoming a huge Svelte fan. Quick self-promotion plug (but in the name of altruism): I've been working on an open source project that glues together Svelte (on the front end) and Crystal (on the back end). https://github.com/noahlh/celestite Two slightly obscure (but growing) languages/frameworks, but hey, gotta pick a niche. Contributions & feedback welcome!

As someone kind of sitting on the sidelines waiting for Crystal to gain some traction before I dedicate time to learning/working with it, I appreciate you for digging in and moving things forward.

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

#34

Post by pier25 » Tue, Mar 10, 2020, 6:34 PM UTC

Jasper_ wrote: post #17

_prototype_ wrote: post #9

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.…

What's wrong with mutability?

Nothing IMO but a lot of folks argue that using immutable state and functional paradigm results in more predictable applications.

Not sure if all this immutability talk in the JS community is parroting because "it's what Facebooks does" or what. Maybe it makes sense once you are building really big front end projects but personally I've never had an issue with mutable state in small to medium sized projects (less than 50k LOCs). Although I admit I've never worked on a Facebook-scale kind of project.

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

#35

Post by ComputerGuru » Tue, Mar 10, 2020, 6:36 PM UTC

snapetom wrote: post #23

dzonga wrote: post #15

I love svelte. but now resorting to server rendered html pages with sprinkles of JS. shit I work on and I have noticed in the world doesn't really need frameworks like react, svelte, vue etc.

Same. I haven't done frontend work for a job for about a decade, but kept up to date with things like Angular/Vue/React. I was recently vountold by my wife to create a reunion site for her class. I looked up "barebones front end frameworks." Anything that began the "Getting Started" page with "npm install" I noped out of there. I ended up with Skeleton/jQuery for the front end and PHP Slim for the backend. This is a…

Someone on HN recommended it to me before, so I’ll just pass this along: look at intercooler JS for making individual “live widgets” on a well-designed graceful degradation site like you describe.

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

#36

Post by deckard1 » Tue, Mar 10, 2020, 6:41 PM UTC

TekMol wrote: 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 stack with a fraction of the headcount. The cost of a modern web dev stack is no joke. And for what, I might ask? The UX of a single page app is atrocious. The canonical example of SPA done right is Google Maps. Ever tried Google Maps on a mobile browser? There is a reason the native app still exists.

SPA is, at best, a desktop-first experience that we're trying to force into a mobile-first world we live. It's nearly the definition of insanity, what we're trying to do with the web today.

In the process of everyone following Google and Facebook, we are also destroying the essential ingredient of the web: links. Everything is a walled garden with internal state and incredibly fragile external links (if any at all). Pinterest and Quora, everywhere. What will define the web of the 2010-2020+ is that everything is broken and everything sucks.

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

#37

Post by choward » Tue, Mar 10, 2020, 6:42 PM UTC

> Svelte is one of the 6 JS frameworks in the (flawed) State of JS 2019 survey — 75% have heard of it, 7% have used it, and 45% are interested in learning more

Why is it flawed and why are you citing a flawed study? You mention that it's flawed twice but then immediately cite data from it. If you're telling me it's flawed why should I care about the data?

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

#38

Post by rich_harris » Tue, Mar 10, 2020, 6:47 PM UTC

_prototype_ wrote: post #9

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.…

That code appears nowhere in the documentation. Regardless, you appear to be confused about the meaning of the word 'mutable'.

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

#39

Post by krainboltgreene » Tue, Mar 10, 2020, 6:50 PM UTC

smithza wrote: post #20

Especially excited to consider a solution without huge runtime libraries (think jQuery, React, Vue). Minimizing web page sizes and enabling dynamic content (which is a mainstay in modern websites) is a huge plus.

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"?

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

#40

Post by rich_harris » Tue, Mar 10, 2020, 6:51 PM UTC

abledon wrote: post #29

does svelte have a way of hiding the .svelte components from the users on the frontend? e.g. so they cant blatantly rip the source code in your components and reuse them

Sure, it's easy: don't serve sourcemaps.

This isn't specific to Svelte though. In fact your code is much more obfuscated with Svelte than with most comparable tools, since you're not serving the code you actually wrote, but rather the output of a compiler (while this is technically true if you're using TypeScript/a minifier/whatever, it's qualitatively different).