Replies: 38 comments 154 replies
-
|
I'll give you my point of view I have about 15 websites with SvelteKit and the truth is that it has been great to build each site using it, this update broke almost all my knowledge and mental structure that I had of SvelteKit so I have to relearn many things, although it is much more confusing than before, but everything has a reason. I would love to see all this with the old Router (or with some changes that make it easier to understand) but this has been planned and studied by professionals like @Rich-Harris who are brutally active in the development world and know the problems that can arise that even we mortals don't fully know/understand. Yes, it is a drastic change, but I agree with all the reasons I read for all these changes. You gotta break a few eggs to make an omelette. So cheer up, good things will come! |
Beta Was this translation helpful? Give feedback.
-
|
This is quite true. I have localisation and [lang] file structure. Took our team months to develop this. And with new update doesn't mention const response = await resolve(event); abut this important thing:(( |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I'm not sure it's really type "safety", it's more guaranteed type consistency - you get whatever type the endpoint returns. Personally, I prefer to import the type(s) that are relevant and use them to define the exports in the page component as that is then immediately readable whereas |
Beta Was this translation helpful? Give feedback.
-
|
Same here. This is a very negative comment, and I also want to underline the great work that has been done on SvelteJS and SK since years, even if I'm hightly sceptical with current direction. |
Beta Was this translation helpful? Give feedback.
-
|
On the contrary, with all due respect Rich Harris is not a god; he’s just out to make a name for himself. If he really cared about web development he wouldn’t be peddling another framework then changing it drastically like the originally commenter is saying. I took the time to really listen to one of his talks about web performance and the problem with web frameworks yet he himself is guilty of all the things he criticizes. If you really want to make a good web application stop using frameworks and build simple applications with little web components here and there where needed. You will be blown away by how much you need to unlearn and how truly simple and boring web development should be. I just checked in with svelte five and was shocked that again they are contradicting themselves; now they are breaking away from aligning with the web components standard. So totally unacceptable. It just boils down to this; you have a lot of ego driven, bored developers who don’t care about the developers they are preaching too. |
Beta Was this translation helpful? Give feedback.
-
"With all due respect..." and "is out to make a name for himself"... you lost any credibility lol. Why personally attack a guy when a whole team of maintainers are responsible? |
Beta Was this translation helpful? Give feedback.
-
|
I do agree that it can be frustrating relearning something, especially if time is of concern. But with that said, there are tons of warning that the Kit version is still in Beta and we should expect breaking changes. All in all, we must expect big changes like this while in Beta. I'm sure they aren't far from a stable release. |
Beta Was this translation helpful? Give feedback.
-
|
As written in my previous comments, for me its less about the fact that something changed but more that the direction it is heading for me does not feel like things this project (and svelte itself) originally promised like "building web applications of all sizes, with a beautiful development experience" (svelte kit home page) and "Build boilerplate-free components using languages you already know" (svelte itself). In fact it moved towards a direction with a lot more boilerplate code while other frameworks such as Vue recently moved into a direction of less boilerplate. |
Beta Was this translation helpful? Give feedback.
-
|
Considering that some of the design principles behind things like #5748 were explicitly "the current design is too boilerplatey" (see, for example, the discussion of how |
Beta Was this translation helpful? Give feedback.
-
|
I'm assuming the main point is "route boilerplate" because of the extra effort/learning it takes to do the +page/+server naming conventions? |
Beta Was this translation helpful? Give feedback.
-
|
Well I feel you, but the thing is.. that.. when you are updating a beta software, you should first look for the commits first. SvelteKit is in beta, it is changing and continue to change until 1.0. Till then always look for breaking commits in main branch. |
Beta Was this translation helpful? Give feedback.
-
|
I also can't imagine how hard and frustrating it is to attempt to build consensus via community discussions on how to redesign a framework used in production by some cowboys/girls like the SvelteKit community. I share some of OP's sadness and I have the deepest respect for the Kit team. I've slowed way way down on my Kit adoption after seeing the divergence away from Next.js directory-based routing spec. That alone wasn't terrible, but when the rationale behind new "runes" in filenames, e.g. I'll probably wait till 1.5 to jump back into using Kit on new projects. I really really liked the original Kit as of maybe 3 months ago. It had some warts, but they weren't deal breakers. I'm more of a backend dev who was finally able to build amazing frontend apps using Kit. But the learning curve is eating up too much of my time now. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW I was pretty resistant to the change too, but in the end it does make things a bit clearer. I would have gone with different names and no + prefix but I get the rationale. I find it also helps when communicating to people what file does what compared to the previous lack of clarity between page endpoints/server endpoints. |
Beta Was this translation helpful? Give feedback.
-
|
@benmccann thanks for the info (and for SvelteKit!.) I'm all for the directory-based routing approach (over file based.) My intended point is that we could have followed the Next.js spec which would have helped Kit adoption, reducing docs, reducing support requests, etc. It seemed like the community pushed Kit toward a much more complicated, (yes I mean overhead complexity, not necessary) solution for the most common use-cases. More broadly, here's my internal summarization of how filesystem-based routing efforts are going: (I say all of this with a lot of respect for the team and it's not my intention to call anyone out or throw shade on the project. These are just my thoughts.) Background: File/directory based routing takes the place of imperative routing in code. e.g. router.get('/', rootHandler)
router.get('/about', aboutHandler)
router.get('/users/:username', userHandlerHandler)Why is this happening? What are the pros/cons?
Bonus points: it's similar to how Apache has worked for decades (directory listings and index.html/htm files.) Overall impression: Filesystem-based approach seems good but it's a simplification at the expense of customization and extensibility. It won't work in absolutely every scenario unless we add a bunch more complexity to it. But by doing so, we've removed the top 2 benefits listed above. Which leads me to believe that this approach should be kept simple but provide an escape hatch for those scenarios where the simple and common needs are not met. The latest changes ( Which means I advocate for a simple FS-based approach that provides an escape hatch in order to do anything out of the ordinary. At this point, I doubt the current designs will change. But hopefully this will shed some light on a contrarian perspective. Thanks for reading. |
Beta Was this translation helpful? Give feedback.
-
|
I think the new version of routing is probably overall simpler than the old one. That being said, I'd like to open up SvelteKit's router to allow you to use it imperatively in code as well. There were some concerns that doing so may constrain us by having another API we need to be careful not to break and so we wanted to nail down the FS-based approach first. But I would like to do it eventually post-1.0. E.g. if you want to have routes live in multiple projects right now, that's not really something we support, but is something I think would be nice to offer in the future. |
Beta Was this translation helpful? Give feedback.
-
|
I like how Solid does that |
Beta Was this translation helpful? Give feedback.
-
@coryvirok That's a very clear statement of what I'm feeling about the changes. Thanks. @benmccann I totally appreciate your (and everyone's) work. My take. The issue is not that the filesystem router has limitations. It's that the platform seems to be trying to get around them. This is adding (I'd argue) unnecessary complexity to the router API. But hey, I'm just gonna go with the flow and do a rewrite. Maybe my skepticism will vanish. I'm sure it'll all come out fine. |
Beta Was this translation helpful? Give feedback.
-
|
I totally understand that it is frustrating to having to relearn some of the concepts. It looks scary at first, but actually conceptually not much has changed. The new About the I'm genuinely curious: If you would start from scratch and not have the previous knowledge you have to unlearn to some extent - wouldn't these things be easier to understand? One way of doing things, special files immediately jump out because of the |
Beta Was this translation helpful? Give feedback.
-
What specifically is harder to understand compared to other file-based routers? There are reserved file names, the url is defined by the folders leading up to these reserved file names. This sounds easy to me, but you seem to have a different view on it, so I'm eager to hear it. I'm purely talking about the "how fast can you pick this up, how easy is it to understand" perspective. |
Beta Was this translation helpful? Give feedback.
-
|
For me it's just more noise and special reserved filenames as you say. I believe I think layouts could easily live someplace else which would be an improvement (the inheritance + named skipping of inheritance makes them a bit confusing and feels awkward like it's not the right or final design). My ideal "layouts" would be something elements can import to maybe also allow the use of named slots. That removes another need for a special character and reserved filename. All you're left with then is non-svelte pages for endpoints (again, same routing rules, only the extension is ignored). The only other things you need to know about routing is that This is ignoring technical challenges around whether things should or shouldn't live in the same file. I think they should for the dev experience, and it's way easier to understand if the config for a route is in the file for that route. The The numerous different special filename combinations of It's always difficult to say whether something would or wouldn't be as easy in hindsight, forgetting what you now know. But I feel learning both the old routing system and the SvelteKit concepts (really just page, loader & endpoints) was significantly easier than I find understanding the new ones even with the now existing knowledge of those things plus the extras (shadow endpoints etc...). But I guess I'm a traditionalist - I think the page, endpoints and loader should be everything, I never liked the "shadow endpoints" being a slight variation of an endpoint. I think when SK was like that it was closer to my ideal framework and felt simpler to understand and reason about. For me, it's drifted away from that over time. |
Beta Was this translation helpful? Give feedback.
-
|
I guess I see this differently, but to me, having 2 The new approach breaks things up by responsibility and scope, meaning it's much harder to do it wrong, even if (arguably) it's also a bit harder to do it right. I see the update more as structural guardrails on a best practice, and this best practice wasn't even identified until the limitations and pitfalls of the old way were uncovered through community use. Add to that the removal of I like how Rich Harris explained things here, especially the part about simplicity. To expand on his thought, the previous method appeared simple at the expense of the user needing some specific knowledge to truly understand it. Now, the system is actually simpler, with the expectation that the |
Beta Was this translation helpful? Give feedback.
-
It's noise for you right now because you know the previous conventions. Some new to web development doesn't. Also, it may be obvious in the simple case, but what about this? Know you have many routes crammed into a single folder, with So yeah, the simple case of
This is confliating two things - layouts wasn't changed in the new API design (although there's a discussion to make them easier to understand when you have to use advanced layout structures). The ability to have layouts defined per page - noone's stopping you from creating reusable layout components and load functions which you mix and match as you like. It's cumbersome for the common case though, which is why I think this would be a bad idea to make it the official design.
As stated above, I think it's less to remember. You learn the vocabulary once and from there on it's super consistent. Compare that to the previous design where you always have to look for adjacent files to know what the current file represents. I saw some comments on Twitter going like "oh cool you can do X with SvelteKit now" which was possible before, which again shows it wasn't that obvious before. |
Beta Was this translation helpful? Give feedback.
-
Or "now I can clearly see my routes without having to go digging into folders, expanding them to see whether they have a view or an endpoint"
How exactly has anything broken down? The example you give is simpler and clearer IMO. It's how filesystems work, which I think everyone is familiar with. IMO the rules about the routes were significantly simpler. Thought experiment: if it truly is simpler and clearer, why don't we make every non-router source code file also a folder with a file inside it? Why aren't people storing their files as folders with a single "doc.word" file inside them?
No, but only because they were split into back-to-back proposals. Layouts are clearly part of the routing system, and affected by changes to it. Because the filename-complexity-budget was kind of blown on routing, I think it made the layout naming complexity more apparent (kind of amplified that issue). There's a new proposal that appears to try to address that the named layouts + the new route names are maybe a little too complex when combined.
AFAIK it's inefficient - the layout would be unmounted / remounted each time (I believe). So although it appears to also enable the use of named slots in a layout, you could easily create perf issues with that approach so it's a limited option.
Uh? The new routing has more adjacent files than the old one. I don't understand that claim at all. There are now more special-names to remember and I've seen lots of people in Discord getting confused with them (esp. when some contain the same-named functions with different usage / return values expected). I think it was simpler when a file was self-contained (everything for a view was in the Svelte file). There wasn't really any vocabulary to remember (besides the special name for layout files and the convention for private files). I know you keep repeating that it's simpler, but my experience is that it isn't. No amount of telling me that it's really simpler will convince me that it is because to me it isn't. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure the argument about file based routing being simpler that directory based holds much water. Granted see all these new special characters and filenames is a bit overwealming, but compared with the equivalent filebased I would argue that it's not so different . E.g. vs |
Beta Was this translation helpful? Give feedback.
-
|
I'm interested in hearing more about your use case. Small dashboard-like web applications are also possible with SvelteKit, and I'd like to know what about the changes makes it harder for you to achieve what you want. |
Beta Was this translation helpful? Give feedback.
-
|
I was scratching my head today since I started up a new sveltekit project and my routing wasn't working. I'm really not a fan of having so many +page files in my project. Its going to make working on projects a pain in vscode for me. Has anyone started a fork for 0.3x yet? |
Beta Was this translation helpful? Give feedback.
-
Have you turned on breadcrumbs? |
Beta Was this translation helpful? Give feedback.
-
|
I must say after reading all this I am impressed with the Maintainers and Collaborators responses. With Nextjs some issues were open for a year and you just wouldnt hear from anyone and they have this "tough tits" approach where they just dont care. I do feel everyone on this directory based routing, its confusing when you looking at your folder structure - so many page.server, page.svelte and layout.server, layout.svelte. And i havent read up on the reason for the +, but it is strange. I liked Next12 where they exported a function 'getServerSideProps' , I dont like the name but the idea that the serverside and client side code was in one file. I mean you should only really be querying data in the 'load' function which makes it small and for most cases doesn't warrant a whole file. This would also fix having to But overall i am never going back to Nextjs or React. I am a Svelte member now. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know why it's so hard for them to at least give us the options? Like is it really a struggle to implement something like that? 😂 |
Beta Was this translation helpful? Give feedback.
-
|
I would like to reply as another non-professional dev that only works in SK every couple of days. I've been chipping away at an application for a while that has ~20 routes so far, and since I'm not working on it 40+ hours a week and routinely have to set it down for days at a time, it's expected that I'll loose some context in the interim and have to grok it again when I get back into the codebase. Probably pretty similar to the OP's situation. All that said, I think the new routing is a huge step in the right direction. As much as it sucks to deal with the migration and learn a new syntax and structure, it also clears many things up. I find the new structure much easier to navigate, and when I'm thinking "I need to load some data on the server before this page renders" I know which file identifier to look for with zero fuss. I'm finding things faster and as a result, developing faster. A few things to point out from my perspective:
Something I grappled with as a single dev building something to help me do my (no-tech) job, was the realistic expectation of what I needed the app to do, which in turn drove my needs in a framework and other tech choices. At first I got this step wrong. I had several false starts because I was looking to build a solution for all current and future use cases. I started with a fastify server running Graphql, code generation, Graphql clients in svelte, then those clients in SK, then merged it all into SK and got rid of the server but kept Graphql, then realized what I really needed was just what SK is offering. In the meantime I ended up with about 6 abandoned repos and a lot of wasted time. I came to realize that I needed to start as small as possible and build up later, which has been advised by virtually every seasoned dev ever. When it's time for the ba-billoin user scale-up, dedicated mobile app, and swanky offices, I can address it then. Right now I just need to build the thing, and the fastest way to do it is using Sveltekit. So my thought is to closely scrutinize what you really need and address it that way. If everything you are doing could run as a SPA, then SK is probably overkill. Go with vanilla svelte and use a client side router and you're in business. (and the API will be stable) On the other hand, having a clear location to load data that hydrates a page and having that secure is huge for me, and I love building things with Svelte. So SK is the way to go. As far as the migration was concerned, running the script and then working through my routes to adjust things took ~45 minutes, including a few interruptions and some time spent in the new docs making sure I understood what was going on. Virtually all of the heavy lifting was done by the script, and I just had to adjust a few things that shouldn't have been where they were anyway, remove the throw statements, and fire it up again. Getting through my couple dozen routes to review files only took about 10 minutes of that. |
Beta Was this translation helpful? Give feedback.
-
|
I understand that migrations are painful and unfun - even more so when you run into speed bumps. We've been dogfooding our own tools to try and make the experience seamless. I've migrated three or four sites of fairly decent complexity pretty smoothly. I did run into one site last night where the migration tool failed, but there's already a fix out for it (#6096) and I haven't seen that happen to anyone else. We'd like to make it as smooth as possible, so are watching for feedback. The big PR changed about 900 files if my memory serves me, so it would be expected that there are a few bugs or regressions, but those are getting ironed out quickly. I'd also like to say I understand how some of these changes may look worse at first glance. Engineering is about tradeoffs. Any decision we make will make some things worse and some things better. However, the things that jump out at us might not always be the most important in the long-run even if they feel the most visceral. E.g. @CaptainCodeman points out that E.g. here's the Svelte.dev site right now pre-migration: https://github.com/sveltejs/sites/tree/1c83a81d3957812a2986c6c50667d3cfca790980/sites/svelte.dev/src/routes Here's the Svelte.dev site in my migration PR: The latter is much clearer to me. E.g. it's much more obvious that there's an Similarly, the We care a lot about aesthetics, developer experience, etc. These are highly subjective, different in the short-term and long-term, etc. As we gain a lot more experience with the changes, we'll have a better sense of what's good and not about them. I'm still trying to figure out my own feelings about all the changes just as everyone else is. There are things I obviously like and others where my feelings have flip flopped back and forth. While it's just one measure, one nice thing I noticed is that I ended having less code after migrating svelte.dev:
Some of the rough edges will continue to be ironed out as we fix bugs or introduce new functionality to address things that could be easier with the latest version. Some of this will also happen via the community and tooling (e.g. someone's already created |
Beta Was this translation helpful? Give feedback.
-
This is a key feature and I don't think it is prominent or emphasized enough in the docs. It might even be tucked away in the separate FAQ page (I think from last time I checked). Being able to long-cache with hashed filenames and immutable headers is a killer feature, never mind the multiple format serving. Back in the day that was whole lump of grunt or gulp tasks. |
Beta Was this translation helpful? Give feedback.
-
Yes, but because it's called I wonder if load is really the right name for the server one, which is really serving data (and I know the GET name contradicts that, because it's sending data too rather than getting it) |
Beta Was this translation helpful? Give feedback.
-
I read (or misread) that to mean the following. "On a client-side navigation, only those |
Beta Was this translation helpful? Give feedback.
-
@benmccann Many programmers starting out put all their components into lib/. Don't know if there is a recommended stand here but personally put route based components in the folder and shared components into lib/. And I had absolutely no idea that putting images into static/ wouldn't be cached or optimized. I have all my images there. -_- (Maybe the folder should be changed to public/ ? ) So making it more clear on how to setup image handling would be a huge help. Thank you ! Suppose I need to make an assets/ folder in lib now for global stuff and put page specific images in the route directories. |
Beta Was this translation helpful? Give feedback.
-
Just FYI, there's a docs section for that here: https://kit.svelte.dev/docs/assets. It's still needs to be fleshed out a bit more though
I'd like to make this part of the default template soon. For now, the best examples might be the svelte.dev and kit.svelte.dev sites |
Beta Was this translation helpful? Give feedback.
-
|
(Here is my experience, so far, as a amateur frontend programmer:)
Now, I'm planning to re-read the doc (https://kit.svelte.dev/docs/introduction) later when necessary & got the time. Before that, without a deep understanding of the changes, I can't confidently judge how good or bad this change is yet. For the big picture, Svelte has earned great trust from me, I finally find something I can enjoy in frontend, just like jquery (though svelte disencourage use jquery with svelte, and I kinda agree after using svelte for a while). As you see the pace of svelte development, and the great community response time & support, I do believe svelte will get better in long term, even there may be some unexpected in the middle. It's beta now anyway, changes should be expected. Trial & improve. |
Beta Was this translation helpful? Give feedback.
-
|
Off topic maybe, but instead of the routing style, I found I need a better ui framework more emergently, I use a mix to 2+ ( |
Beta Was this translation helpful? Give feedback.
-
|
What’s the thoughts on retaining the optional ability to have the load
function within the context=module script block ?
…On Sat, 20 Aug 2022 at 19:18, Simon Green ***@***.***> wrote:
Lots of pages on that original version that are a folder + single index
page *could* have just been a single file, which would have simplified it
even further and made the contrast even more dramatic (e.g. /faq.svelte
instead of /faq/index.svelte) but even so this:
[image: Screen Shot 8]
<https://user-images.githubusercontent.com/304910/185758366-a50dbb13-7649-44d5-afaf-a14c4da3b3ba.png>
is *much* simpler and clearer IMO than this:
[image: Screen Shot 9]
<https://user-images.githubusercontent.com/304910/185758375-839f10f9-2445-4978-86d5-422e23c0d0c1.png>
For me, SvelteKit was perfect when there were just pages and endpoints.
Load always made more sense as part of the view (and was ideally optional /
not required anyway). Everything was more optimal for the most common
cases. Now it feels more complex even for simple cases based on the idea
that it will make the exceptional cases easier (even though they are far
less common).
—
Reply to this email directly, view it on GitHub
<#6005 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGNH6SUDB3YJBEXFUFSTV2EHNZANCNFSM563G2BCA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Two ways of doing the same thing is almost always bad, so no |
Beta Was this translation helpful? Give feedback.
-
|
That's a rather sweeping statement |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if it'd be likely to be added to core, but it's something you could probably support with a Vite plugin or Svelte preprocessor and so it's something that the community may add support for. E.g. check out https://www.svemix.com/. I don't know if @pixelmund has thought about how the latest changes may affect Svemix, but it may be a possible feature for that add-on |
Beta Was this translation helpful? Give feedback.
-
|
I have a Draft-PR pixelmund/svemix#56 for the new Routing-Rework, which brings the old routing style almost back. There are still some weird bugs and it's absolutely hacky. |
Beta Was this translation helpful? Give feedback.
-
|
I think if it were up to me in a vacuum I'd come up with: /+about.svelte // equivalent of /about/+page.svelte
/+about.js // equivalent of /about/page.js
/+about.server.js // equivalent of /about/page.sever.js
/__layout.svelte
/__layout.js
/randomfile.js // note the lack of +
|
Beta Was this translation helpful? Give feedback.
-
|
This started off as a reply to a comment, but felt it was better just as separate comment. I agree with @CaptainCodeman (this reply) as well. I don't care that there's changes nor do I mind having to re-learn stuff. As many have pointed out, it's in beta. But using SvelteKit after the update hasn't been a great experience. I think bloat best describes my experience. The folder-based routing system just does not work with me. Navigating through the sea of There's no doubt many good things came out of the update, but I feel a lot of it could've been added without introducing a whole new system. To me, it feels SvelteKit is attempting to do too much. It tries to be the solution to everything, from simple to complex apps, but it also tries to make everything simple by abstracting it. That usually leads to a bloated solution. For me, the old SvelteKit with just pages and endpoints (and load function) was just perfect (Svelte too). They had just the right amount of abstraction and complexity. I'm an author of an auth library for SvelteKit. Before that, I found a Next.js auth library called NextAuth that handles everything, from oauth to email verification. I never used it before but thought I might make a similar library for SvelteKit. But, the more I developed it, the more complicated it became. Customization became impossible without a janky solution. And NextAuth never really had a solution to the complexity either. And I feel SvelteKit suffers from a similar problem. |
Beta Was this translation helpful? Give feedback.
-
|
Bloat is the perfect description.
|
Beta Was this translation helpful? Give feedback.
-
|
Oh god, yes. Having a separate api route has become unpractical with the update, |
Beta Was this translation helpful? Give feedback.
-
I'm not sure I follow. The features haven't changed, you still have "just pages and endpoints" and if you want load functions. The difference is that the files in which they appear are named differently now. |
Beta Was this translation helpful? Give feedback.
-
|
With the update, we now have server load functions and actions (which feels too limiting), and creating standalone endpoints seems like it should be avoided. You also got lots more directories and files in general. Feature wise, it might be the same, but you have more things to do to get that same result. I'm also talking about the general direction of SvelteKit (with the forms/actions change coming). |
Beta Was this translation helpful? Give feedback.
-
|
I have a project with 168 files inside my /src/routes folder - before the migration. Migrating it will basically turn that into 2/3x more files, by adding all the folders and the split up files. I am 100% considering pinning to the version it's currently on ( |
Beta Was this translation helpful? Give feedback.
-
|
trying to put myself in the shoes of a new user, if I were to look at the file structure of this current svelte routing architecture I would think that this framework is over engineered. It gives me tingly over-engineered spidey sense vibes seeing all the folders and +pages... Reminds me of early OOP class organization |
Beta Was this translation helpful? Give feedback.
-
|
But it's not called /routes/src/project yet ... (my attempt at a Java joke) |
Beta Was this translation helpful? Give feedback.
-
|
If I was a significant contributor to this project I would be absolutely raging at this post. You used an early beta version of a product (0.3!!!) not yet intended for production usage and are shocked pikachu when there are major breaking changes in a multi version update? This is 100% on you and nobody else. |
Beta Was this translation helpful? Give feedback.
-
As written by myself and numerous others, it’s not the fact that something changed, it’s the direction of the change that was the issue. While the proposed changes were flying under the banner of simplicity, a lot of people perceive them as too complex and a step backwards. The problem with perception of course ist that it is not objective, but subjective and we will probably never have a full agreement on this matter. I do however feel, that this change was rushed (if I follow it correctly it was discussed in 3 days), but this may also be subjective since I am mostly active in the Go community, where things are discussed at length (probably too long sometimes). Although this leads of course to a slower speed of innovation and might not necessarily be appropriate for this project. Some middle ground would be good or a process using RFCs that other projects follow. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly, AFAIK no one is complaining that there are changes. It's entirely about whether the changes are an improvement or not. I think the vast majority of people who started using SvelteKit did so because they are open to change, and looking for new approaches. The process was rushed, it felt like the decision had effectively already been made and feedback that questioned the changes was unwelcome. The cartoon suggesting that people wanted "improvements, but no changes" came across as insulting and condescending. |
Beta Was this translation helpful? Give feedback.
-
|
@CaptainCodeman |
Beta Was this translation helpful? Give feedback.
-
|
The user will vote by choosing stay or leave. |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if part of the issue is that the maintainers may have talked about it for days or weeks to come up with the design, so to them it was discussed a lot more than it was for us, where it just appeared one day with very little time to really analyze and consider things? Who knows, but yeah - the process of how the change was announced and the short time window certainly didn't help. |
Beta Was this translation helpful? Give feedback.
-
|
Looking more like java file structure by the day. Seems completely over engineered. These changes are so small they almost don't make sense to implement, but break absolutely everything. This means we all have to re-learn sveltekit routing. I understand this is beta software and we should expect breaking changes, but the reality is that many people, including myself already have quite large codebases in sveltekit. Looking forward to 1.0 so I can use the framework I love without having to change my entire codebase every few months! |
Beta Was this translation helpful? Give feedback.
-
|
I do have some projects and it didn't take that much time. About routing i was using directory as route always so it didn't effect me that much. I use WebStorm and i don't have any issue in finding file and directory. I might be little bit disappointed how sessions changed. But we all knew that before v1 there will be few breaking changes and we all have to accept that. Kit fairly warned all of us for breaking changes. |
Beta Was this translation helpful? Give feedback.
-
|
I feel the same way existo does. I don't like writing frontends with JS frameworks, yet I learned Svelte. I replaced my mostly-static website from plain HTML with Svelte because it brings me joy. Svelte is what HTML should have been. It feels right On the other hand, SvelteKit feels terrible. Is bloated and complex, difficult to understand and reason about. I've spent a couple of weeks reading a lot of discussions on how to solve problems they have created by their own design decisions. I can name a few that stood to me The layout system that nobody asked for: #6124Why do we need layouts? Create a component and wrap your component on each page you want that layout to appear. You are making SvelteKit more difficult to understand, when this is something that already works on plain Svelte <script>
import MainLayout from '$lib/layouts/MainLayout.svelte'
</script>
<MainLayout>
<span>My code</span>
</MainLayout>This is the same thing that Astro is doing, and nobody is complaining about it Weird forms proposal that is more than thousand lines long: #5875I simply don't understand why you need such difficult forms design. This would feel "Sveltic" <script>
export let username = ''
export let password = ''
</script>
<form method="POST" >
<!-- Reactive on form submit, different from `bind:value` -->
<input type="text" bind:form={username} />
<input type="text" bind:form={password} />
<input type="submit" />
</form>I think it's self explanatory. Svelte is a compiler. It should be able to compile this component to some request handler that extracts extracts the form for me. Why am i doing extra work? The confusing routing system: #5815
Svelte Kit is confusing, and shocks against Svelte philosophy. I don't like Svelte Kit |
Beta Was this translation helpful? Give feedback.
-
Looks like a router limitation rather than a necessity. (Bug vs feature)
I don't see how a separate file on my filesystem is better that explicitly specifying which layout i want to use on each page. And as I said, it has been successful on other frameworks. I cannot say the same thing for Svelte Kit's approach
Proves my point. Favouring the compiler rather than the developer
Indeed it is not a bad thing, but making weird choices to attempt pleasing everyone has proven to be more harmful than good.
Plugins are a common approach for extending compilers. See gcc's plugin system, for example |
Beta Was this translation helpful? Give feedback.
-
|
You have inspired me to do a test, on the A simple test of Effect at SSR: A white page until the timer counts down in load-await.mp4Effect without SSR: White page, empty async-load-without-ssr.mp4Do you think this behavior is useful? |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't look useful to me, but sure someone could potentially need this feature. My ideal API would be something like this: <script>
let promise = fetch("https://example.org").then(x=>x.text)
</script>
<!-- Await block means no response will be sent until the promise fulfils -->
{#await promise}
<!--
We can provide some of fallback screen for client routers to display. Only visible
on client side routing
-->
{:then resolved}
<!-- HTTP response to the client -->
{:catch err}
<!-- HTTP response to the client -->
{/await}The compiler should be able to infer that we are awaiting something on a page, and thus create a page handler that doesn't respond until the page has fulfilled all pending promises. This will effetely be the For <script>
// AsyncFetcher has the same code as before, but because
// it's a plain Svelte component, promises aren't server awaited
// (it's considered reactive, and cannot be fully SSR)
import AsyncFetcher from "$lib/AsyncFetcher.svelte"
</script>
<AsyncFetcher/>It has both behaviour as you described, with an API that doesn't shoot yourself in the foot.
|
Beta Was this translation helpful? Give feedback.
-
|
Many things in SvelteKit, have never been well justified. There is certainly an argument given that SvelteKit is supposed to be file system based, meaning that by looking at the project folder tree, you are supposed to know more or less what is going on. It's not pointless, because if the page files exist anyway, why not put them in folders that are equivalent to the url path. This is ok. |
Beta Was this translation helpful? Give feedback.
-
|
I explained the first two in #6005 (reply in thread)
What if you want to mix and match? I have some pages on my site like the homepage, about page, etc. that are static while other pages are interactive. It's nice that I can build both with the same framework. And if I want to build both types of sites I don't have to learn two frameworks, but only one. Astro is great and I love the idea of doing partial hydration, but they've had to build the framework without building any features into the core of the language, which makes it look different than what we might eventually support. I'd really love to build support for partial hydration directly into Svelte 4 core and by building a framework just for Svelte we have some advanced knowledge of what that might look like and can position the framework accordingly. |
Beta Was this translation helpful? Give feedback.
-
|
Just getting back from a 2 week trip, I've had a bunch of time to think about how I would recommend the Kit team proceeds. Here are some more/new thoughts. Various ppl have quoted the "The 2 hard problems in computer science..." quote in this discussion and others for this project. But no-one has offered a rationale as to why naming things is hard. I argue that naming is hard because it is deeply personal.And as such, a framework or library that would like to see mass adoption should side-step as many personal decisions as possible. Another thing that I've noticed is that Kit is attempting to build an API by way of file and directory naming conventions. This seems like a good idea at first, but quickly becomes untenable once more and more functionality is stuffed into the "API". Here's an example evolution of functionality for filename-based API:
Can we take a step back and ask ourselves, is this really worth it? We added filesystem-based routing to make it easier to build web apps. But then we overloaded the filesystem naming conventions with so much extra functionality it makes the imperative approach look downright simple. Suggestions for the team:
If I had to choose just 1 of the above suggestions to be implemented, I'd say we should remove Layouts. They are straight up unnecessary and can be implemented in "user-land." My second choice would be to expose the route config via a programmatic API so I can put my routes wherever I please. Also, this would open up the ability for folks to package their routes to be distributed via NPM. Imagine building an OAuth handler like Passport for Kit... :) Respectfully, P.s. Beware the sunk cost fallacy! It's not too late to undo some of the recent contentious and unnecessary complexity. The community will support Kit as long as Kit is making good decisions with a focus on DX. :) P.p.s. I'd recommend the Kit team define "done" for the framework. What should go in and what should be left to the community to build? Hopefully, you'll see things like Forms don't belong in the framework while things like Security do. |
Beta Was this translation helpful? Give feedback.
-
There are a lot of people who prefer the new naming scheme and then they'd all be complaining that we went back. Everyone has their preference and there isn't really a right or wrong answer here. It's pretty subjective
I agree with this one
Imagine your layout shows the currently logged in user. Without layouts you would need every single page to fetch the user details and then pass it in manually to the common UI component. It would quickly become a pain
The framework is doing things that would be very hard to implement outside the framework. I'm not sure how you would write your own validation handling while supporting progressive enhacement. If you were handling the POST in a +server.js yourself, you can't render a page from there, so you basically have to persist form values and validation errors somehow then redirect to a page, and somehow get the values and errors into the page. It might be possible, with sufficient ingenuity, but for all intents and purposes it's impossible. For anything realistic you basically have to use the actions we provide |
Beta Was this translation helpful? Give feedback.
-
Something like this would be good to enable routes as libraries, so you could mount a set of functionality in the route tree. An example might be a user membership management tool. |
Beta Was this translation helpful? Give feedback.
-
Unfortunately, breaking up the server-side logic that would fetch the logged in user from the page query, (e.g. show the user's profile) will cause the queries to use separate server-side resources. Which leads to race conditions. Imagine you have a logged in user who is viewing their profile at There exists a race condition where the user logs out after the layout Which is to say, I will always put the layout-specific queries into my endpoint in order to share the DB transaction. |
Beta Was this translation helpful? Give feedback.
-
Show me how SvelteKit could achieve this functionality without layouts. |
Beta Was this translation helpful? Give feedback.
-
|
I'm studying Svelte. I found it simpler and more direct than Vue and React. But when I started studying SvelteKit I was scared. I tested Astro with Svelte and really liked them. Now I'm thinking about aborting the Svelte study because of the SvelteKit complication. What will the author do with Svelte in the future? |
Beta Was this translation helpful? Give feedback.
-
|
(about)/about/+page.svelte stuff kinda killed sveltekit for me too, elegant/intuitive part was just wiped away... |
Beta Was this translation helpful? Give feedback.
-
|
Can you detail what has changed using your IDE? It is supposed to mostly work the same since file paths still contain the same keywords as before. |
Beta Was this translation helpful? Give feedback.
-
|
file names changed, so, instead of workflow, settings, users....you get +page,+page,+page.... (admin)/admin/(settings)/settings/workflow/+page and to select next file I have to go:
My tree used to be admin/settings now it is (admin)/admin/(settings)/settings/ because of layout reset stuff...and than it goes a bit deeper with all endpoints we have. I do love svelte(kit a bit less now) and being a backend developer mostly, svelte brought me some joy and desire to do more frontend related stuff...hopefully someone comes with a routing plugin that makes sense (to me).. there are some sk alternatives to explore, so it is not end of the world...(as long as it is not based on angular or react, that didn't work for me). |
Beta Was this translation helpful? Give feedback.
-
|
Why are you using the |
Beta Was this translation helpful? Give feedback.
-
|
I am not the one who converted layouts part, but I believe we are using/need group layouts. This project is a bit extreme in that area (using different layouts based on user rights and some "dynamic" markup/styling injection for white-labeling purposes among other things). |
Beta Was this translation helpful? Give feedback.
-
|
I understand your struggle now since you use a tree navigator. I guess the "ctrl+p" metasearch shortcut is now some sort of standard among editors (and users) and this method didn't really suffer from the change (in your example just hit the shortcut and type |
Beta Was this translation helpful? Give feedback.
-
|
I silently dream of something similar: That is, a router would be something that has a But just giving up the Write down about such a possibility, somewhere in "Advanced routing", so that no one would cling to the fact that the documentation is then too complicated. |
Beta Was this translation helpful? Give feedback.
-
|
I have a strange idea. Then such custom routing, would even have support for load and the rest of the module properties. Check this out: But as if to use So in // src/routes/blog/[...rest]/+page.js
export async function load({ params }) {
const load = await import(`./${params.rest}.js`);
const {data} = await doLoad(load);
const mod = await import(`./${params.rest}.svelte.md`);
return {
post: mod.default,
data
};
}<script>
export let data;
</script>
<svelte:component this={data.post}, data={data.data}/>Eventually, in the I'm assuming my example has errors, doesn't include something, but it's meant to convey the general idea, ok? What do you think? All you need is O! Yet to be able to add such a file of your own routing, using a package, without Adder. So that this file does not litter the |
Beta Was this translation helpful? Give feedback.
-
|
I think it'd be wise to hold judgment until 1.0; and trust (and maybe help) the team to do the right thing. |
Beta Was this translation helpful? Give feedback.
-
|
Or wait for version 2.0 or 3.0. :P |
Beta Was this translation helpful? Give feedback.
-
|
Or use another tool. Routify looks promising |
Beta Was this translation helpful? Give feedback.
-
|
Not trying to beat a dead horse here, but in case anyone is looking for simpler routing, less magic, and more flexibility without sacrificing performance: astro looks like it is going to fit the bill.
If/when SK goes back to simpler routing and removes layouts and undoes a bunch of the complexity thats been added, I'd be happy to switch back. But for now I'm gonna give astro a shot. |
Beta Was this translation helpful? Give feedback.
-
|
I'm guessing Spring as in the Java framework? I might be missing something but it doesn't seem any better than what you can do in Astro. |
Beta Was this translation helpful? Give feedback.
-
|
From my understanding, Astro doesn't provide the following features on forms:
It's a common pattern in other server side frameworks to provide a Model class which defines all validation requirements (such as RegEx, or null checks). The framework generates forms based on that specification. You only write your validation logic once for both the client and the server. |
Beta Was this translation helpful? Give feedback.
-
|
ah, gotcha. Those are definitely nice to have but I wonder how it can be implemented when Astro relies on other JS frameworks for client side login. |
Beta Was this translation helpful? Give feedback.
-
|
Typically, astro isn't an spa, so when switching between pages you'll see a browser reload. |
Beta Was this translation helpful? Give feedback.
-
|
Astro has built in "SPA feel" now, simply import ViewTransitions in your head and it's an SPA! https://docs.astro.build/en/guides/view-transitions/#full-site-view-transitions-spa-mode Animations don't work in Firefox, but it feels like your regular SPA, no page reload |
Beta Was this translation helpful? Give feedback.
-
|
There have been previous discussions on this one before - #5748 When I first caught sight of the changes my first reaction was yeeesh. Ultimately you won't find a one size fits all. Personally I think one way to get around this and avoid a lot of the problems. That way you'd leave the end choice up to the end developer as to which option to go for. Personally I've kind of moved away from sveltekit for now, it looks as if the future might be Vue 3.3 In response to the original dog meme that was posted in the other thread I couldn't resist but post my own :) |
Beta Was this translation helpful? Give feedback.
-
|
As per @Rich-Harris "Best API is no API at all." was said regarding Svelte 3 in https://svelte.dev/blog/svelte-3-rethinking-reactivity. I would love to hear the same about SvelteKit, but unfortunately it's not the case. SvelteKit is not developer friendly and requires reading docs that didn't explain everything in clear way, there are a lot of I believe SvelteKit 2+ would be much cleaner/better. |
Beta Was this translation helpful? Give feedback.
-
|
Honestly everyone seems to have moved on about this topic since long (even on the discord), some adapted, some left, some came back, most of those who tried for a few minutes realized it's exactly the same and went on their blessed journey with svelte-kit, you should probably do the same. |
Beta Was this translation helpful? Give feedback.
-
|
"most of those who tried for a few minutes realized it's exactly the same" problem solved, let's move on... |
Beta Was this translation helpful? Give feedback.
-
|
Personally I would respectfully disagree and say directory and file based routing are very different. That being said I think all the pros and cons of the different approaches have already been covered. My own personal preference is that when you get above a certain level of complexity it's probably better to do something in code rather than special syntax's. But ultimatley where that threshold is set in so far as simplicity vs complexity is going to be up to the dev's of the project as they'll be the ones putting they're time into maintaining it. |
Beta Was this translation helpful? Give feedback.
-
|
I had been writing a fairly large app with the beta version and was hoping that this migration would not be too difficult. I have no problem with the file-based router and actually like it, but the props data and also the fact that sessions are gone is going to require quite a bit of re-factoring. The reason I started developing with Sveltekit in the first place was that it was easy to work with and, well, svelte. It seems to have gotten a little over-complicated. |
Beta Was this translation helpful? Give feedback.
-
|
Oh man, I got to this comment when I decided to finally migrate my "life changing entrepreneur" website. Just kidding, finally the website was showing like nothing happened, everything was working, supabase was not affected, I could log in, chat, etc. I did it, I did the migration. |
Beta Was this translation helpful? Give feedback.
-
|
Old threat but had to weigh in. Built some fairly large apps, worked on two enterprise apps, still do. From Backbone to Angular to React and everything in between. SvelteKit was pretty clear that things may change. It wasn't a production release. While many had that ahhh crap moment as they realized there would be refactoring, it really wasn't all that difficult and I believe it's for the best. So if you find this, just bear down and make it happen. It won't be that tough once you set your mind to it. That all said I can't think of another frontend framework that's as much of a joy to work with. It really is great IMO. While there are a few other promising frameworks out there Svelte is a top three frontend kit in my book. |
Beta Was this translation helpful? Give feedback.
-
|
Again very late bump but I agree 100% @DanBaDo. I absolutely love Svelte. After playing around with it for about a day, I already felt like I "got" it. Using it is a joy instantly and, most of all, extremely productive. For SvelteKit, it took me about two weeks to really "get" it. Yes, things make sense and it’s not horrible to use. But coming from Svelte, I guess I just had higher expectations, maybe? Svelte’s DX is amazing, it’s a joy! SvelteKit is ... good. File-based routing is fine, but I hate the naming conventions. I’m 2 months into building a client project with it now and I still get annoyed and confused about which +page.ts or whatever I have open right now. Yes I configured VSCode to show directory names in tabs, I know about all the tricks. It’s still annoying and makes me slower and more frustrated whenever I work on two routes simultaneously. (Plus, other editors might not have that option. In general I find SvelteKit harder to use in Editors that aren’t VS Code and while I’m fine using VS Code, I don’t want an editor monopoly and I don’t want my favorite project to further it.) I don’t understand why it would be an issue to just give me the option to name a file "routename.server.ts" or "markup.svelte". My life would be a lot better already. And then there are still things like load functions or managing some stores that feel quite boilerplatey and confusing at times. It’s hard to actually point to specific things, but with SvelteKit I just sometimes feel like I’m sitting in front of nebulous code cloud, even with a fairly simply project. So yeah, to echo some here: I really hope Svelte will be maintained, because it’s amazing and I don’t want to miss it. Worst case you can still use SvelteKit in csr mode, but that’s not the same. |
Beta Was this translation helpful? Give feedback.
-
|
@liam-k you're not alone. I still have a major SaaS on .405. The rest of my SK apps are all on the new naming conventions, and I absolutely hate it. It's been months and nothing has changed. I'm not more productive. |
Beta Was this translation helpful? Give feedback.
-
|
Just saying: with the addition of middleware on Astro, there is no need to use Sveltekit. I strongly suggest that anyone who finds the meta frameworks obnoxious to use a combination of Astro + Svelte + HTMX/jquery. It feels a lot like making a good old PHP website but with much better tooling from the JS ecosystem and none of the complexity of Nextjs nuxtjs or whateverjs. We have been writing websites that way since the 90s. I think we can use the same techniques today... |
Beta Was this translation helpful? Give feedback.
-
|
Just wanted to leave my two cents here as well. I have been working with Nuxt.js for years now, both on private projects and on various enterprise apps for a large corporation. Since the beginning of 2022 I'm working on another big web app for a different company with Angular. Was eager to learn it, grew to hate it. Luckily, in preparation for an upcoming project, I was tasked with looking for something else. Instead of diving right into Nuxt 3.0, I thought it might be a good idea to look around and make a well informed decision. So I gave Svelte Kit a go as many developers attest it a great DX. Early on Svelte seemed like a no-brainer. Now, after fiddling around a bit, not so much. The routing is a bummer. The Anyways. Svelte is lovely and Svelte Kit is neat. Both are much appreciated! Thank you so much for pushing the technology! |
Beta Was this translation helpful? Give feedback.
-
|
@Altair-Bueno -> i want to look into that, sounds amazing. |
Beta Was this translation helpful? Give feedback.
-
I feel the same way. My goal was to move away from the cumbersome nature of React/Next and my mind went to Sveltekit. However after trying it out I have the same reaction as you do |
Beta Was this translation helpful? Give feedback.
-
|
Svelte is good framework but sveltekit is bummer to me. After tryng to fitted with my need i just can't bear my self with routing folder decision, it's so cumbersome, the way that sveltekit flow feels is same as remix but not with route model, for me why svelte doesn't take that remix do with flatfile, it's more readable, configurable and organized. |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. I have made many examples of why a router config that specifies files is better than a folder based router. |
Beta Was this translation helpful? Give feedback.
-
|
I just upgraded the project. How is this 'json' function response better than the previously inferred type? I can't switch functions not related to API responses in now cause of this decision.. I feel like it's going from a good project into legacy by adding and adding instead of using the strengths of TypeScript. 
|
Beta Was this translation helpful? Give feedback.
-
|
It's explicit, and allows you to return other types of response (e.g. streaming) The return json({ message: 'success' }) |
Beta Was this translation helpful? Give feedback.
-
|
@CaptainCodeman why couldn't you have both and infer the streaming type? Would have been simpler and a flexible implementation. Many of us reuse functions across projects and other TS projects infer the returned type. Also we use an auto Zod implementation of OpenAPI which is now broken because of this. There's many other issues with this :-/ |
Beta Was this translation helpful? Give feedback.
and others
-
Let me first say that I am very grateful about everyone who dedicates their time and effort in this project. Being a co-maintainer for a large Go library myself, I know how much time, weird issues and discussion and other things strain the life of a maintainer and open source developer.
Now this is probably going to be an emotional rather than an objective post, but I somehow have the urge to at least voice my opinion on this. For a little bit of a back story, let me share that basically though-out 2020/2021 I was very frustrated with web development per-se. At work and in my "GitHub life" I basically started out with angular1, and made the journey until angular 10ish at which point I was totally frustrated and looking for opinions. I basically tried to "learn them all" vue.js, react, and so on. Finally, somehow in beginning of 2021 I stumbled across this "svelte" project and I was blown away. Finally, I got joy back in actually programming web applications and when I found out that svelte kit offered a nice way to wrap everything up in an "application", I was basically through the roof. Just create some
.sveltefiles here in a nice, clean folder/file structure and BAM, you have yourself a nice web application.Now, I am not a professional frontend developer, nor do I work on my web apps everyday. I do not need any "enterprise-grade" frontend library, otherwise I would have probably stuck with angular.
I tried to update my svelte kit App today after a while (from 0.3xxx) and I was sort of in shock what happened. First I though ok some things changed with the vite config fair enough. But the biggest "shock" was the new routing system and the way "data" props are handled now. I scrolled through the discussion (which I all completely missed because of the lack of time lately) and while I understand that some things make sense from a technical point of view, as a user (albeit, "non-professional"), I cannot understand them at all. svelte kit was a good, clean way to design (maybe a smaller) web application with simple routing and simple template props and that is basically gone now. I tried running the migration scripts and I gave up after about an hour, somehow my simple application with 8 routes was too complicated for it, maybe I am also just too emotionally tired to try it at the moment.
I understand that I have no right to "demand" anything here. I suspect that this post is probably going to be locked, since you also locked the discussion on the original design thread. I just wanted to voice the option of the "little guy" web developer that was actually quite happy with this very nice lean, easy web framework that now seems to be gone.
Beta Was this translation helpful? Give feedback.
All reactions