4 ms·

So taking a fairly simple forum that I run as an example, on every page load you'd pull down 100MB or so of database, and then query that down to just the one c

So taking a fairly simple forum that I run as an example, on every page load you'd pull down 100MB or so of database, and then query that down to just the one chunk of a few hundred bytes to display a post, in the browser? Why is that supposed to be better?

whstl 3y ago
You naturally don’t do this, you can have multiple HTML pages, like a static blog. Or like a lot of forums did in the 90s/early 2000s.
- Gordonjcp 3y ago
  Forums didn't have multiple HTML pages in the early 90s, they stuck everything into a database like they do now, and pulled it out with PHP3, or even Perl (the one I wrote was PHP-FI, then converted to PHP3, and is now entirely lost).
  - whstl 3y ago
    Nope. You're wrong. A lot of them did use static pages back then. Especially the ones predating PHP. Also a couple of the most popular open source Perl ones. I remember Matt's wwwboard working like this, for example. Some of them didn't. But A LOT certain did.
shortcake27 3y ago
You wouldn’t pull a 100mb database to query in the browser; that’s not how static sites work. Instead, you’d rebuild the relevant pages whenever the content in the DB changes. Now, for a forum, I’m not sure this is a good idea, unless you have a super fast optimised build process. Even then, the delay in build is not what people expect from a forum. But the OP is not suggesting pulling a 100mb db down into the browser.
- Gordonjcp 3y ago
  But OP mentioned doing all the "dynamic" stuff in the browser. I know how static sites work, I run dozens of them for people. I don't see how using WASM improves the situation any.
  - whstl 3y ago
    "Doing dynamic stuff in the browser" doesn't imply doing every single thing in the browser. One can perfectly store data as JSON or even Markdown itself on separate files but do the templating in the frontend, for example. Pretty easy and doesn't require downloading 100mb of data.

whstl 3y ago

You naturally don’t do this, you can have multiple HTML pages, like a static blog. Or like a lot of forums did in the 90s/early 2000s.

Gordonjcp 3y ago
Forums didn't have multiple HTML pages in the early 90s, they stuck everything into a database like they do now, and pulled it out with PHP3, or even Perl (the one I wrote was PHP-FI, then converted to PHP3, and is now entirely lost).
- whstl 3y ago
  Nope. You're wrong. A lot of them did use static pages back then. Especially the ones predating PHP. Also a couple of the most popular open source Perl ones. I remember Matt's wwwboard working like this, for example. Some of them didn't. But A LOT certain did.

shortcake27 3y ago

You wouldn’t pull a 100mb database to query in the browser; that’s not how static sites work. Instead, you’d rebuild the relevant pages whenever the content in the DB changes. Now, for a forum, I’m not sure this is a good idea, unless you have a super fast optimised build process. Even then, the delay in build is not what people expect from a forum. But the OP is not suggesting pulling a 100mb db down into the browser.

Gordonjcp 3y ago
But OP mentioned doing all the "dynamic" stuff in the browser. I know how static sites work, I run dozens of them for people. I don't see how using WASM improves the situation any.
- whstl 3y ago
  "Doing dynamic stuff in the browser" doesn't imply doing every single thing in the browser. One can perfectly store data as JSON or even Markdown itself on separate files but do the templating in the frontend, for example. Pretty easy and doesn't require downloading 100mb of data.