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

Introduction to Svelte

daveceddia.com

Post reply on HN
Print view View original

31–40 of 116 posts

Re: Introduction to Svelte

#31

Post by rich_harris »

daoxid wrote: post #12

The article says that items = items.filter(i => i !== item); is compiled to $$invalidate('items', items = items.filter(i => i !== item)); So this invalidates the whole array, right? Would this then re-render the whole array, i.e., remove and recreate all DOM nodes? And if so, does Svelte support more fine-grained ways to update arrays?

Svelte author here. There's a couple of things to note:

- as Glench mentioned, it's not destroying and recreating stuff unnecessarily. By default it will create or destroy blocks at the end of the `each`, if the length of the array has changed. If you use a `key` then it will diff the input (as opposed to the output) and move elements around accordingly.

- `$$invalidate` is just an implementation detail, and is subject to change. There a couple of directions in which we plan to do so. One is to use bitmask-based change tracking, which would allow us to generate more compact code resulting in faster change checks (e.g. `changed & 7` instead of `changed.foo || changed.bar || changed.baz` when updating the view). Another is to track which nested properties of an object or array have changed — at the moment, `items[i] = item` invalidates all of `items`, but it would be great if we had a way to invalidate `items[i]` instead.

Re: Introduction to Svelte

#32

Post by rich_harris »

gedy wrote: post #5

I loved Svelte a few years back and still think it's a nice framework with cool ideas. However, a big issue for me using it at a company is that testing (especially unit testing) seems to be an afterthought. This has made it a non-starter for using it with multiple teams working on same code base. Maybe it's changed with Svelte 3 but a library I wrote for it wasn't clear how to test. (Edit sounds same: https://github…

Honestly, the biggest blocker to us having a 'blessed' story around testing isn't figuring out how to test (which is relatively straightforward), it's figuring out what to test. Do you really need to test that `

Hello {name}!

` results in `

Hello world!

` if `name = world`? Because then you're really just testing that the framework itself isn't buggy, rather than anything to do with your app.

Which isn't to dismiss the concern — just to offer an explanation as to why it hasn't been our top priority so far.

Re: Introduction to Svelte

#33

Post by Keats »

porker wrote: post #28
asdkhadsj wrote: post #19

Earlier quoted context omitted.

It can matter though; fwiw. I love Rust, but my "node_modules" in Rust is absolutely huge. Not a problem on Desktop, but because I am full-time Rust these days my next laptops have to have lots of storage. Gone are the days where I can have a small SSD in my laptop. Fwiw though, even a 250MB node_modules would pale in comparison to my Rust version lol.

> I love Rust, but my "node_modules" in Rust is absolutely huge. Why does Rust need a node_modules folder?

It's not node_modules but it is the same concept, it's called target in Rust.

Re: Introduction to Svelte

#34

Post by dymk »

Cthulhu_ wrote: post #30
nailer wrote: post #7

Earlier quoted context omitted.

That's the compiler, not the output of the compiler. Likewise GCC/LLVM is huge, but helloworld.bin is pretty small.

How big is the source code size of GCC/LLVM? I mean node_modules often contains the full source + dist of the whole dependency chain.

Many gigabytes

Re: Introduction to Svelte

#35

Post by gedy »

rich_harris wrote: post #32
gedy wrote: post #5

I loved Svelte a few years back and still think it's a nice framework with cool ideas. However, a big issue for me using it at a company is that testing (especially unit testing) seems to be an afterthought. This has made it a non-starter for using it with multiple teams working on same code base. Maybe it's changed with Svelte 3 but a library I wrote for it wasn't clear how to test. (Edit sounds same: https://github…

Honestly, the biggest blocker to us having a 'blessed' story around testing isn't figuring out how to test (which is relatively straightforward), it's figuring out what to test. Do you really need to test that ` Hello {name}! ` results in ` Hello world! ` if `name = world`? Because then you're really just testing that the framework itself isn't buggy, rather than anything to do with your app. Which isn't to dismiss t…

> "Because then you're really just testing that the framework itself isn't buggy"

Not in all cases, I maintain some component libraries (mostly React, but a Svelte one too) and ensuring a standard component interface is pretty valuable imho. Enzyme as an example lets you test React components, props, state, etc in isolation but is not very prescriptive about what you 'should' test.

Re: Introduction to Svelte

#36

Post by Zelphyr »

This looks nice. I'm not a framework guy (more on that in a second) but they at least seem to be heading in the direction of letting me get work done without forcing me to do it their way.

That said; first it was Backbone which wasn't terrible but kinda clunky in my opinion. But then Angular came along and everybody rushed over to that pasture. But then React came along and everybody rushed over to that pasture. Now Vue is appearing to be greener than the others. Is Svelte where everyone will go next?

My point is this: if all these frameworks were so great, why do we keep running to the latest new one? I actually heard a contractor say the other day, "five years ago everybody wanted Ember developers and now everybody wants React developers. I even have those old Ember clients coming back asking for developers to rewrite the Ember projects in React."

Maybe it really is turtles all the way down...

Re: Introduction to Svelte

#37

Post by sktrdie »

I like reading scientific papers and most examples sections provide rich and intricate outlines of real-life use-cases where the idea can be experimented against. These examples usually involve quite complicated scenarios that "put the idea to the test".

One that I recently read involved a solution to the "Challenge Problem" [1] (simulating the movement of a rover) which involves lots of interesting properties and allows one's idea or framework (or whatever) to really battle test the grounds with reality.

On the web however it's different... we're somehow stuck with todo-lists.

1. https://mdetools.github.io/mdetools18/challengeproblem.html

Re: Introduction to Svelte

#38

Post by Zelphyr »

"Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages."

How is it nice that you have almost 30MB of code for something that prints "Hello World"?

EDIT: For what it's worth, I don't fault Svelte for this necessarily. This is indicative of NPM bloat which is becoming rampant in my opinion.

Re: Introduction to Svelte

#39

Post by [deleted] »

Zelphyr wrote: post #36

This looks nice. I'm not a framework guy (more on that in a second) but they at least seem to be heading in the direction of letting me get work done without forcing me to do it their way. That said; first it was Backbone which wasn't terrible but kinda clunky in my opinion. But then Angular came along and everybody rushed over to that pasture. But then React came along and everybody rushed over to that pasture. Now…

[deleted]

Re: Introduction to Svelte

#40

Post by bbmario »

Zelphyr wrote: post #38

"Another nice thing: the node_modules folder for this Hello World Svelte app totals only 29MB and 242 packages." How is it nice that you have almost 30MB of code for something that prints "Hello World"? EDIT: For what it's worth, I don't fault Svelte for this necessarily. This is indicative of NPM bloat which is becoming rampant in my opinion.

Is it 29MB for production dependencies, or dev and prod?
Post reply on HN