|
|
|
|
|
by FireInsight
978 days ago
|
|
I find that most these sorts of projects are for people just toying around or who have an irrational hatred of the JS ecosystem... Ultimately they lock devs into a tight, less supported ecosystem, and they might end up writing some parts in the languages native to the web anyways. And I mean, the page doesn't even load for me on my browser, just stuck at 0%. What kind of documentation page even needs a progressbar, just use a static page, right? Edit: for what it's worth, I gave this a second chance with raw Chromium. Loaded up to 400%, heh, but tbf the page does have product examples for seemingly useful products. |
|
These projects make a lot of sense, I think. You only write one system, not a separate frontend and backend, and let the middleware sort everything out.
The code rendering the plain HTML is the same code that re-renders the entire page when you switch to another page, without necessarily re-fetching data from the backend.
This is terrible for websites (ironically, like this website, which documents the framework), but great for web applications. Most native browser navigation is pretty jarring unless you add a bunch of javascript to hide navigation taking place, but if that frontend expands, you're pretty quickly building two systems (a frontend and a backend) to solve one problem.