5 ms·

As an "outsider" who dabbles in wasm I never understood why running custom code on the server to generate "dynamic" webpages would be better then a dumb server

As an "outsider" who dabbles in wasm I never understood why running custom code on the server to generate "dynamic" webpages would be better then a dumb server which just serves files, and the dynamic part is running in the browser instead (other then that 90's web browsers sucked for this type of stuff). E.g. nothing will ever beat a dumb file server with a cdn in front when it comes to simplicity and scalability.

stavros 3y ago
Because you can't guard your competitive advantage as easily when you need to send your entire codebase to the client, and it turns out companies like that stuff.
- flohofwoe 3y ago
  What's the "competitive advantage" of a webpage though? It's usually just some code snippets copied from StackOverflow and a database ducktaped together right? ;)
  - jamil7 3y ago
    Careful, they might steal your for loops.
  - stavros 3y ago
    Yes, but that's enough for a billion valuation nowadays, so...
- BrandoElFollito 3y ago
  With modern frameworks it is not even that. What you get is a compiled, minimized page where all of the technical interesting things are lost after the build step. The only thing you can make use of is the design and the actual content.
suprjami 3y ago
I've had sites where I just write in Markdown and rsync it to a webserver. All pages were rendered dynamically. The advantage was that I set it up once then literally never care about a website again and just write in my beloved Markdown. It was great. Until the webhost took away PHP anyway.
- flohofwoe 3y ago
  GH Actions (or any othe CI service) can do the same workflow though. Commit and push markdown, GH Action starts server-side, converts the markdown to html with a static site generator of choice, and uploads to webhoster. If you use Jekyll as static site generator and GH Pages for hosting, it even works out of the box (eg no GH Action tinkering needed, just flip a switch in the GH project settings) But arguably, a local static site generator workflow works just as well (convert to html locally and upload those files to web hoster instead).
  - suprjami 3y ago
    I have since moved to GitHub Pages for my main site, but mine was even simpler than that: https://github.com/superjamie/emdee https://github.com/superjamie/emdee
crote 3y ago
Not everything can be done in a browser. You might want to store user-submitted content in a database, for example. Or you might want to do authentication. You might want to provide full-text search in a multi-gigabyte dataset. You might want to provide an interface to something which can't be accessed from a web browser. You might want to validate user-provided input. All of those require custom code running on a server. So now you have to take whatever data you have on the server, translate it into a well-defined custom transfer protocol, send it to the client, translate it back, and finally turn it into html. And the same for the other direction, but now you suddenly have to do input validation on both the client and the server to prevent anyone creating a custom client from doing anything malicious. Or you can just turn it directly into html on the server and be done with it. It's a lot less work, and provides basically the same experience for most applications.
- hinkley 3y ago
  Also users haven’t had “a browser” for a decade. Between personal and work I have four, technically five, and then some apps on my Apple TV (YouTube in particular). User accounts let me share state between them. There’s no protocol yet that lets you do that on the client, though Apple might be working that way. If you haven’t used the device integration features of OS X and iOS you are missing out. Cut and paste is very, very useful.
- flohofwoe 3y ago
  Yeah, depends on the type of app / webpage of course. E.g. a blog doesn't need any of that, but a webshop does. But there's also a middleground where most of the code runs in the browser, while only some small parts need to run on the server (like login/auth, or a "cloud drive" storage). IMHO this type of web application is currently the most interesting. PS: how complicated that is all depends on the library ecosystem IMHO.
