5 ms·

> Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, Assumes facts not in evidence. People are already building JavaSc

> Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.

ramesh31 5y ago
>People are already building JavaScript monstrosities to serve entirely static blog content. I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users. I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. Couldn't even grasp the concept. I think for better or worse this is where we are headed.
- wwweston 5y ago
  Since forcing the industry to realize the possibility of server-side rendering at gunpoint is oppressive and impractical I suppose that there is some sense in which we need "accept that's how websites are built now," but there's certainly no problem with speaking about the benefits of server-side rendering and drawbacks of JS-ification. > 2-3mb of JS download (that will be cached aggressively) It's a giant problem on mobile. Connection quality varies and the larger the payload the greater the probability that it just doesn't all load. Caching? Mobile Safari will just reload the entire damn page periodically if you swap apps -- I don't think it caches in the same way that desktop browsers do.
  - thestepafter 5y ago
    A couple versions ago mobile browsers started clearing cache when you leave the application to help save battery life if I remember correctly. Very annoying because now I am unable to open a bunch of tabs in Safari for HN threads before I go off grid.
    - buchanaf 5y ago
      This sounds made up.
      - wwweston 5y ago
        Whether the reason is true, the behavior seems more or less consistent with my experience. Mobile Safari caching seems forgetful on surprisingly short horizons (especially when low power mode is on). Mobile Firefox seems better but sucks down battery life on the order that Google / Apple Maps in active navigation do. If you have a reason to believe the reality is different, though, happy to hear about more details beyond "this sounds made up."
- orange8 5y ago
  Look at the bright side... more $$$ for your efforts.
- giantrobot 5y ago
  > I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. I don't think we should simply accept that's how things are done now. > I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. A web developer like the one you mention that can't even conceive of server side rendering makes them a bad web developer. That lack of core understanding means they have no idea how a web browser works and only view the world through JavaScript. They have no concept of progressive enhancement. So this means they'll likely spend the next five years poorly implementing features a web browser already has. They're going to make websites, er "apps", that won't work properly in micro browsers. Hyperlinks won't work or will be flakey enough to might as well not work. And best of all their stuff won't work on entry level devices that are extremely popular. > But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users. You say this but it's not the common case. A lot of people have shitty devices because they're cheap. Whether they're entry level phones or shitty bullpen office systems people everywhere are stuck with them. No matter how fast Chrome might execute some JITed inner loop is immaterial when the next line adds the DOM's billionth div pretending to be a button. Thanks to cargo culting CI/CD there's little guarantee some app is going to reference the same JavaScript file on different days so the cached version will be tossed and yet another copy of Doom will be downloaded. There are plenty of uses for JacaScript and cool web technologies. There's also lots of places where JavaScript is indispensable and enables awesome things. But requiring 3MB of JavaScript to read a static blog post is just poor craftsmanship. It's not even interesting as a project because you've signed the reader up to execute some unsolicited code to do who knows what. If you love JavaScript, render all your markdown with it on your device and just send me the static output. Don't make me download Doom and the markdown just to turn it into a few paragraphs of text I can't actually read. Web developers should respect their audience enough not to make them spend unnecessary resources to use their stuff.
- franga2000 5y ago
  These sites aren't fast though... As soon as your computer isn't the newest or your internet connection isn't the fastest, or you simply have other things happening in the background, these JS-heavy sites slow down to a crawl where more reasonable things would render instantly. They also make it easier to hide nefarious code and often break accessibility and customizability the user agent is supposed to provide.
- Dangeranger 5y ago
  I would like to see web apps move in the direction of server-side rendered static pages on initial load, and then progressively hydrate the app with data from the back-end on demand. Rails does this surprisingly well using Stimulus with web sockets to mediate the exchange of events and data between the client and server layers. Similar strategies are used in Phoenix Live View apps. Load static markup and data -> request more data if you need -> send events and data to the server -> respond with the new state to display if different than the client’s version.
  - evilduck 5y ago
    At the risk of sounding rude, what you're describing has been the status quo for data-heavy SPA scenarios for a couple years. NextJS, NuxtJS, Angular Universal, Gatsby, they all allow you to preload data into a server side render and then let the client side JS take over on demand.
    - cutler 5y ago
      Have you actually had a look at Rails 7 with Turbo? It's nothing like what you're describing with NextJS etc. in that it aims to keep Javascript to an absolute minimum.
      - evilduck 5y ago
        Yes, they’re sending HTML chunks over the wire. It’s the same end result though, except you’re still not exempted from learning JS.
        cutler 5y ago
        It puts rendering back on the server where it belongs. The JS is minimal.
        evilduck 5y ago
        I’ve seen garbage and exemplary sites produced with both methods. Rendering HTML with data hydrated server side and assembling it with a library client side vs rendering JSON and generating the HTML client side is a weird religious stance to take.
