A few reasons why updated routing is an improvement from the previous design

[nikfp]

I've seen a lot of negative feedback on this repo about the updated routing. I know that within the community this has been a huge point of controversy, and the core team did a great job of explaining the technical reasons for making the change, which were sound. I thought it would be useful to post a few reasons why this was a good change from less of a technical, inner workings perspective, and also encourage others to share their opinions. All of my points are in response to opinions of others throughout the community.

TL:DR

• The new changes to routing are positive, albeit different
• Ergonomics in codebases are improved
• Much ambiguity is removed overall
• Things are simpler to reason about
• Most of the philosophical issues people are having can be viewed from a different perspective and actually make a lot of sense
• Most of the technical and ergonomic issues people are having can be solved by an updated approach
• The sections below got longer than expected.

People don't like the + character at the beginning of files.

I've seen reasons for this ranging from "I don't understand" to "It fits no current convention out there" to "I just hate it and it's ugly".

Let's think about this for a moment. To start with, index.** is a current convention for JS based projects to access the entry point of something - package, application, website, etc. But at one point, this wasn't a convention. It could have just as easily been entry.** (which semantically might have made more sense) or start.**. I can see where the friction comes from that SK is moving away from the broader convention, but it's to the benefit of the framework as a whole. Every innovation ever didn't make sense until someone did it and the benefit became apparent, and then it made sense. So if we give index.svelte some further consideration, it stands as the entry point, but to what exactly? In the context of SK you had to read the docs, know that the filename was reserved and for what purpose, and then you could effectively use it, because unless you had one page, you probably had many more than one index.svelte lurking. This left a possibility of some confusion to the developer new to SK, because you could clone a repo, open it up, and make an assumption on what index was and how it would behave. This in turn could lead to some bad (or even dangerous) practices.

Then we had the other "special" files - __layout.svelte, _db.ts, etc. Everyone thought this was great, but to me it always felt a bit disjointed. Nothing was consistent, there were reserved filenames, you had a load function in a separate script block in a file that pulled information from a sibling endpoint file, an underscore meant the file wasn't considered a route but two underscores followed by one of a handful of special names meant that it could represent a route - or a layout - or a reset - or an error page. I found myself in the docs all the time until I was able to grok all of that through sheer memorization. I'm sure others had the same experience.

The contrast to this is the new + character and directory based routing. From the perspective of someone who has never been in a SK project and clones a repo, the first thing that comes to mind is "this means something, and I need to know what". You are prompted to read the docs or ask someone who knows, and to learn it. This is good because it removes most of the opportunity for ambiguity and confusion by forcing the developer to learn what they are looking at. Every framework has it's quirks, including NextJS, Nuxt, and Angular. This puts up some guardrails and encourages you to understand the SK quirks before you fire the foot gun.

THEN it actually gets much simpler, because reasoning about the file system for routes follows a concise set of heuristics:

• Routes are represented by the directory. How each routes behaves is represented by the files in the directory
• The + character indicates that the file has a direct role in the functionality of the route. No + character and the router doesn't care about it. Add co-located support files as needed. (but you probably won't - everything can be done in the + files or should probably move into $lib anyway)
• Anything with page in the name pertains to the page at this level of the directory structure
• Anything with layout in the name pertains to this level and any descendants
• Anything with .svelte on the end pertains to rendering and related logic
• Anything with a .ts (or .js) on the end has to do with data and not rendering
• Anything with server in the name only runs server side.

That's it. Now there is logical separation of what file does what task. .svelte files get cleaned up as load blocks move out, things get abstracted away, and the overall experience is cleaner. I read through the new docs ONCE and this made sense, and I haven't had to look again. People say the new way is less intuitive, I disagree.

Back to index vs page. You are working to render a page, correct? Using the page naming conventions is about as semantically accurate as you can get.

People don't like the directory based routing vs the File System based routing

Why though? Directory based routing sorts better, making it easier to find things. It's clearer what does what - a directory is a route, the files in the directory define behavior. It's still file system based routing, but it's actually simpler if you look at it.

As an example, here are two file paths on the old file structure:

routes/customer.svelte
routes/customer/index.svelte

Those two files output exactly the same route. So which do you use and when?

Here's the new way:

routes/customer/+page.svelte

That's it. You do it that way. No ambiguity.

Here's another example:

routes/project/index.svelte
routes/customer.svelte
routes/orders.svelte

How does this sort? Just like I listed it. The problem is when a human is looking through this, orders should go before project, but it doesn't. Similarly, customer should be listed above both orders and project, but it's in the middle. This is default sorting behavior as seen in your editor sidebar or if you list files and directories in the terminal. Great for computers, bad for mere mortals.