MrJohz 3y ago
Like with anything, that might be a good strategy in some situations, but not in all. For example: * If you have some secrets that need to stay hidden (e.g. database passwords, API keys, encryption keys, etc) then that needs to be processed by code that lives on your servers. If all your code runs on the client, then there is always the chance for an attacker to discover those secrets. * It is often easier to present a smaller, limited API to the client to reduce the surface area available to attacks. For example, if you let the client connect directly to your database, you need to make sure that that database is correctly secured, that the correct permissions are there, and that nothing can go wrong. But if you just give them a list of books, or films, or whatever your app does, then it will be harder for them to break through that defence. (And if they do manage that, you should still have the database set up as securely as possible to provide an additional layer of defence.) * A site often feels more responsive if the initial load is served as one single chunk of ready-to-use data (as opposed to serving the application, showing a loading indicator, making the necessary data fetches, then showing the data). Even if they take the same time the first option often intuitively feels quicker to the user. * Leading on from that, it can often be quicker to load things up front, just because the server that's responding to the user is probably sitting next to your database and any other servers it needs to talk to. These network calls are also much more reliable in that sort of context. If you push all of the processing to the user, you're going to have to handle the slower and more unreliable calls. * The server will probably be a much more consistent platform than user browsers. Browsers are a lot better these days, but there are still lots of slight differences that you'll need to be aware of. If you have control of a server, though, you can specify the exact versions of every tool, runtime, etc that you need, and be able to update things more deterministically. Fwiw, these aren't all true all of the time, and there will be exceptions. I work primarily on frontend applications, and there's a lot of value in a well-designed application that does the majority of work, if not all, in the browser. But this is typically only true for fairly complex web apps, or projects where some amount of rendering has to happen in the browser whatever happens.
Gordonjcp 3y ago
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.
tjoff 3y ago
Dynamic pages do have some overhead, as discussed in the article. But it is still vastly superior to running the site in the browser. Because the generation is done once, and it is darn quick. After that all of the numerous advantages of a static page still applies from a users perspective. The resource use is many orders of magnitude less and the page is much more responsive. The user experience is vastly superior, we haven't cared about that in the last decade.
- trollied 3y ago
  Yup. Less DOM manipulation the better.
quectophoton 3y ago
Depends how much you want to want to avoid showing a spinner during first load _and_ when moving between pages. And how much skill you have to not mess up basic browser functionality. As a reference point, GitHub still breaks the back button for me like 40% of times when I'm navigating their source code (me using Chrome on OSX because I only need to do this on my work laptop). I don't even know how they manage to do this. In my experience, sites that generate HTML server-side tend to feel faster and more reliable than anything that depends on rendering client-side. Loading a booru with 50+ images per page with a cold cache in my browser, always feels quicker and more pleasant than loading text-only GitHub pages that should already be cached everywhere and haven't been modified for days.

stavros 3y ago

Because you can't guard your competitive advantage as easily when you need to send your entire codebase to the client, and it turns out companies like that stuff.

flohofwoe 3y ago
What's the "competitive advantage" of a webpage though? It's usually just some code snippets copied from StackOverflow and a database ducktaped together right? ;)
- jamil7 3y ago
  Careful, they might steal your for loops.
- stavros 3y ago
  Yes, but that's enough for a billion valuation nowadays, so...
BrandoElFollito 3y ago
With modern frameworks it is not even that. What you get is a compiled, minimized page where all of the technical interesting things are lost after the build step. The only thing you can make use of is the design and the actual content.

suprjami 3y ago

I've had sites where I just write in Markdown and rsync it to a webserver. All pages were rendered dynamically. The advantage was that I set it up once then literally never care about a website again and just write in my beloved Markdown. It was great. Until the webhost took away PHP anyway.

flohofwoe 3y ago
GH Actions (or any othe CI service) can do the same workflow though. Commit and push markdown, GH Action starts server-side, converts the markdown to html with a static site generator of choice, and uploads to webhoster. If you use Jekyll as static site generator and GH Pages for hosting, it even works out of the box (eg no GH Action tinkering needed, just flip a switch in the GH project settings) But arguably, a local static site generator workflow works just as well (convert to html locally and upload those files to web hoster instead).
- suprjami 3y ago
  I have since moved to GitHub Pages for my main site, but mine was even simpler than that: https://github.com/superjamie/emdee https://github.com/superjamie/emdee

crote 3y ago