MuffinFlavored 5y ago
> monstrosities why do you have to sprinkle that snark + negativity in there? it implies a toxic role of "you are superior" and "people who use JavaScript to serve static blog content" are inferior. why can't we all just get along? especially in this tight-knit programming community that is supposed to be full of love and collaboration. in today's modern day of inclusion and emphasis on mental health, you're spreading hate towards people who use JavaScript to serve static blog content and talking down to them. not every 2022 of you, in my opinion. let's work to get rid of the culture where you imply somebody else's code project doesn't meet your standards, and that since they wrote it, they are dumber than you for making poor design decisions in your opinion.
- rglover 5y ago
  > especially in this tight-knit programming community that is supposed to be full of love and collaboration You must be new here.
- irrational 5y ago
  > full of love and collaboration Why do you have to sprinkle that positivity in there? It implies a toxic role of “I am naive”. Ah, I’m just jerking your chain. For the most part I agree with you. Calling the way other people do things a “monstrosity” really is uncalled for.
  - dustymcp 5y ago
    Having to support these "monstrosities" i cant see it as toxic but merely a way of life..
- FpUser 5y ago
  >"tight-knit programming community that is supposed to be full of love and collaboration." Now you owe me a coffee and a monitor.
- epolanski 5y ago
  While I don't like as well the tone of previous poster, I think that any field should have a healthy dose of "elitism" and "competition" and the previous user is right.
Dangeranger 5y ago
Perhaps, but if your goal is to turn a pile of markdown/aciidoc/rst files into a blog, there are better and more purpose built tools for that. i.e. Jekyll, Hugo, Gatsby, 11ty.

ramesh31 5y ago

>People are already building JavaScript monstrosities to serve entirely static blog content. I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users. I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. Couldn't even grasp the concept. I think for better or worse this is where we are headed.

wwweston 5y ago
Since forcing the industry to realize the possibility of server-side rendering at gunpoint is oppressive and impractical I suppose that there is some sense in which we need "accept that's how websites are built now," but there's certainly no problem with speaking about the benefits of server-side rendering and drawbacks of JS-ification. > 2-3mb of JS download (that will be cached aggressively) It's a giant problem on mobile. Connection quality varies and the larger the payload the greater the probability that it just doesn't all load. Caching? Mobile Safari will just reload the entire damn page periodically if you swap apps -- I don't think it caches in the same way that desktop browsers do.
- thestepafter 5y ago
  A couple versions ago mobile browsers started clearing cache when you leave the application to help save battery life if I remember correctly. Very annoying because now I am unable to open a bunch of tabs in Safari for HN threads before I go off grid.
  - buchanaf 5y ago
    This sounds made up.
    - wwweston 5y ago
      Whether the reason is true, the behavior seems more or less consistent with my experience. Mobile Safari caching seems forgetful on surprisingly short horizons (especially when low power mode is on). Mobile Firefox seems better but sucks down battery life on the order that Google / Apple Maps in active navigation do. If you have a reason to believe the reality is different, though, happy to hear about more details beyond "this sounds made up."
