Rich Harris - Annoying Things About Svelte
HTML-код
- Опубликовано: 30 июн 2022
- Platinum Sponsor:
Monogram - monogram.io
GraphCMS - bit.ly/3Ft8ojy
Vercel - vercel.com
Gold Sponsors:
Storyblok - bit.ly/3OuJEg4
Array - array.com/company/about-us
JavaScriptDB - javascriptdb.com/?ctx=svelte-...
Netlify - netlify.com/
Music By:
Fractal - / officialfractal
Description:
Things we did that svelte users are annoyed about 
Наука
This guy is just awesome. Very professional. I would love to see him every month talking about the progress on Sveltekit 1.0, what issues as developer they encounter and how can we help them as a community. Thak you, Rich
I second that
Just go to issues in the repo Svelte Kit.
This guy is a genius! I loved the part where he analyses the {#switch} template and thinks on the best way to deliver the feature for a syntax that doesn't even exist. It's easy to understand why svelte is the most loved framework now that i've seen his thought process in action.
That really impressed me a lot as well. Great talk and I like his way of finding solutions of problems.
Rich is truly one of the best things that could have happened to the web development community. His outlook on dealing with problems is one of a kind. His way of dealing with criticism, and how he addresses his user base is so professional & refreshing to see.
Honesty, professionalism, and a total lack of pretentiousness. Thanks Rich and the entire Svelte/Kit team, I'm glad I am betting on Svelte for my own projects.
I like the Switch implementation, except for making the default case the first thing after opening the switch block. It makes it look like it will be always run regardless, and then deppending on the case something else is ALSO executed.
I would prefer to still have a default block
Agreed, also on the default case.
I would rather have the default moved to the end of the switch block without its own block, that seems clearer to me as if no case is a match this is what you get.
Agree with above statement!
Love the idea of a switch implementation!
Also needs some thoughts on how to allow for fall through multiple cases without assuming a 'break' in each case and how to accommodate more complex case selectors/predicates.
Having the default first also seems a strange inversion to me, as it's so tied to not matching all the other cases and handling what remains as a kind of final thought
switch seemed nice but since default case is always at the bottom I feel it would make more sense to leave it there to avoid confusion
The walkthrough on providing good reproductions seemed remedial, but I actually enjoyed it quite a bit and it was good to see it from the view of the maintainer. I'll certainly be much more attentive in the future when creating issues. Thanks Rich, "Be like Bluebie!"
-1 to switch, doesn't add enough benefit to justify the new syntax, and is more LOC than if/else. Really great, personable vibe from the video overall. Signed, a minimalist.
Instead of switch, I would prefer if it was using pattern matching ala. Rust and the JavaScript pattern matching proposal. This would make it much easier to include special conditions without having to refactor switch to if/else.
I agree. I often file myself switching on a string, and occasionally a case ends up needing to be a regex match and refactoring to if/else is a pain
I don't use switch that much. But your pseudo code for switch looks beautiful and convinced me ;) was great to read
Love the switch. I know it’s usually frown upon but it keeps the code so much cleaner.
as an alternative to the current control flow syntax, we could be using html elements(separate from the content, not like Angular). The nice thing about that is that normal HTML tooling can work with it. the dev mode could even use web-components to implement them on the client side
Switch statements feel mostly redundant; I was half expecting you to say "this switch statement I crafted looks a lot like an if/else". I've found the majority of my template logic is if/else blocks; very rarely do I need an else-if (I'd even consider it a bit of a code smell when I do).
still not got around to using svelte in anger yet, but still sat through this entire video as I love my svelte fix and Rich is just such a great guy. I learns lots from the vid about web dev in general and how to raise good bugs which would apply to any repo. Thanks Rich.
These talks are just great, learn so much watching them.
Loved the analysis of the #switch template, I would keep the {:default} part of it because it's more self explanatory, though having the default part of the switch on the beginning of the switch block with no tag doesn't feel natural (people might wonder if it's gonna be always active or not), and also it's not consistent with existing switch constructs.
Internet : what we find annoying about svelte
Rich : And Rohan will answer
Yes please on the 'Switch case' your final example looks fine and consistent.
I thought I would not like the switch statement... and then you typed it out and I realized that it would be sooo nice to have.
My issue with the switch syntax is not knowing how you’d do case fallthrough (no break statement). It’s a handy thing to have in some (excuse the pun) cases
the vscode argument is completely valid, sometimes i try to import svelte transitions and it imports "svelte/types/runtime/[...otherStuff]"
I've found that the builtin JS, TS, and JS/TS settings to VSCode are the problem. I can't recall what they are but relating to imports, the specifier should be set to "shortest" I think
That module decimates my work
+1 for adding {#switch} {:case}
Big into the Switch syntax! Looks lovely...
Loved this vid, thanks so much! You may even get more views if you go all out and add to the title.."and things you lot do that annoy us!" I for one promise to take my shoes off and be more like BlueBie...provide a simple fresh repro each time we raise an issue. To continue the shoe metaphor, that we put ourselves in the maintainers shoes as much as possible even using standard norms (npm instead of yarn or pnpm). I wonder how many of us had thought of that!
Very interesting think-out with case. I think what you came up with would be a fairly good feeling use.
Switch case is good in case of fall through, its a good to have feature but do consider breaks and default case properly.
+1 for adding switch
My only question regarding the switch block is: how would you account for the presence/absence of the break commands - it's arguably rare, but sometimes you don't just want to run the code for a single case.
12:31 you should really take a note from the "astro add" command, it allows you to do all of those changes for an already existing project.
I would really love to see some but in image processing similar to Next/Image or even the new one they’re playing with Next/Future/Image
10:48 Im not sure, because the default is what is executed/returned if no other case applied. So intuitively it should be after all defined cases.
I'm going to use Svelte rewrite a web-based app I wrote in 2018 with React originally, which is just a mess - it needs an upgrade, but a bunch of plugins just break when I try.
It will be a fresh new, fun rebuild of the UI on top of my php back end.
For the switch block for the syntax that you displayed how will we enable case fall through .. eg: case 1:case 2: both run 1 block
The switch statement is great. Would love to use Svelte Native for my next production app.
Does svelte support split file components? Single file components are cool but splitting things up makes it easier for me to do things like testing
I hate the fact that there is no good way to customize Svelte components with CSS. I used React + CSS in JS once and loved being able to easily customize components with custom classes. I used that for width, height, margins and other things that the component itself should never define.
Workarounds (and why they don't work):
* Use flexbox/grid (this is limited to size and margins but sometimes you need other CSS customization)
* Pass class as string (Only works for global CSS and is not compatible with atomic CSS)
* Pass inline CSS as string (Unreadable code + no IDE support + code can't be optimized + no CSS pre/postprocess + not compatible with atomic CSS)
* Use a CSS in JS solution (Solves most problems and has great DX but introduces runtime overhead. In my future projects I might just go with this method)
I wish Svelte just detected if an exported variable is being used as a class and treated it as if it was a class attribute of a regular dom element
I really wish we could have a switch block, i needed to use it a lot of times before but sadly resorted to if else, its a great syntactic sugar
Did you tried using ?
It helped me reducing #if else.
love sveltekit so far! Feels so much more productive and it's still in beta.
While SSR vs SPA is a good argument for SSR, I was initially thinking the comment had to do with SSR vs Static. I recently ran into an issue where I was trying to generate a non-routed and non-hydrated prerendered site. However, I had some JS on the page to manage some fun animations. Unfortunately, not hydrating meant that NO js was on the page. Which resulted in no animations. Which isn't at all what I was hoping it would do.
Rich, I'd suggest to think about integrating the "Island Architecture" into SvelteKit somewhere in the near future (v2.0 maybe?)
+1!
The fact that Rich will sit there, show his thought process and do some coding with us, is delightful. Love Svelte, wish I would have been able to talk my old company in to using it. My future projects will all be svelte. Keep up the great work!
he open-sourced his thought process
11:18 I really apreciate this switch syntax, you write less code when the else ifs get bigger, no need to repeat the variable for example
I am a big fan of the switch case and was thrilled when python added that functionality. My vote would be to have a {#switch} block for Svelte!
switch case syntax is a game changer. i can feel it
Hmmm, can't believe no one mentioned this but layouts don't have end points! That's like a show stopper sometimes
Oh god please that switch statement is just what we need
Thanks for highlighting that people opening issues should put some effort into it. I'm not an OSS maintainer, but I've ran into many issues in different repos where people didn't even bother posting the error message that they got, let alone create something more detailed and robust.
Worst offenders seems to be people that don't even google the problem that they have, because if they did they would immediately see an older StackOverflow/GitHub thread with a solution posted...But no, they just decided to open a new issue and go about their day.
As far as I'm concerned, you should become more strict and just close issues that are super low effort. If people don't have the basic decency to treat you (and the project) with a certain amount of respect, I don't know why you as maintainer of something should burn out because of others.
As always it is a joy to listen to RIch, you should totally have a Pod Cast. Great video. One day maybe Svelte will rule the world.
I’d recommend self-documenting the config file with commented-out directives.
Issues are helpful for not just maintainers. I haven't used svelte yet, but I have plenty of other open source software and issues even closed ones are often the only sanity check or opportunity to find work arounds.
I get that maintainers want nice issues, but that is often a large burden on users and does have a negative impact on community contributions.
Maybe the trade offs are acceptable.
Aw what a pleasant surprise! Thanks man!
All my projects outside of work, here on out, will mostly be in Svelte/kit with some React/Next to stay fresh for work / my day job that uses react whenever I contribute to some client side codebases (and of course, interviews since it’s still dominating the market). I just feel like Svelte, especially with how Vercel feels about it and how they brought Rich aboard, is about to really take a step up in popularity and usage. I think it has better marketing than Vue, and better content online. Once it gets a larger community following, it should dominate and be on reacts level of popularity.
i like the {#switch} syntax :-)
Thanks Rich Harris, loving Svelte
Think I probably missed something in the documentation, but… given everything is an object in javascript I pass functions to components as props instead of using create event dispatcher as it seems (is) less complicated. So, maybe if passing functions is fine then the more long winded approach using event dispatcher is annoying.
@@kieranbarker1902 Indeed… and since posting I stopped passing in functions generally in favour of a simple on:click and let the parent handle the click inline with the markup. Or I use set context.
while I like the rant on reproduction repos vs a branch of a real project I've had multiple instances where I couldn't recreate a bug outside of my own project with the exact same lockfile. I still don't quite know what's wrong there, I even turned my branch into a draft PR so I could trigger my CI and the error does occur in github actions, but I cannot recreate it outside of that project.
@11:25 yes please! Switch blocks, please!
starting song is catchy asf holy shit
Please no switch statement; as something for the future consider match statement, to enable pattern matching
Thanks Dear Mister Svelte-president
I'm late to the party but switch statements are beautiful in Kotlin using the `when` functionality. Used to hate them in PHP so avoided them altogether in JS/TS - regardless how clunky it got.
Please ship the {#switch} syntax, it looks so nice
js switches are simpler then if else because they only represent onet side of a comparison but they are limited by design because of this. If elses take a condition expression which is more flexible/complete. I see why seeing a long if else can make you wonder if switches are better but by seeing Rich's exploration I understand why it wouldn't be that beneficial. mapping values to dom expressions could be useful but in svelte, I don't think that I've seen a way to create "DOM expressions", the only way I would know now is but it requires real module components. Yes, the switch syntax you tried out is nice.
i love this man
Starts at 0:50
Very insightful, +1 for switch implementation.
I’m sure I’ve seen this a few months ago but this video was published 4 days ago???
It was part of the Svelte Summit Spring 2021 Conference which was posted online in one very long video.
13:38 teach me to fish 👍🏼
Is this a reupload? I swear I've seen this already.
It's from the last Svelte Summit, you probably watched it live, or the full conference video. :)
The first switch syntax, with cases indented and default at the end is the easiest to understand and most similar to other languages, that would be ideal!
bind:attributes
so i can stop abusing display: contents
Thank you, Jesus.
16:29 I saw chakra and mui for svelte
i'm just here waiting for someone to mention Rich Harris as the Jesus of Web Development
WE NEED SWITCH BLOCK
Not a big thing but I think the colon-prefix is superflouos. Instead of {#if ..} {:else} .. {/if} why not simply have {#if ..} {#else} {/if} ? I think the slash, akin to the HTML/XML 'end', is clever and nice to read. However, I don't see much that speaks for having the colon prefix, thus only adding more to learn.
Apart from lil' pet peeves, Rich you're a real asset to WebDev. Svelte is the first Web Framework that is a joy to use, everything else is just doing things in a complex manner because "What we're doing is complex, durr". Especially Angular falls into this hole. Thank You!
He really made a “reacting to my subreddit” video in talk form.
isn't this a reupload?
Annoying things about Svelte = being too good
Glory hair and nice beard
Yes, please on the {#switch} ! Thanks for all you work!
CaptainAmerica0001 is me 😳
Yes please add that switch implementation that actually looks pretty clean
"Syntax is the thing people ask us to change most".... maybe it's because, even ignoring personal preferences, the Svelte syntax is just... ya know.... really ugly?
Vue's done the best job out of everyone by being completely unopinionated. It has a default approach, but if you want to use a more Svelte or Hooks-like style or Classes or OOP, or functional, or JSX, or Markdown, or CoffeeScript or TypeScript, ...you can. It just lets you do anything. Yes I think most of these are terrible, but somebody out there is using them because syntax matters. Svelte's default syntax being so ugly and there being no option to change it has warded off most people I've talked to from using it. Or even trying it for more than a minute or two. It doesn't matter what features you offer, if to get them I need to look at something ugly the whole time.
I see this as Svelte's biggest downfall, it's like the focus is 99% on performance and anything that isn't perfomance has to fight for attention in the 1% of efforts. Developer experience should be Svelte's primary focus for probably the next 2 years. Maybe I like having seatbelts and air conditioning more than having a marginally higher top speed.
Switch 👍
22:53 how to provide reproduction steps for an issue
{#switch value}
value is equal to {value}
{:case 0}
Empty...
{:case 69}
Nice
{/switch}
insert some kind of counter element
rich you're a fucking boss
Thanks for supporting Ukraine guys!
I am just here to say that I LOVE SVELTE!!
Can we start using svelte kit in production ? Why 1.0 delaying ? What’s up with this vite issue that blocking ? Can anyone throw some light !!?
You can if you can allocate effort towards updating it very often. If not, be patient :)
I'm using Sveltekit in production and it works very well, there has been only few small breaking changes, that usually just name changes, except for endpoints which is completely new thing but you don't have to use them.
@@hazreh Just go to issues in the repo Svelte Kit.
You have "SvelteKit 1.0 release blockers in Vite" and "Help getting to 1.0" pinned there, which show what's missing for version 1.0.
Annoying things about Sveltekit - its NOT Svelte-like, at all. If svelte was like sveltekit, few if any would use it.
I'd like this for the switch
{:switch thing}
{:'foo'}
{:'bar'}
{/break}
{:'foo1' | 'bar2'}
{/break}
{/switch}
following the c style switch because it allows falling through
_too lazy for one commit at a time_
I saw Jesus today
The MOST annoying thing is that music ...
vs code extension sucks
:(
This {#switch} stuff is just syntax sugar over {:else if }. It does not make the code simpler and won't bring any value. In the same team, some coders will use {:else if}, others {#switch} for no particular reason apart from personal feelings ... sometimes, it's better to have just one good solution to rule them all.
IMHO, don't bother implementing {#switch}
10:39 I designed exactly this switch/case a year ago with a preprocessor, it would compile down to if/else.
I deleted the project but forgot to deprecate the NPM package, @willsterjohnson/wutils
the docs for it are gone along with the repo, and I can't remember how to set it up... but the dist code is there