Live data from Hacker News

Svelte 3: Rethinking Reactivity

svelte.dev

101–110 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#101
post #97

Earlier quoted context omitted.

Authoring less code is definitely an explicit goal: https://svelte.dev/blog/write-less-code

Obligatory fanboy comment: it seems that every project you create moves web dev in a better direction, and you don't seem like a bad chap either!

Thank you, that means a lot!

Re: Svelte 3: Rethinking Reactivity

#102

Yes, the release I've been waiting for. I started to dabble with Svelte v2 right before coming of v3 was announced. Are web component going to happen with v3? I am trying to combine Python server app with Svelte enhanced HTML and got good results on v2. I noticed they are marked as todo: https://svelte.dev/docs#Custom_element_API

It's only the documentation that's a TODO, you can use them currently. Just pass `customElements: true` to the compiler and specify a tag, either as `tag: 'my-tag'` or in the component itself with ``.

TODO: make shadow DOM optional, and only auto-register if a tag is provided (currently it's required)

Re: Svelte 3: Rethinking Reactivity

#103

I was giving a chance to Svelte when it was upgrading to version 2 and releasing this compilation thing but it failed badly during a project that I was building due to some bugs of Svelte had with transpiling. Should I give it another chance?

Yes!

(Longer answer: what sort of bugs? Was there an issue on GitHub?)

Re: Svelte 3: Rethinking Reactivity

#104

From the tutorial: > Svelte is giving us a warning: > A11y: element should have an alt attribute > When building web apps, it's important to make sure that they're accessible to the broadest possible userbase, including people with (for example) impaired vision or motion, or people without powerful hardware or good internet connections. Accessibility (shortened to a11y) isn't always easy to get right, but Svelte will…

Eslint already warns you about issues like this, and is framework-agnostic. Does Svelte just use eslint under the hood? Otherwise you risk fracturing the ecosystem with framework-specific a11y requirements.

Accessibility requirements for the web have a centralized source in the WCAG. As long as linters/checkers conform to that, it doesn’t seem like it should be a source of fragmentation.

Re: Svelte 3: Rethinking Reactivity

#105
Mithril.js has been doing plain javascript variables for years :) Basically, React's decision to use setState is an overoptimization. Mithril (and flutter, interestingly) opts for global redraws, greatly reduces end-user code complexity while still being fast for most all cases.

Re: Svelte 3: Rethinking Reactivity

#106
post #100

Earlier quoted context omitted.

Allow me to try and convince you of its importance :) https://svelte.dev/blog/write-less-code

I actually read that just before this comment :) Edit: Some more clarification about why the arguments don't hold for me. - More code = more bugs I think code that is harder to understand leads to more bugs, but more characters typed does not necessarily directly result in more bugs, as far as I know. - Writing code takes more time Again, it's not the typing that takes time, but thinking of which code to write. If I…

> more characters typed does not necessarily directly result in more bugs, as far as I know

Most of the discussions I could find on the topic before writing that post suggested that the error rate per thousand lines of code is surprisingly constant across languages, which suggests that more characters typed does result in more bugs. I learned that from the internet though, so take it with a grain of salt!

It's true that `bind:value={foo}` offers another way to change the value of `foo` besides `foo += 1`, since at that point you're explicitly opting in to two-way binding. If you prefer, you certainly can do the `on:change={handler}` thing instead, but as I argue in the post I think that's less effective at capturing the intent of your code (and gives bugs more places to hide). This is definitely a subjective area though.

Re: Svelte 3: Rethinking Reactivity

#107
post #22

Since you are reading here Rich Harris; while I really admire your solutions, one weak point with Svelte seems to be a clear unit testing solution, or at least docs last I looked. I also noticed this with Ractive, and feel it weakens these in the eyes of many businesses considering these tools. I know it's a solved/solvable problem but it feels like better docs and samples in quick start guides would help.

I admire Rich Harris' work as well. 4 years ago I was picking my first SPA framework. Narrowed it down to Ractive and Vue. Picked ractive, it had a beautiful documentation and tutorial. Still have an app in production based on ractive. But author abandoned it. Then vue 2 took off. I didn't have a choice but switch. Recently I started playing with Svelte/Sapper again. I like it a bit better than vue for some reason and was looking to use it in the next project of mine. So svelte 3 comes at right time for me.

The author is a brilliant developer, but he should narrow his focus on Sapper/Svelte now, beside which he has many other projects (rollup, etc...)

Re: Svelte 3: Rethinking Reactivity

#108

Yes, the release I've been waiting for. I started to dabble with Svelte v2 right before coming of v3 was announced. Are web component going to happen with v3? I am trying to combine Python server app with Svelte enhanced HTML and got good results on v2. I noticed they are marked as todo: https://svelte.dev/docs#Custom_element_API

It's only the documentation that's a TODO, you can use them currently. Just pass `customElements: true` to the compiler and specify a tag, either as `tag: 'my-tag'` or in the component itself with ` `. TODO: make shadow DOM optional, and only auto-register if a tag is provided (currently it's required)

Ah ok. Great to hear!

Re: Svelte 3: Rethinking Reactivity

#109
- Is speed comparison going to include Angular with Ivy renderer enabled (and probably OnPush change detection strategy enabled)? It's also AOT rendering stuff that doesn't use virtual DOM.

- There is a lot of static code analyzing tools, like linters, that work with separate JS/CSS/HTML files. Does Svelte have to adapt all those tools in order to make them properly work with a single file component (.svelte file)?

- I believe enabling first-class TypeScipt support would bring more sanity to Svelte-based development.

Re: Svelte 3: Rethinking Reactivity

#110

This is roughly how QML works too right? > Cybernetically enhanced web apps That is pretty terrible! It seems to me that the main think that distinguishes Svelt is that more work is done at compile-time? Why not a slogan that says just that? "Compile-time optimised reactivity." or "Low overhead reactive web apps" or something like that. Cybernetics is nonsense waffle. Anyway good luck! Seems like a better approach th…

> Cybernetically enhanced web apps

Is not AOT compilation is a more traditional name for such stuff?

Post reply on HN