You can update to the new way, and it all sorts in the proper order:

routes/customer/+page.svelte
routes/orders/+page.svelte
routes/project/+page.svelte

I know which one I'd rather be pawing through.

Searching for files is now too hard --- too many +page.svelte

I acknowledge that there are now more +page.svelte files in each project. That's the nature of the update. That said, I have two points on this.

First, you should try searching by directory instead of by file. It's actually easier to get right to what you want by doing so. For example, take this file structure again:

routes/customer/+page.svelte
routes/orders/+page.svelte
routes/project/+page.svelte

Hitting ctrl+p in vscode and then searching for project page sv gets you one result: routes/project/+page.svelte. Even if that same directory had a +page.ts, and a +page.server.ts in it, you would still get one result. Swap to project page server and you get the server file, and that's it. Use the fuzzy search and save yourself some headaches. customer gets you into that directory, orders gets you into that directory, etc., then add something unique about the file you are chasing.

Second point, this isn't really very different than it was before. I'd bet your project had a heck of a lot of index.svelte files strewn about. So you would have still gotten a lot of results searching for index anyway. To get something useful back you would have entered another character string to narrow it down. I recall using the fuzzy search before the same way I do now. I don't find myself using any more keystrokes, and since things have clearer separation of concerns I can actually better target the file I'm looking for.

I now have a hundred +page.svelte files open at once.

Yes, but should you? I can't think of a good reason I'd be working on more than one or two files at one time. Someone may post a valid reason otherwise, but why not close the rest? Problem solved. I get anxiety when my text editor has too many tabs open. One task at a time.

If you still need some clarity on where you are, your editor probably has a breadcrumbs feature. Turn it on. Never lost again.

One last thought in closing:

It's important to remember that innovation can't happen without change. We all want things to get better, but there is a stability sacrifice we have to make in order to do that. It's more so on a framework that is still in beta, which practically guarantees breaking changes, AND it's a JS framework, meaning things are going to move really fast anyway.

Another way to look at this is the old quote:

"The definition of insanity is doing the same thing over and over again and expecting a different result"

Feedback from others is welcome and appreciated.

[sandstromdev]

I really like the naming changes.

Previously, you had your svelte file: index.svelte. If you wanted to get data from the server, you'd fetch it in <script context="module"> inside that same file. But you couldn't query the database directly, since the load function had to be able to run in the browser as well. Therefore, you had to have another file, index.js, containing a GET handler that would query the database and respond with the data. You could also fetch the data from an api route, but for small applications you might feel like it's a bit overkill to maintain a whole api.

Now you just add a load function in +page.server.js next to your +page.svelte and query the database directly, and like magic, the data is right there in export let data.

The projects I'm working with now are pretty small, so it makes total sense to put the logic right next to the page, and it makes it very clear what the different parts are doing, and in what order they're doing it.

Another pro is that making every route a directory makes it really easy to add sub routes later without having to deal with a bunch of refactoring.

[moisesbites]

I am work in a big project using sveltekit. In the begging, it was Sapper. So, we did migration to sveltekit. After recent version update, I had a lot of work to understand the new route system, to chande code to reflect in the various layout paths, the new data object and how to live without session. It's worth it!

Now, I don't want to come back to the old version. Sveltekit is more powerful and flexible now. It's the best to develop web apps.

[ZetiMente]

As someone being vocal in the discussions today and in the "I just hate it and it's ugly" for the + camp, I will take the bait. Nothing but respect for everyone. I'm glad we can have these discussions.

TLDR; "There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton

Let's think about this for a moment. To start with, index.** is a current convention for JS based projects to access the entry point of something - package, application, website, etc. But at one point, this wasn't a convention.

The thing though, the index comes from index.html. This has been around since the beginning of HTML. The convention was born with HTML. Then if we look at the next progression of the web, we have index.php. So JS didn't invent this convention, it was passed down. React & Angular picked up these conventions, which naturally lead to Svelte having it as well. But whether we call something index or page is irrelevant. Only pointing out that index has a long tradition.

SK is moving away from the broader convention

In life and in computer science especially, you should follow convention unless you have an extremely compelling reason to go against it. To do otherwise is hubris; that you know better than the many brilliant people who came before. Usually, there are very good reasons why something wasn't done before. Change in itself is not a virtue. And does not automatically lead to innovation. Many times it makes things much worse. Especially when so many people have had a visceral response to the change. So is it because people don't want change, it happened too fast or that the reasons aren't extremely compelling?

Then we had the other "special" files - __layout.svelte.

