Rich Harris - Annoying Things About Svelte

[Music] [Laughter] [Music] wow [Music] all right it's filter loader it's me rich with a talk on annoying things about svelt this is going to be a two-part talk the first part is things this felt core team has done that annoy you lot and this is inspired by a post on this felt severely asked me called what frustrates you in using svelte and i thought i would just go down as much of this list as time allows and look at some of these points and respond to them maybe in some cases explain why we made certain decisions maybe in other cases who knows figure out some to do listen items the second part is going to be just in the interest of balance and fairness things that you lot do that annoy the svelte core team but we'll get to that all right so without further ado what frustrates you in using svelt do i become sad at work when i have to use vue instead of spelt i'm sorry there's not a lot that we can do about that um not much honestly i wish felt kit had better error messages when something went wrong next had really great debugging compared to svelkit yeah this is true um we we have decent error messages in some cases but but not all um i would say that this is uh kind of a natural phenomenon in software development like an error occurs when something has gone wrong and the reality is you just can't anticipate all the ways that something is going to go wrong once people start hitting certain cases you might find that you can provide a more informative error message than just throwing whatever error occurred but in order for that to happen people need to find it and so a framework like next which has this ginormous user base and has been going for many years its users have found all of those situations and raised issues about them and so i think this is one of those things that just kind of naturally gets better over time so we definitely want better error messages in everything that we do um if you hit a situation where you have a cryptic error and you think that the framework could be doing something better than raise an issue because the chances are we'll agree with you all right the vs code extension code completion and formatting often don't do what i expect them to sometimes they completely mess up import statements and i haven't figured out why it works sometimes and sometimes not um so i i think the vs code extension is is a marvel like full disclosure i i don't totally understand how it works and it's maintained by smarter people than me um i just use it and most of the time i find it works great occasionally it'll do something that's not 100 perfect but on the whole it works pretty well but if you do find that you run into cases where stuff isn't working well then um you can raise an issue all of this stuff is maintained on the language tools repos as felt js language tools this is where to go okay the only thing's missing from me are error boundaries and each over iterables yeah so error boundaries um what's meant by that is if an error occurs during rendering it should be possible to recover from that and at the moment that's not the case in svelte you need to you basically need to make sure that errors don't occur during rendering this is something that we're definitely thinking about this felt full i don't want to make any strong guarantees but it's something that i want and it's something that lots of other people want so you know watch this space each over iterables um this is something that's come out from time to time and it's if you're not familiar with with this jargon then it's probably easier if i just show you with a little demo so say you had a map app equals new map then map set a1 map set b 2 and so on and it would be cool if you could do each map as entry and then do something inside here but you can't um that's not possible because uh the the each block expects you to have an array-like object and maps aren't they're iterables so you have to do this sort of thing instead you have to convert it to an array first um and in there i think it's something like entry there for the key and then entry one for the for the value um or you could use the structuring like that and then reference key and value like so um why don't i make this a little bit bigger so you can actually see it so yeah it would be really nice if we could get rid of that um there's a reason that it's like this the reason that we made that decision back in the day was when we're designing all this iterables weren't really a thing outside the context of transpilers like babel um in order to iterate over this object you would need to use a four of loop and babel turns that into some monstrosity with some pretty bad performance characteristics or at least it definitely did at some point um that's not really the case anymore now iterables are well supported everywhere and this is something that i think we could do and possibly something that we should do next up the push for edge serverless first i had a working prototype with sapper which is felt kit's predecessor which only ran on node and then important express middleware which is a hard requirement and switch just felt it happened and screwed me completely over well i'm sorry about that that's definitely not what we want um it is possible to run sveltkit as a node app um we're still figuring out the best way to accommodate things like express middlewares that do frankly some quite naughty things with the request object before passing it to your middleware um we want to be able to expose those things so if something adds like rec.session or rec.orth or whatever it is then we want to be able to surface that but we want to do so in a way that is sensible and isn't going to be a design foot gun um further down the line so bear with us we will have a solution to that the whole edge serverless first thing though that's not just us like the entire industry is moving towards this model um and that's because it has some very concrete advantages to the old way of maintaining your own node servers right now i think um i think there are probably more apps running on node servers but the the growth charts when you look at serverless and edge are just extraordinary and it's important to skate to where the puck is going to be we want to be able to accommodate users who don't want to have to worry about maintaining their own servers and serverless and edge have some very desirable characteristics and we think that this is the right choice we think this is the way that people are going to be building apps for the foreseeable future i know it's in tactics sugar but i'd like a switch block it feels primitive to chain if else's yeah okay let's think about this so let's go back to our repel um let's say we've got let thing equals whatever make it a prop and you might have uh if thing is foo so how would we do this with switch syntax well we begin with switch thing obviously and for the remainder of this we're going to have these errors down here because uh this is invalid syntax but this is just for an exploration so we'll ignore it for now um we need to get the cases in here and maybe these are blocks like case foo but that's gonna feel quite laborious after a while right because we've got one for each of these that's that's quite a lot of markup so i don't think that's gonna work but maybe we could take a leaf out of the the else tag here and turn that into [Music] a case foo and then maybe case bar and then maybe okay spaz and then default it it feels a little bit weird that every other time we have um a block that has these continuation blocks like else or um then and catch in the context of a weight block they're they're all flush left they're all um at the same level so maybe um if we just get rid of that indentation this part looks a little bit red maybe we put the default up here like that so everything until the first case is the default and then and then we start the case i kind of don't hate it honestly um we've also got the the situation where there is no no else there's like there's no default fallback um in which case we wouldn't have that and then maybe we do the same thing that we do with await blocks when there's no pending state when you only want to have uh you wait for the promise to resolve and then you show something so we would do like that hmm yeah maybe we should do this i don't know sound off in the comments tell us what you think slow key configuration needs to be simplified a lot should be a list of options in the cli setup tool do you want a static pre-rendered client or a full client server with endpoints a simple spi option would be nice too because some people still need to write them um i i get where this is coming from um i do particularly if you're just getting started it's nice to not have to understand what the configuration is doing before before building your site but i think this is one of those things that's seductive but ultimately would be a mistake and and here's why very often you don't know what you need to build until you're actually building it and what i find with clis that give me a list of predetermined options um is that i don't understand the difference between them like i know how to create a completely static site or i know how to create a fully server-side rendered thing i know how to do the the node version or the cloudflare version or the cell version because these are options that are in my cli but then what if i change my mind what if i need to change something afterwards then my job of figuring out how to do that is much harder because i i don't understand the differences between these different starting points and so for example you're building something that you think is going to be a fully static site but then it turns out that you need something dynamic might not even be dynamic server rendering it might just be that you need to add an endpoint to do some proxying or something like that if you've started with the static site preset and you don't have the configuration options that svelkit has and instead you need to go back and recreate it as a partially dynamic site or whatever it is then then you've lost we think it's better to have some configuration that exposes all of these controls in a way that is consistent and documented and that you can change to meet the evolving needs of your application i do agree that we could probably make the onboarding a little bit simpler we could have more examples than just the demo app or the skeleton app and that's something that we'll probably get to for 1.0 but in general i think even if the configuration does take some learning it's a better approach than having presets that are then hard to work with when you discover that your needs have changed uh loves felt but missing all the ecosystem of react for sure um yeah we we can't fix that overnight unfortunately the svelt docks don't have a search bar um yeah so at the moment the this felt documentation is one single giant page and if you want to find something then you just have to press command f and search for it that way the svelt kit docs on the other hand do have a search bar and it's split in into multiple pages so instead of using command f you use command k and you get much better search and i think what we'll probably do is we'll backport this search function to the sveltbox um because i i agree it's much easier that way all right we've got a comment about syntax everyone loves to talk about syntax i forget the syntax every time even i'm not sure right now in django template is much more simple for x in y and then end four like i i personally recoil at things like n4 and end if it's not quite as bad as bash where you have if and then you you end an f block by writing phi which just boggles my mind every time but it's still like it's still a bit weird um i think having a closing slash kind of makes sense in the context of a language that extends html because that's how you close an element it just kind of flows naturally but look everyone has different opinions about syntax and none of them are correct because it's all basically subjective but what i will say is that syntax inspect has um let me just pull up the issue uh so this has been bike shedded more than just about anything else in the framework this is a very old issue um between svelte one and svelte ii is when we started having this conversation and it it goes on forever like every possible combination and permutation has been considered at some point and this is what we landed on um and so the chances are if you have a different idea for syntax we've already considered it and there was some reason that we couldn't or decided not to do it currently nothing is felt itself only sveltkit is the docs are not so good um yep guilty uh the reason for that is like we haven't done any kind of interactive tutorial this felt kit yet um it's gonna be a big undertaking and it's something that we're definitely going to do before we get to 1.0 um you're just going to have to bear with us for that the lack of a comprehensive ui library again um there are a bunch of ui libraries out there but ecosystem stuff just takes time single biggest frustration for me as it's felt is not a standalone compiler i'm forced to use some garbage bundler um so uh is so in version one i felt we actually had a spell cli which did compile slot components into javascript modules and and we got rid of it um for a for a good reason which is that what that compiler essentially had to do was it would inline all of the the internal library helpers that your component was using so that your file could be used as a standalone javascript module without dependencies um and it it doesn't really scale very well um we found that people were doing that like almost out of laziness and it was resulting in in bad end user outcomes so you should be using a bundler like if you're building anything you should probably be using a bundler because that is the way to deliver the best outcome to your users but you can use svelte as a standalone compiler in fact on the mainsfelt docs we have we have a compiler api that that you can play with yourself it's just that normally this stuff is abstracted away because you're using a bundle that has a felt plugin and it just happens automatically behind the scenes but you can do it yourself if you want nothing is stopping you from doing that all right this is a big one it's a svelte kit thing but i really dislike how heavily server side rendering is pushed search engines do actually run js so csr isn't a big deal for seo i'll come back to that and the slower first page speeds do negatively impact google's search rankings okay there's a lot going on here we do heavily push ssr and that's for three reasons seo is one but the other two are performance and resilience um so on the seo front yes google does run javascript um google is not the only search engine bot out there but it is the big one um and it does run javascript which means that if you have content that is injected um after the page has been loaded then it can get indexed but and while i don't have any inside knowledge of how search engines work here what i've gathered over the years is that this process is less reliable and it will happen less frequently which makes sense because it uses a lot more resources to open a page in a headless browser and execute javascript than it does to just scan the html and index it so the advice that we've been given over the years is that you should do server-side rendering because your content will be indexed more reliably more efficiently um and in fact there's a page i have up here which i will drag in so i can highlight some stuff for you this is um from a page by google on understanding javascript seo basics and there's a couple of interesting snippets here um once google bots resources allow a headless chromium renders the page and executes the javascript okay so once again it's about resources and whether or not we have the bandwidth to do so keep in mind that server side or pre-rendering is still a great idea because it makes your website faster for users and crawlers and nodal bots can run javascript so putting aside the not all bots can run javascript thing what this is saying is that ssr is good for performance not bad as a comment to suggest and this is something that people pretty much universally find ssr is good for performance and that's for a couple of reasons first of all it's good for perceived performance because seeing a blank page and then seeing content flash in makes you think that things are slower than seeing some content as immediately when when the page loads but it's better for actual performance too like if you think about here's a browser and here's a server if you're getting a blank page with some html and css and javascript taking that back to the browser running the javascript and then fetching some data from the server then you've got to do these two sets of round trips but if instead you go to the server and the server gets data from itself or from somewhere else in the same data center that's basically instantaneous and so you can send that back to the client fully formed and so you can get content in one round trip instead of two that's a simplification of course but the general principle is that server-side rendering will make your site faster and that is one of the reasons that we push ssr so hard in spell kit finally resilience is really important too javascript fails all the time for reasons that are completely outside your control as an application developer people with spotty connections or people on weird wi-fi networks with back configuration people on browsers that don't support the javascript you're running people looking at your content on something like the internet archive years after it was initially created all of these are perfectly valid use cases and in all of those cases those sites will only work if you have server-side rendering so for the combination of those three factors we think that ssr is the correct default and that you should only opt into spa mode when you have a really really good reason to all right i've gone way over my time budget so i'm i'm going to stop there even though we didn't get through everything um thank you to everyone who contributed to this thread it's really useful just in general feedback like this is super helpful for maintainers um so please keep it coming um i'm gonna go and get some lunch and then i'll see for part two let's enjoy an intermission you'll find our snack bar chock full of good things to eat and drink tasty tempting hot dogs thirst quenching soft drinks fresh crunchy popcorn a complete assortment of delicious candy and a full line of cigarettes all right part two time to turn the tables so there's really only one thing that i want to talk about and it's a bug bear that i share with basically all open source maintainers and it's around reproductions sometimes people open issues on open source projects and they're asked to provide a reproduction and they either don't or they create a bad reproduction so what i want to talk about in this section is why repros are important and how to create a good one now when you open an issue on sveltkit you're presented with this issue template and one of the sections here is the reproduction section and i'm going to read it out of the baiting a link to a repository or a fork of node.news felt kit that reproduces the issue reproductions must be short self-contained and correct and must not contain files or codes that aren't relevant to the issue please do not just paste a link to your project explaining how to reproduce is generally not enough it pushes the burden of creating a reproduction project onto a small set of volunteer maintainers and isn't scalable if no reproduction is provided the issue will be closed now frankly we're not all that militant about closing issues without reproductions but we probably should be because it would increase our development velocity the worst offenders are people who open issues and choose not to provide a repro often saying something like this is simple enough that i don't think i need to provide one this is kind of like going to someone's house and being asked to take off your shoes and deciding to keep your shoes on you know you might be thinking my shoes are cleaner than your carpet but it doesn't matter you've been asked to take your shoes off and you'd be a sociopath not to and that's kind of what it's like when you disregard the instructions in the issue template it's a little bit rude the thing is it's in your interest to create good reproductions and that's for a couple of reasons firstly any moderately popular open source project will get a lot of issues a few days ago svelkit had somewhere around 400 i've been aggressively triaging over the last few days and it's closer to 300 now but it's still a lot of issues and each one requires a lot of time and effort to deal with and we're grateful for these issues we're glad that you've chosen to open an issue but at a minimum it's going to take a few minutes to look at the issue understand what's going on develop the context and either close it which means writing a message explaining why it can be closed or writing a pull request with tests and everything else that goes with it in order to close it the hard way either way it's going to take time let's say it takes 10 minutes on average to close an issue if you have 400 issues that's 66 hours of non-stop work there's only 40 hours in a work week so that's a week and a half of doing literally nothing else but the reality is that 10 minutes is way too optimistic the average issue i would guess take somewhere between 45 minutes to an hour to close if it's an hour and you have 400 of them then that's multiple weeks of doing nothing but closing issues and in that time more issues are going to come along it's very true that issues with reproductions get closed faster than issues without reproductions because they're easier to fix and so if every issue has a good reproduction the time that it'll take us to close them all and release felt kit 1.0 is going to be reduced so between us if we can all create good reproductions that's going to help everyone but it's also beneficial for you as an individual because as maintainers we prioritize issues with good reproductions it's partly a question of gratitude if you've put the effort in to make the issue really easy for us to fix then we want to repay you we want to thank you by prioritizing your issue but it's also just because i know that an issue with a good reproduction probably isn't going to be a giant rabbit hole and i want to use my time profitably so i'm more likely to pick an issue from the tracker that has a good repro so for all of those reasons please do provide a reproduction and then there's the issues that do have a reproduction but the reproduction is overly complex or it includes things that aren't relevant to the repro or it doesn't have instructions and that's almost as bad so in the next few minutes what i'm going to do is talk you through what a really good reproduction would look like so let's say you found an issue relating to how url parameters are encoded in a svelka app specifically that they're different between server and browser and you want to create a reproduction that shows this the first thing we're going to do is create a project with a distinctive name i'm not just going to call it sveltkit bug because then when i clone your repro locally and put it with all my other repros maybe there's going to be a naming conflict or it's just going to be harder to juggle with all of the other things that i'm working on at the moment so um good project names um is a really good first step i'm going to call this sveltkit url params encoding issue or something like that um cd into that directory and then i'm going to create a new repo using npm in it spelled right i'm not just going to take my existing project and add a branch to it that shows the problem i'm going to start from a fresh project because that's the best way to not include all of the extraneous stuff that isn't going to help the reproduction i'm going to create it in here um create the skeleton project i'm just going to pick all of the defaults here i'm going to install dependencies with npm i know some of you like to use yarn i like to use pmpm but a good baseline is to use the same package manager as the ecosystem at large um and in javascript that means using npm by doing so it means that you're going to check in a lock file which will enable any maintainer to recreate the state of the reproduction at the time with the versions that you were using when you encountered the bug if you use yarn and you check in a yarn.lock file then you're forcing maintainers to also use your arm and a lot of maintainers don't use yarn we use npm i personally use pmpm so i'm happy with the pmpm lock file but a package dashlock.json is the gold standard here let's open this project i'm going to start my dev server open that up uh and then i'm going to create a route that demonstrates the issue call it test slash params dot svelt and we'll give it an accompanying endpoint params dot js right and we'll write some code that shows that uh the params from the server match the params from the browser when we have a simple parameter like foo if we then add some uh some links that show the bug then we can immediately see the problem and then the last step is to put this repository on github and link to it from your issue along with some instructions on how to see the bug and that's all it is that's all that's involved in creating a simple reproduction now i cheated a little bit uh this reproduction is one that i stole from an issue that is currently open on this felt kit repo it was submitted by bluebee and it is an absolutely perfect example of how to do a repro so bluebee you're awesome everyone else be more like bluebee okay here under the rant and thank you for everyone who does submit issues with reproductions it truly is appreciated and thank you everyone for watching this talk i'll see you around

Channel: Svelte Society

Views: 37,468

Keywords: Svelte, Javascript, Web development

Id: dB_YjuAMH3o

Length: 30min 42sec (1842 seconds)

Published: Fri Jul 01 2022

Reddit Comments

[u/shmert]

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

Also, a link to original post: https://www.reddit.com/r/sveltejs/comments/u6ji0z/what_frustrates_you_in_using_svelte/