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!
Svelte 3: Rethinking Reactivity
101–110 of 186 posts
Re: Svelte 3: Rethinking Reactivity
#102Yes, 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
TODO: make shadow DOM optional, and only auto-register if a tag is provided (currently it's required)
Re: Svelte 3: Rethinking Reactivity
#103I 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?
(Longer answer: what sort of bugs? Was there an issue on GitHub?)
Re: Svelte 3: Rethinking Reactivity
#104From 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.
Re: Svelte 3: Rethinking Reactivity
#105Re: Svelte 3: Rethinking Reactivity
#106Earlier 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…
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
#107Since 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.
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
#108Yes, 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
#109- 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
#110This 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…
Is not AOT compilation is a more traditional name for such stuff?