So this is another convention that SK borrowed from PHP, Ruby & Python. In Ruby & Python, you would use __ FILE __ and in PHP it was used for magic functions. C+ reserves __ for the compiler's. _ has commonly been used in computer science for file names, data fields, spaces, italics in markdown in or to designate private. It's a natural fit in programming.

You are prompted to read the docs

For starters, literally the docs say about the + is "Each route directory contains one or more route files, which can be identified by their + prefix.". So if nothing else, the docs need to be way more explicit and clear. Secondly, this is induced friction. Sveltekit is the underdog here. In an extremely competitive world, especially with React, Next, Solid, Vue, Nuxt and Angular. Adding any hurdles to a newcomer at the very beginning is bad news. The first step that you want for trying to onboard someone is not confusion. Third, this is very optimistic thinking. Many people are just going to give up and move on. This is firing the footgun right at the start. In my experience onboarding people, they're going to put the components in lib/components. This footgun everyone talks about with _Component.svelte being exposed as public seems imaginary. And if it does exist, seems to be a poor justification for ruining a clear concise file name with an objectively ugly +.

The + character indicates that the file has a direct role in the functionality of the route. No + character and the router doesn't care about it.

But why though? Why can't a normal file name be the direct role in the functionality of the route and the _ character means the router doesn't care about it? Shouldn't public and working be the default? Is this really worth all the pain & confusion ? And what problem is this solving exactly? People might expose a component? What other framework in history has ever made routes private by default?
And yes, + is ugly and out of place. It has never existed before ever in file names. It means add or plus. To use it to mean public in a file name is perverse. I understand, that at one point in time, every symbol didn't have meaning. But symbols evolved over time to become what they mean. Ruining every filenames aesthetics so someone won't make an accidentally public route is ridiculous. The _ is the convention for private and a normal filename is the route. The file should look and work by default. Why do we want RTFM by default? Why do we want broken by default? Everything should be clear and easy OTB to maximize the number of people to join Svelte Salvation.

People don't like the directory based routing vs the File System based routing. Why though?

