Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Svelte is our choice for a large web project

github.com

Post reply on HN
Print view View original

51–60 of 136 posts

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

#51

Post by snapetom »

smt88 wrote: post #30
snapetom wrote: post #23

Earlier quoted context omitted.

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…

You seem to be refuting a straw-man argument here. Why would a hobby site provide a counter example for people talking about work they do for their employers? No rational person would advocate using Svelte or React for a static, one-off, informational site to be maintained by a single person. In fact, you didn't even need jQuery at all. Vanilla JS works across browsers in a way that it didn't when you learned web cod…

> No rational person would advocate using Svelte or React for a static, one-off, informational site to be maintained by a single person.

This is where we disagree, and I think that's the problem. In my use case, I just wanted an HTML template file with at most a few CSS files. There's a dearth of those frameworks/templates compared to bigger packages.

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

#52

Post by untog »

snapetom wrote: post #48
untog wrote: post #46

Earlier quoted context omitted.

> 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 So rather than install a dependency via a package manager you installed it manually. Okay.

Calling Skelton a dependency is ludicrous. It's just an HTML file with a CSS file. Look at every other "lightweight CSS framework" - Specture, Mustard UI, etc. They all have dozens and dozens of files where you need a package manager. The whole point was that it's simple enough that I don't have to deal with a package manager, and a lot of projects don't need to.

The whole point is that you choose an arbitrary thing to treat as a dealbreaker that doesn't really make a whole lot of sense. "npm install jquery" would have given you the exact same result you have, except it would have violated your dealbreaker. It just doesn't seem particularly logical to me.

To be honest, if you're going for "as simple as possible" there's no reason to use jQuery at all these days, it's a waste. Modern browsers have perfectly capable APIs!

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

#53

Post by snapetom »

ComputerGuru wrote: post #35
snapetom wrote: post #23

Earlier quoted context omitted.

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.

Haven't heard of that one. Thanks!

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

#54

Post by leejoramo »

I am on a team that has chosen Svelte to replace Riot.js. It has been an excellent experience. We have found that since Riot and Svelte have some similarities in structure and do not use a shadow DOM, we that our old Riot code and new Svelte code co-exist while we build new features and slowly migrate everything.

Our team has diverse experience with the other tools in this space. I would say that the consensus is that Svelte is far more intuitive and fun than other tools.

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

#55

Post by ratww »

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?

> For those who can't live without a framework: What would you miss?

The thing I miss the most is a good component and state abstraction. That's it.

I would be very happy using ASP.NET WebForms today: components are rendered 100% in the server but the state is persisted by the client using a field. The server can be 100% stateless.

Too bad it is impossible to convince anyone to pick up ASP.NET WebForms in 2020 :)

Modern backend frameworks such as Rails and Django have similar "component-ish" helpers, but those always fall short of the capabilities of both React/Vue and ASP.NET WebForms, and you have to worry about state by yourself.

Phoenix Live View is cool, but needs a stateful server, requires JS and polyfills up the wazoo. At this point I'd rather use Vue or React.

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

#56

Post by [deleted] »

Vinnl wrote: post #49

Ah, I mentioned it on Twitter [1] somewhat prompted by seeing this article, but before reading it, but: > It's interesting that Svelte is positioned as a Javascript framework: it seems to be practically a different language, far more so than JS+JSX. > The downside is that it's hard to integrate with much of the Javascript ecosystem, e.g. TypeScript. > Yet at the same time, it doesn't fully embrace being a different l…

[deleted]

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

#57

Post by krainboltgreene »

untog wrote: post #47
krainboltgreene wrote: post #39

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…

> Uncompressed matters because it takes a device longer to parse more code

This is...a trivial thing to measure, at best. Engineers write way worse code that will be much bigger targets to care about that will likely never be worked on.

> Particularly in a world where low end Android devices are being shipped with slow CPUs and very little RAM

The benchmarks for this (todomvc for example) aren't egregious, even for mobile devices.

> The real killer combination is React plus a giant blob of state that has to be parsed, and then hydrated into individual elements.

That is a bad end-engineer design choice, you don't have to write react that way.

> But people just don't seem to care.

Because they largely don't need to: Even if the end-engineer wrote and designed things in a performant way, it wouldn't account for the slowness of business process.

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

#58

Post by okareaman »

I watched a tutorial by the author Rich Harris today after reading this link on HN earlier and stopped when he started talking about a DSL he created for Svelte so you don't have to write as much JS. I don't want to learn another DSL. I don't see what the big deal is about compiling. We've have many languages that compile to JavaScript and Google Closure Compiler to tree shake and minify. For years now! Svelte is a nifty DSL to JS compiler that produces small bundles because there is no SDK to back it up or include. Cool, I guess.

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

#59

Post by untog »

krainboltgreene wrote: post #57
untog wrote: post #47

Earlier quoted context omitted.

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

> Uncompressed matters because it takes a device longer to parse more code This is...a trivial thing to measure, at best. Engineers write way worse code that will be much bigger targets to care about that will likely never be worked on. > Particularly in a world where low end Android devices are being shipped with slow CPUs and very little RAM The benchmarks for this (todomvc for example) aren't egregious, even for m…

So I guess the answer is "things are going to be bad, so why bother optimising?". I guess I can't really argue with a self-fulfilling prophecy like that. Not considering the size of a JS library because the business process is slow? Oh... kay? Just feels like real lowest common denominator stuff: why should I do good work when someone else isn't?

FWIW I did Lighthouse audits on React TodoMVC and Svelte TodoMVC In the performance category React gets 74 while Svelte gets 100.

First contentful paint:

React: 3.8s

Svelte: 0.9s

Time to interactive:

React: 4.8s

Svelte: 0.9s

I can't make you care about this stuff but the numbers are very straightforward.

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

#60

Post by elliotf »

I love svelte on the personal/toy projects I've tried it on, but does someone have an example of a large-ish svelte codebase with an example of a testing pattern that they've found works?

Using mithril/vue/react, there are assertions you can make about how a given action will modify the state, and given some state, how that state will be rendered.

I've not found a good way to make assertions on the behavior of code without resorting to poking through the DOM and dealing with asynchronous behaviors.

Post reply on HN