Bringing back the "Shadow Endpoint" Terminology #5740
Replies: 3 comments 4 replies
-
|
As I'm one of the ones whose complaining on Discord prompted the creation of this discussion, I feel like I can provide a few reasons why "shadow endpoint" is a much better term than "page endpoint." The first reason is that cramming the word "page" into a different usage in the context of routing makes it very confusing for beginners to keep track of. They have to keep track of pages, endpoints, and page endpoints (which are really just regular endpoints that correspond to specific pages). When you're learning new terminology, it can be incredibly confusing to differentiate terms when you see multiple familiar words used in combination with each other, rather than having a new term to represent a new meaning. Consider the terms "server", "client", and "request", which are all commonly used in web development. Ignoring whether it makes chronological sense or not, imagine if we decided to use the term "server requester" instead of "client". While it's not a one-to-one comparison, I think it's a good example of how reusing the same words in too many places can negatively impact clarity. The second reason that I find "shadow" better than "page" is that the term "page endpoint" can be hard to use in conversation while being clear about what you're talking about. While explaining things in the Discord server, I often find myself doing sentence gymnastics to make it clear that I'm talking about a page endpoint, not a page, and not a page and an endpoint, and not a plain endpoint. I've still had people on the other end of the conversation get confused in this way, which just makes it harder to communicate. The third reason that I have for using "shadow" over "page" is simply that shadow endpoint is a much more representative name of what the functionality actually is. The logic behind "page endpoint" is relatively weak: it's an endpoint that has its own page. Why not call the pages "endpoint pages"? On the other hand, the term "shadow" endpoint elucidates that the endpoint is the "shadow" of the page, sitting behind it to feed it information. The term "shadow" also implies that some functionality has been "hidden", which is exactly what the shadow endpoint does by hiding the load function and having the page automatically call it. This is probably the weakest of the three points because it's entirely based on the connotations that I personally assign to those words, but I think it's worth mentioning because I've talked to others who share the same feelings. |
Beta Was this translation helpful? Give feedback.
-
|
IMO they are both wrong. Say you have an endpoint ... whether it is a page / shadow endpoint or a standalone one is purely based on whether there is a matching route page. So the endpoint doesn't change, but adding or removing some other file changes what it is called? Isn't that confusing? I think it's simpler to have just "endpoints" and then talk in terms of whether a page auto-loads them or not. |
Beta Was this translation helpful? Give feedback.
-
|
to give some counter examples, consider the terms HTTP, server and HTTP server. I don't think many users are confused by the term HTTP server even though HTTP is protocol and server can refer to any kind of server. if anything, when you hear HTTP server you can immediately guess what kind of server it is. what if we called it shadow server instead? that would be very confusing IMHO. the same could be said for shadow endpoints vs. page endpoints. with the latter, I think most users would think that a page endpoint is an endpoint that has some association with a page. with the former, who knows! there are many more examples of phenomenon but the basic point I'm trying to make here is that I think it makes more sense to name something A + B if it is a certain type of B that is associated with A - rather than C + B where C is a new term altogether. just some food for thought 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I can definitely see how taking the approach of "all endpoints are the same, the pages are different" could be useful, I would prefer that over "page endpoint". As far as other examples of combining terms to make new terms, I think there's a fundamental difference between how adjective-y the term "HTTP" is as compared to the word "page". I'm no linguistic expert, but I feel that the word "page" is such a general noun that it's very easy to interpret it as being a noun rather than a modifier on the word "endpoint". HTTP is a much more specific term and it's easier to pin down where it's being used as an adjective/modifier versus as the noun. But perhaps I'm overthinking and relying too much on my own preconceptions and connotations... |
Beta Was this translation helpful? Give feedback.
-
|
Thought experiment: if a page endpoint is requested with an accept header, to get the JSON instead of the HTML, does it "suddenly" become a standalone endpoint? So the same endpoint is both a page endpoint and a standalone endpoint, depending on the request that is made at runtime? Re: server vs http server - the latter is a more specific type of the former. Both are servers, one just clarifies the type by defining the protocol. |
Beta Was this translation helpful? Give feedback.
-
|
as someone who recently started learning Svelte (and SvelteKit) - I thought Page Endpoints made a lot of sense! it sounded very reasonable to me that you had Endpoints as an overarching concept. Endpoints is then further divided into:
for me, the name Shadow Endpoint doesn't make as much sense and it is not clear to me that Shadow refers to the fact that a certain Endpoint is associated with a Page. again - I'm new to SvelteKit but maybe it could be good to factor in views from newer users as well 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
It's all moot now anyway ... |
Beta Was this translation helpful? Give feedback.
-
For a brief moment, SvelteKit had referred to what is now known as "Page Endpoints" as "Shadow Endpoints".
#3532 introduced the terminology, but (if I remember correctly) it seemed that the naming caused quite a bit of confusion and thus the term never made it into the official docs and that's how the story ended.
Except not quite. It turns out that Rich had accidentally created a name that was too cool to be deleted from the internet as many of the more active members of the community started using the deprecated term of shadow endpoints to refer to the concept, with some even preferring it over the new term of page endpoints.
As it could be detrimental to SvelteKit to have "insider" terminology for core concepts, and because the name "shadow endpoints" has garnered many fans in the community, maybe having a poll about this could help decide if it's worth bringing the name back.
39 votes ·
Beta Was this translation helpful? Give feedback.
All reactions