The reality though is that with File System routing, you have directory based too. So it's not like the routing changed, it's more that the flexibility and freedom of file system based routing was taken away. You could always make a folder and throw your route inside before. But now you are forced to do this. The File System based routing is more intuitive to me because that's how I organized stuff on my own person computer. I don't make a folder to put a single file in it. I make everything as concise and pithy as possible. I love pithy filenames. Sacrificing usability, flexibility and readability for Maintainability is not a good trade off. (Especially since I don't maintain SK. Ha!)

I have all this redundant naming now and folders with a single folder in it. Instead of shop/product/[id].svelte, it is now shop/product/[id]/+page.svelte. An extra folder for what gain? That is losing order and organization in my folder structure. I could make it shop/[id]/+page.svelte but I also have shop/cart/[id]/+page.svelte too !

If something doesn't need to be a folder because it only contains one item, then it shouldn't be a folder. A folder is conceptually for containing many items. It's best to have your folder structure as shallow as possible so you're not constantly diving unnecessarily deeper. That is order. Otherwise, everything becomes bloated, hard to find and difficult to manage. Instead of api/cookies.ts & api/darkmode.ts, I have api/cookies/+server.ts & api/darkmode/+server.ts.

This adds a completely unnecessary directory! Having a folder of api/ with all my routes there makes perfect sense and is the most rational way to organize it. And how its always been done and "if it ain't broke, don't fix it!" This supposed benefit of making routing level by folders is dubious when I'm forced to make my folders unnecessarily deep. And did anyone really care about that before anyways? So what if you have todos/ and about.svelte? If you care that much, you still had the freedom to make it todos/ and about/. But now you're forcing me to do it as well! This has caused my entire project to be so bloated now. Don't be fooled. The amount of complexity in the system is the same, it's just been shifted.

Yes, I can do CMD + P in VS Studio. But I should also be able to find my files in the directory easily ! I had that before and now it's lost. Using a specific feature of a tool as a crutch is bad. It's a sign of disorder. I can cruise through my directories much faster than CMD + P so again, wasted time for me. And I get that some people use CMD + P. But not being accommodating of people's development styles is a sign that the DX is no longer a priority. . Easiness is being traded for "Simplicity".

I'd bet your project had a heck of a lot of index.svelte

This is true, but I also had a lot of files with actual names like profile.svelte and help.svelte so the burden was most less.

I now have a hundred +page.svelte files open at once. Yes, but should you?

No. But what is the reality? We all have too many Chrome tabs and VS studio tabs open. It's the nature of the beast. However, we shouldn't do things that exacerbate it. And shifting blame here to the developer instead of acknowledging that this slows down work, and reduces DX is suspect. It's a red flag to me when I'm being told how to develop.

It's important to remember that innovation can't happen without change.

The truth though, this isn't really innovation. It's pretty similar to how you would organize a Java project.

What innovation is happening here?

The directory based routing already existed. The file routing option was just taken away.

The + isn't an innovation. It's just switching from routes working by default to routes being broken and private by default. So now instead of putting _ on private components that are colocated in routes/. We're putting an ugly + on every single file that is public.

I'm not a big fan of having files that say only export const prerender = true; but I can see the benefit of separation of concerns for modules as that is an actual pain point. And the load is more precise now. But innovation?

Svelte was innovation. Making a project more ridged isn't innovation. It's just sacrificing the beautiful development experience and flexible filesystem-based routing that the SK home page claims. Flexibility & functionality was just taken away in the name of "simplicity". Where did this notion that two ways to do something is a sin? Since when is two ways to do something confusing? A million ways to write this sentence. Perhaps if the file and folder routes contracted, but it was pretty clear. Is simple a greater value than DX?

To be clear, my only issues are the naming convention, private by default aka the + and removal of file based routing. Which at the end of the day is pretty petty. But...

It felt like before that productivity aka easiness (the DX) was the supreme value. Now it seems it has shifted to the philosophy of Rich Hickey. A man who hates ORM. Even though ORM are easy & save massive amounts of time. A man who created Clojure, which is a dialect of the Lisp programming language on the Java platform. If that gives you any hints. The man is far more brilliant than I will ever be. But in 2022, I'm using server-less Firebase with SK for maximal productivity and ease. Minimal code. Maximal results.

Easy Made Simple.

[nikfp]

@ZetiMente Thank you for the well thought out response! There is a lot that you said that I agree with, some things I don't, and a few things that could be clarified.

Regarding Index files, your take on it was:

The thing though, the index comes from index.html. This has been around since the beginning of HTML. The convention was born with HTML.

This part I agree with for the point you are making. The point that I was making though, was not that in index.svelte is inherently wrong, but that having multiples of that file name was semantically incorrect in my eyes. Further to my point in that section is that moving to the + character was addressing a lack of consistency that was built in in the beginning of SK.

You mentioned:

In Ruby & Python, you would use __ FILE __ and in PHP it was used for magic functions. C+ reserves __ for the compiler's. _ has commonly been used in computer science for file names, data fields, spaces, italics in markdown in or to designate private. It's a natural fit in programming.

This again is accurate, but diverged a bit from the point I was trying to make.

Putting it another way from what I said originally, when I started using SK I could tell that the naming conventions and practices adopted were done ad hoc and coming from multiple places. Routes could be described 2 ways, then you had _ files that were ignored, but __ files that were not, certain names had a meaning to SK and others didn't, load functions happened in the file, but loading data for them happened in a separate file, and it wasn't easy for me to understand. When the changes were implemented, I had the experience that it immediately made sense to me. It's important to note that that this is my experience and I'm not saying that is should or will be everyone's experience. We all think and perceive differently, so better for me is almost guaranteed to be worse for someone else.

literally the docs say about the + is "Each route directory contains one or more route files, which can be identified by their + prefix.". So if nothing else, the docs need to be way more explicit and clear.

100% accurate, I agree with this completely. At MINIMUM the docs should have a sidebar clarifying this, with the reasoning behind it and an acknowledgement that this is indeed different.

Secondly, this is induced friction. Sveltekit is the underdog here. In an extremely competitive world, especially with React, Next, Solid, Vue, Nuxt and Angular. Adding any hurdles to a newcomer at the very beginning is bad news. The first step that you want for trying to onboard someone is not confusion.

I see your point. I also see this another way. It's been my experience that learning how something works in one set of circumstances (react, for example) has a nasty habit of setting an expectation in my mind of how things probably work in another. This has been my personal foot gun many times. I have found that I am VASTLY more productive learning something new and working with it AFTER I have taken the time to get through the instructions. And not just in programming, but in life in general. So to me - and I stress this is just my opinion - anything that prompts me to get a good handle on something before I go nuts with it is almost always beneficial to me in the end. You see friction, I see guardrails I guess.

Why can't a normal file name be the direct role in the functionality of the route and the _ character means the router doesn't care about it?

Because SK needs a way to specify files that perform certain tasks. Doing it your way gets rid of the + character, but introduces a list of file names that are reserved again. Now instead of one character as the indicator, you have to memorize a list of words that mean something. To my mind that is harder to remember, and harder to pick out of a list in an editor, terminal, etc. Swinging this very far the other direction is more in the realm of what Nextjs is doing with thing like getServerSideProps, which solves the file naming issue, but introduces massive bloat in each file. I don't like files that are many hundreds of lines long, which is what I experienced in NextJS, so to me the tradeoff to this direction is worth it.

And yes, + is ugly and out of place. It has never existed before ever in file names. It means add or plus. To use it to mean public in a file name is perverse.

My reaction level to this is different. I get that it's not normal, I get that many in the community are strongly opposed to it, but to me it's not a big deal. I actually find the file structure easier to parse with my eyes this way. Granted it's unconventional, and you and I will disagree on this and that's fine, but beyond the unconventional nature it's not something that will affect me.

If something doesn't need to be a folder because it only contains one item, then it shouldn't be a folder. A folder is conceptually for containing many items. It's best to have your folder structure as shallow as possible so you're not constantly diving unnecessarily deeper.

I agree with this, but in philosophical isolation. This to me is an ideal that we all strive toward.

In practice it's a bit different. I don't see how to consistently do the routing while also maintaining the concision you are chasing. In isolation you are correct. In practice, a tradeoff needed to be made.

Having a folder of api/ with all my routes there makes perfect sense and is the most rational way to organize it. And how its always been done and "if it ain't broke, don't fix it!"

This is true, API folders will be a mess because they could be so simple to begin with. If I had hands in this to do something about it I would make a sibling folder to routes/ that would be api/ and could operate under a different set of constraints, simply because not rendering logic is needed. So in short, make it simpler because it's possible to make it simpler.

And did anyone really care about that before anyways? So what if you have todos/ and about.svelte? If you care that much, you still had the freedom to make it todos/ and about/.

I did 😮 I cared about it. You are correct that we could arrange projects we controlled however we wanted, but every project I cloned was different. Sorting was wacky, and not consistent between projects, because people did it differently because they could do it differently. Now it's consistent.

But I should also be able to find my files in the directory easily ! I had that before and now it's lost. Using a specific feature of a tool as a crutch is bad. It's a sign of disorder.

I see your point, however I am also seeing my directory traversal moving faster in the terminal. So yes and no? Guess it depends on the person?

... But what is the reality? We all have too many Chrome tabs and VS studio tabs open. It's the nature of the beast. However, we shouldn't do things that exacerbate it. And shifting blame here to the developer instead of acknowledging that this slows down work, and reduces DX is suspect. It's a red flag to me when I'm being told how to develop.

You should not be told how to develop. And to be clear before what I'm about to say, I would never be so naive as to make assumptions as to how your mind works. It's been my experience that my productivity is inversely related to the number of tabs I have open - of any kind. I need to focus on one thing at a time. My wife can think about 9 things at once and do it well and I envy that, but ergonomics are better for me with less.

The truth though, this isn't really innovation. It's pretty similar to how you would organize a Java project.

Oddly this statement fostered a lot of thought on my part. On the one hand, that kind of structuring is reminiscent of enterprise grade solutions in an OOP language. I can think of a lot of valid reasons to move away from that. On the other hand, that kind of structuring is reminiscent of enterprise grade solutions in an OOP language. Those have been battle tested for decades. I'm going to reserve a response for later on this one. (And thanks for the thought fodder!)

I should also note at this point that I started programming in .NET, so OOP thinking does influence my rationale, at least as a contrast to the JS ecosystem. I should also note that I gladly never type the word "class" in JS code. That whole "everything is a class" that Java and .NET have in common is truly obnoxious.

It felt like before that productivity aka easiness (the DX) was the supreme value. Now it seems it has shifted to the philosophy of Rich Hickey.

For the most part I disagree with this, but I think it's a matter of opinion more than anything else. Not what you brought up about the philosophy, but more about my experience with it. l LOVE prisma, I think Firebase and Supabase are doing really cool things, and my deployment targets are Vercel and Cloudflare. If we didn't use ORM's as Rich Hickey posits, the first thing any of us would do is get annoyed at the data layer and start building abstractions to simplify it.... which is an ORM. So yeah, you are correct here in your point.

To me the change in SK made things easier, which is why I'm defending it. If it was a neutral change to me I would be on the sidelines or out of the discussion altogether. If it was negative I would be in the opposite camp making noise before SK hit 1.0. One thing is for sure, the change sure is polarizing and I'm understanding that even though it got easier for me, it got harder for you.

[ZetiMente]

@nikfp You have brought up some excellent points for me to consider and happy to have this dialogue. I will give everything you said more thought to try and understand. However, I don't quite understand this:

Doing it your way gets rid of the + character, but introduces a list of file names that are reserved again.

Before, every .svelte file in routes/ is a route except for files with _ as prefix.
Now, every .svelte file in routes/ is a component except for files with a + as the prefix.

Before, every file with __ was designated to be a special svelte file.
Now, this is entirely gone?

Before, every file in the routes/ folder was public.
Now, every file in the routes folder is private unless given a +.

Before, the list of file names that were reserved were index.svelte, index.js, __layout.svelte and __error.svelte
After, the list of file names that are reserved are +page.svelte, +page.js, +page.server.js, +server.js, +layout.svelte, +layout.js, +layout.sever.js, +error.svelte

So there's still a list of reserved file names. Nothing changes there. Fundamentally, nothing has changed here except the symbols.

The design just have easily could have been files in the routes/ folder are public and files in the routes folder with _ are private. Basically __layout and __error easily could have been layout.svelte and error.svelte. But the __ was used to show that it was a special SK file. Which is now just gone. (good?)

The reasons given for the + are that this avoids the mistake of making a component public. Yes, it is nice to have guardrails against someone making a mistake but this a mistake a dev is likely to make once, look up what they did wrong, then fix it and never make that error again.

And to help with grouping the routes when you do CMD + P. But this is like every file is called +page.svelte now. Sure, you have a solution to search by directory. But you're literally going to have every day someone say, "I have too many +page.svelte" files now. So all that has occurred is trading the problem of the directory level with the chaos of dealing with every file being the same name.

However, my argument is that this is ugly. (The + is an unnatural symbol in filenames) But that it adds confusion to a newcomer. You never want to tell a newcomer "RTFM". That comes later. :)