orange8 5y ago
Look at the bright side... more $$$ for your efforts.
giantrobot 5y ago
> I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. I don't think we should simply accept that's how things are done now. > I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. A web developer like the one you mention that can't even conceive of server side rendering makes them a bad web developer. That lack of core understanding means they have no idea how a web browser works and only view the world through JavaScript. They have no concept of progressive enhancement. So this means they'll likely spend the next five years poorly implementing features a web browser already has. They're going to make websites, er "apps", that won't work properly in micro browsers. Hyperlinks won't work or will be flakey enough to might as well not work. And best of all their stuff won't work on entry level devices that are extremely popular. > But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users. You say this but it's not the common case. A lot of people have shitty devices because they're cheap. Whether they're entry level phones or shitty bullpen office systems people everywhere are stuck with them. No matter how fast Chrome might execute some JITed inner loop is immaterial when the next line adds the DOM's billionth div pretending to be a button. Thanks to cargo culting CI/CD there's little guarantee some app is going to reference the same JavaScript file on different days so the cached version will be tossed and yet another copy of Doom will be downloaded. There are plenty of uses for JacaScript and cool web technologies. There's also lots of places where JavaScript is indispensable and enables awesome things. But requiring 3MB of JavaScript to read a static blog post is just poor craftsmanship. It's not even interesting as a project because you've signed the reader up to execute some unsolicited code to do who knows what. If you love JavaScript, render all your markdown with it on your device and just send me the static output. Don't make me download Doom and the markdown just to turn it into a few paragraphs of text I can't actually read. Web developers should respect their audience enough not to make them spend unnecessary resources to use their stuff.
franga2000 5y ago
These sites aren't fast though... As soon as your computer isn't the newest or your internet connection isn't the fastest, or you simply have other things happening in the background, these JS-heavy sites slow down to a crawl where more reasonable things would render instantly. They also make it easier to hide nefarious code and often break accessibility and customizability the user agent is supposed to provide.
Dangeranger 5y ago
I would like to see web apps move in the direction of server-side rendered static pages on initial load, and then progressively hydrate the app with data from the back-end on demand. Rails does this surprisingly well using Stimulus with web sockets to mediate the exchange of events and data between the client and server layers. Similar strategies are used in Phoenix Live View apps. Load static markup and data -> request more data if you need -> send events and data to the server -> respond with the new state to display if different than the client’s version.
- evilduck 5y ago
  At the risk of sounding rude, what you're describing has been the status quo for data-heavy SPA scenarios for a couple years. NextJS, NuxtJS, Angular Universal, Gatsby, they all allow you to preload data into a server side render and then let the client side JS take over on demand.
  - cutler 5y ago
    Have you actually had a look at Rails 7 with Turbo? It's nothing like what you're describing with NextJS etc. in that it aims to keep Javascript to an absolute minimum.
    - evilduck 5y ago
      Yes, they’re sending HTML chunks over the wire. It’s the same end result though, except you’re still not exempted from learning JS.
      - cutler 5y ago
        It puts rendering back on the server where it belongs. The JS is minimal.
        evilduck 5y ago
        I’ve seen garbage and exemplary sites produced with both methods. Rendering HTML with data hydrated server side and assembling it with a library client side vs rendering JSON and generating the HTML client side is a weird religious stance to take.

MuffinFlavored 5y ago

> monstrosities why do you have to sprinkle that snark + negativity in there? it implies a toxic role of "you are superior" and "people who use JavaScript to serve static blog content" are inferior. why can't we all just get along? especially in this tight-knit programming community that is supposed to be full of love and collaboration. in today's modern day of inclusion and emphasis on mental health, you're spreading hate towards people who use JavaScript to serve static blog content and talking down to them. not every 2022 of you, in my opinion. let's work to get rid of the culture where you imply somebody else's code project doesn't meet your standards, and that since they wrote it, they are dumber than you for making poor design decisions in your opinion.

rglover 5y ago
> especially in this tight-knit programming community that is supposed to be full of love and collaboration You must be new here.
irrational 5y ago
> full of love and collaboration Why do you have to sprinkle that positivity in there? It implies a toxic role of “I am naive”. Ah, I’m just jerking your chain. For the most part I agree with you. Calling the way other people do things a “monstrosity” really is uncalled for.
- dustymcp 5y ago
  Having to support these "monstrosities" i cant see it as toxic but merely a way of life..
FpUser 5y ago
>"tight-knit programming community that is supposed to be full of love and collaboration." Now you owe me a coffee and a monitor.
epolanski 5y ago
While I don't like as well the tone of previous poster, I think that any field should have a healthy dose of "elitism" and "competition" and the previous user is right.

Dangeranger 5y ago

Perhaps, but if your goal is to turn a pile of markdown/aciidoc/rst files into a blog, there are better and more purpose built tools for that. i.e. Jekyll, Hugo, Gatsby, 11ty.