Repository navigation
Refactor Code and Docs "Server" Verbiage #720
Description
Current Situation
There are a lot of locations in the source & docs where we currently call things "server", when they really should be called "web frameworks"
Proposed Actions
Rename functions, comments, and docs while keeping these guidelines in mind
- Web Framework = FastAPI, Flask, Sanic, Tornado, Django
- Web Server = Gunicorn, Uvicorn, Hypercorn, Daphne, Built-in development servers, etc
- Reactive Component Framework = IDOM
- It's an easier way to distinguish us rather than the more literal "we are a web framework built on-top of web frameworks"
- Views = Built-ins that assist in plopping something visual onto the page
- Components = We are already pretty good about the usage of "component", no need for change
Activity
rmorshea commentedon Mar 28, 2022
I basically agree and was thinking about this in my last PR. Only difference is that maybe we could use "Web Application" instead of "Web Framework". Framework is a bit generic - in principle one can have frameworks for building both apps and servers. With that I'd probably rename
idom.servertoidom.appArchmonger commentedon Mar 28, 2022
"web application" is rough. Although it makes sense, that namespace is currently getting used up by Progressive Web Applications, so it ends up feeling incorrectly labeled.
Archmonger commentedon Mar 28, 2022
I haven't given much thought on what we could rename idom.server to.
Maybe
idom.compat?I'm currently on vacation, I'll give more thought to this next week.
Archmonger commentedon Apr 4, 2022
I'll likely update this list if I think of more. But this is what I have for now:
idom.compatidom.compatbilityidom.frameworkidom.supportidom.backendidom.confidom.apprmorshea commentedon Apr 4, 2022
I'm thinking
idom.appmight be fine. Whenever you construct something likeflask.Flaskorsanic.Sanicall the examples assign to anappvariable.rmorshea commentedon Apr 4, 2022
We should be able to use the same language as these app frameworks do in their documentation.
Archmonger commentedon Apr 4, 2022
In that context, app is referring to the WSGI/ASGI application. But in our case, the end user isn't really directly interfacing with the WSGI/ASGI app through IDOM.
At the same time, I'm personally not a big fan of any of the options I posted.
I'd think of it from a few steps back. What is it that the module currently trying to do, and what might it do in the future? From my perspective:
This module really sounds like a compatibility layer to me.
rmorshea commentedon Apr 4, 2022
Besides
idom.appI'd sayidom.compatwould be my next pick.rmorshea commentedon Apr 4, 2022
Actually, didn't see
idom.backend- that one's pretty good.Archmonger commentedon Apr 4, 2022
Agreed. Semantically,
idom.backenddoes make a lot of sense. I'll sit on this one for a bit and see if I think of any other options.