You want everything to be as intuitive as possible at the beginning. The most vulnerable stage. Something this strange is going to really turn people off. It's not like this is React where millions are forced to use it for work. Svelte is a very niche product with a small ecosystem. Sveltekit is an emerging framework with 100k downloads a week compared to Next's 3million a week. If someone see's a + in the filename. They're going to think "hmm, this is really weird". Sure, making a component public is unfortunate, but it is a mistake made MUCH later in the learning process. Not in the onboarding process. It just makes it such a harder sell. The sad truth is that people want easy, familiar and intuitive. No matter how simple it may seem to you. Go out and try to onboard someone in SK and see the reaction.

Yes, I know it seems extremely trivial. But that's the reality we live in.

[nikfp]

@ZetiMente To me the file system thing still looks and works better now. YMMV, but it just makes more sense to me in the end. And I don't mind the + character. Looking at it from your perspective, it makes sense. The way you propose it does make things easier than before and I could be happy with that. Looking at it from my perspective, it also makes sense. I can now interpret and navigate my project better. So we get to wave at each other from opposite camps and (politely) debate on the internet, at least until the maintainers can split the difference and make everybody happy 🙄. I'll agree that the + character could go away and I'd be happy about it (or at least not upset in any way), but I want to keep the functionality that came with it.

