3 ms·

>On top of that, sr.ht is one of the most lightweight websites on the internet, with the average page weighing less than 10 KiB, with no tracking and no JavaScr

>On top of that, sr.ht is one of the most lightweight websites on the internet, with the average page weighing less than 10 KiB, with no tracking and no JavaScript. You have my attention!

devwastaken 8y ago
Server side html rendering will always be less efficient, but I can see the application of using curl to request and parse pages.
- calcifer 8y ago
  You mean more efficient, right? Because the single page "applications" that download UI and data with javascript take a three-digit number of requests and multiple seconds to render everything and be "done".
  - devwastaken 8y ago
    No, because once you download the js you don't redownload it on every page request. When you want to update contents you get the new data to be displayed. This is how any other gui application does server communication. The traditional page based responses re-send all the html content over again. If the client can cache it then it doesn't have to be, but caching something like a git frontend does not work with page based responses due to the amount of new data. Just because Facebook and Google abuse js to the nth degree does not mean it's automatically bad. It's how you use it, and you can infact do things without react and Vue.
    - kungtotte 8y ago
      When most of the web looks like this: https://news.ycombinator.com/item?id=17655316 https://news.ycombinator.com/item?id=17655316 I'm happy about Drew's decision to not include JS.
      - devwastaken 8y ago
        As I just stated, you don't need to have 1MB of JS to do things, it's that software companies typically do it because they're about actually providing a service and solving problems than worrying about non-issues such as 1 second more of initial download time. This is 2018. You don't have a 56K modem, I don't have one. Those that do will benefit from smaller data requests after the initial download. Holding back the real issues the web can solve over an arbitrary problem like that is damaging to what can be achieved. The web is a software platform, and unless you want to equally complain about applications in C that go over 1MB, you're making mountains out of mole hills.

>On top of that, sr.ht is one of the most lightweight websites on the internet, with the average page weighing less than 10 KiB, with no tracking and no JavaScript. You have my attention!

devwastaken 8y ago

Server side html rendering will always be less efficient, but I can see the application of using curl to request and parse pages.

calcifer 8y ago
You mean more efficient, right? Because the single page "applications" that download UI and data with javascript take a three-digit number of requests and multiple seconds to render everything and be "done".
- devwastaken 8y ago
  No, because once you download the js you don't redownload it on every page request. When you want to update contents you get the new data to be displayed. This is how any other gui application does server communication. The traditional page based responses re-send all the html content over again. If the client can cache it then it doesn't have to be, but caching something like a git frontend does not work with page based responses due to the amount of new data. Just because Facebook and Google abuse js to the nth degree does not mean it's automatically bad. It's how you use it, and you can infact do things without react and Vue.
  - kungtotte 8y ago
    When most of the web looks like this: https://news.ycombinator.com/item?id=17655316 https://news.ycombinator.com/item?id=17655316 I'm happy about Drew's decision to not include JS.
    - devwastaken 8y ago
      As I just stated, you don't need to have 1MB of JS to do things, it's that software companies typically do it because they're about actually providing a service and solving problems than worrying about non-issues such as 1 second more of initial download time. This is 2018. You don't have a 56K modem, I don't have one. Those that do will benefit from smaller data requests after the initial download. Holding back the real issues the web can solve over an arbitrary problem like that is damaging to what can be achieved. The web is a software platform, and unless you want to equally complain about applications in C that go over 1MB, you're making mountains out of mole hills.