bitspittle
commented
6 months ago Hey @franz-sw ! Thanks for this interesting discussion.
BTW, if you're not aware, the kobweb block does have a cleanUrls property which defaults to true. You can set it to false (kobweb { cleanUrls.set(false) }) and then that will require people visit the page with ".html" on the end, which should be more consistent with what your server is forcing you to do.
To be upfront with you, I'm not planning on prioritizing hash-based routing. There's simply too much to do as is, and you are the first person who has asked for it. I will happily leave this comment up though so that other users may find it and chime in with their own thoughts.
One of the biggest advantages that Kobweb provides is SEO support. Creating one export per route is kind of Kobweb's secret sauce (as secret as an open source project can get I guess!). As far as I can tell, hash-based routing is not at all SEO friendly?
I appreciate it could be useful to be able to mimic clean URLs even with a web hosting service that doesn't support them, but at the moment I don't think complicating the codebase to support that use-case would be a good trade-off.
Especially, the standard definition of fragments for HTML is meant to relate to an element with some ID inside the document. Maybe I'm wrong about this, but I feel like hash-based routing is a case of using a feature in an unexpected way.
Finally, going through your advantages:
-
Simplified Server Configuration: Configuring a static hosting web server is generally straightforward.
-
Fallback for Legacy Browsers: Kotlin/JS already requires modern browsers, so I don't think that advantage applies here.
-
Instant Routing Decisions: Kobweb already provides instant routing as is.
-
Ease of Deployment: As mentioned above, you can disable the
cleanUrlsproperty on Kobweb for these restricted server cases.
I'm sure this answer is disappointing but I hope you feel at least it was respectful and informative.
franz-sw
As my SPA hosting provider doesnt sopport URL rewriting (no permission for .htaccess rewrite engine) user always get an 404 error if they navigate from outside to any page of my site ( e.g. http://example.com/page would not open http://example.com/page.html , instead it throws an 404 ) For me Hash-Based Routing (explained below) seems to also be an advantage for other users as it makes everything lighter and only an index.html is needed. As a workaround for now i am rename all my route from e.g. http://example.com/page to http://example.com/page/index.html which works, but I would appreciate it if you consider this suggestion.
Explanation of Hash-Based Routing
In hash-based routing, the URL looks something like this: http://example.com/#/page. Here, /page is the hash fragment. The key aspects of hash-based routing include:
Client-Side Handling: Everything after the # in the URL (the hash fragment) is not sent to the server. It is only accessible and handled by the browser. This means the server only sees http://example.com/, and it always serves the same HTML file, typically index.html of your SPA.
JavaScript Listens to Hash Changes: The JavaScript running on the page listens for changes to the hash fragment. When a user navigates to a different hash fragment, the JavaScript updates the page's content accordingly, without a full page reload.
Browser History: Modern browsers treat each unique hash fragment as a separate history entry, enabling the use of the browser's back and forward buttons, similar to traditional multi-page websites.
Advantages for SPA Hosting
Simplified Server Configuration: Since the server only needs to serve the main index.html file regardless of the hash fragment, there's no need for complex server-side URL rewriting. This makes hash-based routing highly compatible with a wide range of hosting environments, including basic static file servers.
Fallback for Legacy Browsers: Hash-based routing is supported by all browsers, including older ones that don't support the HTML5 History API.
Instant Routing Decisions: Since routing decisions are made client-side based on the hash, it can lead to faster perceived navigation performance.
Ease of Deployment: Deployment on servers without support for clean URLs (path-based routing) is straightforward, as you don't rely on server-side logic to handle different routes.