And I see your point about adoption, but also see that NextJS is the 900 lb gorilla in the room and is on v12, whereas SK is on v0.4**. I would hazard to say that SK will never be as popular as NextJS unless react itself sees a massive decline, but I am also confident that there is a lot of cross-pollination happening at Vercel and the two frameworks are looking at each other with a keen eye. It's in the best interest of both worlds to get along and learn from each other before something like Astro comes along and eats both of their lunch. Next has been looking at similar changes, but it's much harder for them to do because of their positioning and heritage. (She's a big ship, she turns slow!) SK can still be rebellious, for better or for worse.

And you pulled out a Simpsons reference, 👍

EDIT - agreed with you more 😉

[ZetiMente]

@nikfp Yeah, I can understand your perspective. I prefer the file based routing over the folder based routing because I love economy, flat directories (api/cookies/+server.ts and shop/product/[id]/+page.svelte are yuck to me), flexibility, expressive filenames and user friendliness. However, I get it does add consistency, maintainability, structures the folder levels and additional type safety. It also helps manage the additional clutter added by moving the modules into being their own files. NextJS will probably move in that direction too. (Although it seems they might make exceptions for the api/ folder)

It's about preference and it's a design trade off.

But with the +, it's weird to privilege the exception instead of the standard.

The three 3 reasons behind the + design decision.

1. Files without the prefix (like Widget.svelte) are simply ignored by the router, making colocation easy without workarounds

But isn't the design now that a svelte file needs to be "+page.svelte" / "+layout.svelte" / "+error.svelte" to function as a route now? If you make a Widget.svelte file in routes/about/ folder, its automatically private anyways because it's not an approved name.

routes/about/page.svelte -> Works
routes/about/Widget.svelte -> Doesn't Work. Not an approved name.

So the argument that it prevents someone from shooting themselves in the foot by putting a Component in a route folder isn't even valid.

But do we even need private routes at all ?

The demo has api.ts as a generic fetch. I would argue that this isn't consistent since there are two ways to do something here.
This file should go into lib/.

Therefore, either one of these options would make everything more simple.

A. Remove private routes from routes/. The 1 file of api.ts could be moved to lib/ and remove all the + from every file. As every file in routes/ is now public unless it's NOT a svelte file called page.svelte/error.svelte/layout.*.svelte.

OR

B. If people really want to keep private routes. Same rule as above but all .ts/.js files are public unless they start with _.

OR

C. Just go back to the old way of files with _ are private and files without are public. And print in the console. "Hello, we noticed that you have a svelte file that isn't page.svelte/layout/error that doesn't have a _. Not using the _ makes the file public by default. Please insert a _ in front of the file. {link to docs}"

2. If we need to add more route files in future (e.g. +loading.svelte), we can do so without it being a breaking change, because + is a reserved prefix

I don't understand this. I can see removing a reserved word would cause breaking changes. But how would adding a word break things? There's already special logic for page.svelte, layout.svelte and error.svelte anyways. If everything is public by default, isn't adding a loading.svelte file already going to work? Then the only breaking change is if someone had a component called loading.svelte. But is it really too much to ask someone to change the name of the component?

3. Route files are grouped alphabetically — in your editor, a route directory will contain child directories, route files, and ordinary files, in that order

I guess. But the child directories will already automatically be at the top already. With the _ as private, you have components and then routes. I will concede that if you created a workaround for hiding the _, you would lose this benefit. But if you kept the _ for private, you would.

Overall

Breaking with convention, the aesthetics, the readability of the + and the confusion it causes isn't worth it imo. I would rather just all my files in routes/ be public unless marked with _ for private. But it's ridiculous that I care this much about a plus sign..

At the end of the day, other people think this is more simple. And they maintain the repo.
Regardless of the wisdom of telling newcomers to RTFM.

Dr. Strangelove or: How I Learned to Stop Worrying and Love the +

[eddiemcconkie]

Then the only breaking change is if someone had a component called loading.svelte. But is it really too much to ask someone to change the name of the component?

I think it is. SvelteKit is still in beta, so breaking changes are expected at the moment, but once it's at a stable release I think we'd want to avoid breaking changes as much as possible. Even if renaming a component is a relatively simple fix I know I'd still be a bit bothered by it, and I think it's a good enough reason to keep the prefix just for the sake of future-proofing my code

[einarpersson]

I really like this major rewrite since I have previously had a very hard time understanding how things fitted together, where things ran etc. even after reading the docs again and again. Things did fell into place with this rewrite.

However
My concern regarding the + is not my own preference (I am somewhat undecided, on the fence) but rather its effects on the adoption of SK. I am simply a bit worried that people might discard it saying “this is just too strange for me” and that SK may become harder to sell internally to colleagues etc. Whether we like it or not, people do have strong preferences and I’m just wondering if the + part is worth it.

One more thing: I agree with the point raised earlier that this change favours pages but not api:s. Having an api folder with a bunch of folders with single files feels clunky. Is there a solution for this on the horizon? Otherwise it feels like it may become one reason for why someone might choose something else for a “api-heavy” project.

Also, regarding co-locating components. If that was something I would do, then I wouldn’t mind putting it in a subdirectory, I.e I could have lived with a solution like

projects/page.ts
projects/page.svelte
projects/_components/Thing.svelte
# only allow route files directly in /projects

Why would you like to intermingle route files with a bunch of components anyway? If you want collocation, why not just put them in a (hidden from router) subdirectory? Was this considered? Then simply the price to be paid for someone who wants to collocate components would be to “put them in a subdirectory”, instead of forcing everyone else to add a plus sign to all their route files. Maybe there is a simple answer why this is a bad idea, but I haven’t seen it considered.

To summarize: I like the changes overall, I am a bit worried that something that should be a small detail (+) gets too much in the way, and I see a genuine annoyance with all the folders needed for creating a fairly simple api (is there a solution?).

[coryvirok]

💯 x this:

My concern regarding the + is not my own preference (I am somewhat undecided, on the fence) but rather its effects on the adoption of SK. I am simply a bit worried that people might discard it saying “this is just too strange for me” and that SK may become harder to sell internally to colleagues etc. Whether we like it or not, people do have strong preferences and I’m just wondering if the + part is worth it.

If we had just adopted Next.js' new standard for routing, we would benefit from their entire dev audience wanting to switch to SK for the speed + simplicity.

Pushing more and more of the routing and layout logic into file and directory names is an incredibly slippery slope - Death by 1000 machete cuts.

If the answer to every question from a new SK dev is, "RTFM" that's an incredibly non-intuitive framework. And by definition, an incredibly poor DX.

[eddiemcconkie]

@nikfp I agree, while it's definitely different I think these changes are a huge improvement and fix a lot of the things I felt weird about with the old SvelteKit.
The more I see the + prefix in the filenames the more I like it. I never liked the __ prefix for layout and error pages, nor the _ prefix for non-page files. They felt like kind of an afterthought to me compared to everything else in the framework which seemed to be done very intentionally. The +, along with the move to directory-based routing, makes everything feel a lot more consistent, and it makes it easier to identify which files deal with routing and which ones don't.
A lot of people are concerned with how difficult adoption will be for beginners. Honestly, I think the + prefix is a much easier concept to grasp than the many $ symbols scattered around the rest of Svelte, so I'm not too worried about it. Personally I'm really happy with the direction SvelteKit is headed in, and I think this was a big step towards a more consistent and reliable design.

[danawoodman]

Using a special character in a directory/file name is a different beast than $ for reactivity and $$ for special attributes. $ for reactivity is easy to explain to any newbie (it's shorthand for working with a store, in a component) and $$ attributes are not super commonly used. Using + in every route file is a very uncommon and onerous imo

[einarpersson]

Just to be clear - As mentioned here my main concern is not that it is necessarily hard to grasp, but rather that it might be a reason why devs get turned off and discard SK out of pure gut feeling. And so this is not just a technical question.

(On the other hand I have to believe that this is something that Rich etc have thought about)

[plasmatech8]

I have been feeling conflicted about editor ergonomics of folder-based routing with the + signs.

What bugs me is that it is annoying/harder to visualize my files. When I use the file explorer in my editor sidebar, I need squint my eyes to find the folder, and then find the file that matches the correct indentation. In the tab menu, all the +page filenames are not optimally expressive/differentiable and is slightly difficult to sift through. Also, when only one tab is open I cannot tell which file I am looking at (depending on the "workbench.editor.labelFormat" setting). This might be partly a problem with me and VS Code, but still. That is for visualization.

When it comes to selecting a file, I know I can use the CTRL/CMD+P, but I personally rarely use it. I don't feel super fussed though, atm. Note that a newbie will prefer visual interfaces over commands.

Ideally, files would have filenames that describe what they are, like AboutPage.svelte. --- And it turns out, this is still possible by co-locating files like AboutPageContent.svelte in your route folder (or in your lib) - but there will be a lot of +page files that are mostly empty, and things may look bloated. Plus it starts to become comparable to config-based routing.

As a thought, config-based routing is not bad since it is solid, familiar, and has not too many points of differing opinion. Using a router-file makes slightly more sense in git version control. And you can have files like AboutPage.svelte stored in a folder structure of your choosing. --- Although, people may prefer a trendy system, with particular standards and zen. Also, some people find config files annoying - other config files already exist, but the SvelteKit routing system could be more complicated.

There is no perfect solution and this is a minor nitpick. I am happy with the current because it works. I trust the judgement of Mr Svelte for design decisions.

[e0]

My biggest problem with this whole change is how some of these things are being communicated and argued for. This is not directed only at you but most of the "new routes are better camp".

People don't like the + character at the beginning of files.

The directory is called routes. If you want to have something that is not a route, those should be the ones that need a prefix, not the actual route.

I can understand the argument for saying __layout is ugly. How about we add another directory called layouts alongside routes?

The argument I dislike here is talking about "Oh if you want to have a widget or whatever svelte file here that is not a route, it would be confusing.". If you care about teaching beginners good practices (like reusability and separation of concerns), maybe the message should be to keep your components outside of the routes folder.

If the + prefix and reserved names such as page and server are what is necessary to bring in the new TypeScript magic, I think that is a good tradeoff. I just think it would be a more honest and compassionate conversation to not dismiss people's negative reactions with poor arguments.

People don't like the directory based routing vs the File System based routing

Why though? Directory based routing sorts better, making it easier to find things. It's clearer what does what - a directory is a route, the files in the directory define behavior. It's still file system based routing, but it's actually simpler if you look at it.

I agree that the new way is more structured. The downside is that you can end up with a lot of directories, where each of them have a single file in it. For example with all of my /routes/api stuff.

Again, I think enforcing directories is what is needed to bring all the TS convenience and that is a tradeoff I'm in favor of. I disagree it is objectively better and I think people are being too dismissive of people who voice their pains with editors that they did not have prior to this change.