Not everything can be done in a browser. You might want to store user-submitted content in a database, for example. Or you might want to do authentication. You might want to provide full-text search in a multi-gigabyte dataset. You might want to provide an interface to something which can't be accessed from a web browser. You might want to validate user-provided input. All of those require custom code running on a server. So now you have to take whatever data you have on the server, translate it into a well-defined custom transfer protocol, send it to the client, translate it back, and finally turn it into html. And the same for the other direction, but now you suddenly have to do input validation on both the client and the server to prevent anyone creating a custom client from doing anything malicious. Or you can just turn it directly into html on the server and be done with it. It's a lot less work, and provides basically the same experience for most applications.

hinkley 3y ago
Also users haven’t had “a browser” for a decade. Between personal and work I have four, technically five, and then some apps on my Apple TV (YouTube in particular). User accounts let me share state between them. There’s no protocol yet that lets you do that on the client, though Apple might be working that way. If you haven’t used the device integration features of OS X and iOS you are missing out. Cut and paste is very, very useful.
flohofwoe 3y ago
Yeah, depends on the type of app / webpage of course. E.g. a blog doesn't need any of that, but a webshop does. But there's also a middleground where most of the code runs in the browser, while only some small parts need to run on the server (like login/auth, or a "cloud drive" storage). IMHO this type of web application is currently the most interesting. PS: how complicated that is all depends on the library ecosystem IMHO.

MrJohz 3y ago

Like with anything, that might be a good strategy in some situations, but not in all. For example: * If you have some secrets that need to stay hidden (e.g. database passwords, API keys, encryption keys, etc) then that needs to be processed by code that lives on your servers. If all your code runs on the client, then there is always the chance for an attacker to discover those secrets. * It is often easier to present a smaller, limited API to the client to reduce the surface area available to attacks. For example, if you let the client connect directly to your database, you need to make sure that that database is correctly secured, that the correct permissions are there, and that nothing can go wrong. But if you just give them a list of books, or films, or whatever your app does, then it will be harder for them to break through that defence. (And if they do manage that, you should still have the database set up as securely as possible to provide an additional layer of defence.) * A site often feels more responsive if the initial load is served as one single chunk of ready-to-use data (as opposed to serving the application, showing a loading indicator, making the necessary data fetches, then showing the data). Even if they take the same time the first option often intuitively feels quicker to the user. * Leading on from that, it can often be quicker to load things up front, just because the server that's responding to the user is probably sitting next to your database and any other servers it needs to talk to. These network calls are also much more reliable in that sort of context. If you push all of the processing to the user, you're going to have to handle the slower and more unreliable calls. * The server will probably be a much more consistent platform than user browsers. Browsers are a lot better these days, but there are still lots of slight differences that you'll need to be aware of. If you have control of a server, though, you can specify the exact versions of every tool, runtime, etc that you need, and be able to update things more deterministically. Fwiw, these aren't all true all of the time, and there will be exceptions. I work primarily on frontend applications, and there's a lot of value in a well-designed application that does the majority of work, if not all, in the browser. But this is typically only true for fairly complex web apps, or projects where some amount of rendering has to happen in the browser whatever happens.

Gordonjcp 3y ago

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.

tjoff 3y ago

Dynamic pages do have some overhead, as discussed in the article. But it is still vastly superior to running the site in the browser. Because the generation is done once, and it is darn quick. After that all of the numerous advantages of a static page still applies from a users perspective. The resource use is many orders of magnitude less and the page is much more responsive. The user experience is vastly superior, we haven't cared about that in the last decade.

trollied 3y ago
Yup. Less DOM manipulation the better.

quectophoton 3y ago

Depends how much you want to want to avoid showing a spinner during first load _and_ when moving between pages. And how much skill you have to not mess up basic browser functionality. As a reference point, GitHub still breaks the back button for me like 40% of times when I'm navigating their source code (me using Chrome on OSX because I only need to do this on my work laptop). I don't even know how they manage to do this. In my experience, sites that generate HTML server-side tend to feel faster and more reliable than anything that depends on rendering client-side. Loading a booru with 50+ images per page with a cold cache in my browser, always feels quicker and more pleasant than loading text-only GitHub pages that should already be cached everywhere and haven't been modified for days.