4 ms·

>There has be some reason why people don’t write their personal websites in pure HTML. Well, it’s simple: >>HTML is unpleasant to write. >This is the only rea

>There has be some reason why people don’t write their personal websites in pure HTML. Well, it’s simple: >>HTML is unpleasant to write. >This is the only real reason. This seems like a huge overstatement. His point about each page being a snapshot in time strikes me as a bug, not a feature, but to each his own. My biggest qualm besides this is that working without a template will make nontrivial isomorphic rendering and rehydration way more developer-time intensive, and I think we should be embracing this strategy for any behavior that can be implemented both with and without page reloads -- even if you don't like shwanky JavaScripts, subsequent page loads will be faster if you just have to update the necessary changes rather than the whole page. Finally, raw HTML isn't the cleanest format to write in. I don't want to be tied to a WYSIWYG, I'd rather be able to access my editor from anything with an ssh connection, and I don't want every text file I deal with to start with a bunch of repetitious boilerplate (headers and such). I'd rather write in a cleaner format for data and let the computer deal with fitting it into the template. I don't think that HTML being unpleasant is a good reason not to write in it. If you're writing in something that compiles to HTML you should probably understand the model directly underneath you.

dmitriid 7y ago
> working without a template will make nontrivial isomorphic rendering and rehydration way more developer-time intensive What are you talking about? This is static HTML and static CSS. There’s no isomorphic rendering ir rehydration. It already is “rehydrated”. And it will take significantly less time to download than for dozens of kilobytes of JS to do the same thing.
- blotter_paper 7y ago
  The beauty is that you can have it request the JavaScript after the HTML, so those kilos of JS don't slow down first render and by the time a user clicks something you're probably rehydrated and ready to request subsequent pages without a full refresh. On the offchance you aren't rehydrated by the time of a click you just fall back to the normal behavior of an anchor link. All the delivery/render speed of static HTML with the subsequent page load times of an SPA. I could see not liking this approach if you're trying to minimize bits downloaded, but if you're concerned about user experience I would idealise using this pattern on all internal links (pretty much -- there are weird exceptions like embedded content that refuses to run after initial render for security reasons). This approach is more complicated, but also more performant due to less overall DOM manipulation. Step 1: client requests page. Step 2: static HTML is delivered. Step 3: static HTML begins rendering on client. Step 4: client requests JavaScript attached to bottom of HTML document. Step 5: JavaScript is delivered. Step 6: JavaScript begins execution. Step 7: JavaScript goes through the document replacing normal anchor links with elements that have click events which request only the content, and not the template, for subsequent pages[0]. Step 8: user clicks a "link." Step 9: client requests content. Step 10: content gets delivered. Step 11: client updates part of the page and the URL bar, but doesn't cause a whole page refresh. [0]Exception: you can give yourself hooks for a template change if you want, and even a significantly different layout on the same site will often have some common factors like footers and background.
  - icebraining 7y ago
    Why is this a better approach in terms of UX?
    - blotter_paper 7y ago
      Users don't like waiting for pages to load. Rendering fewer new DOM elements takes less time. Thus, user experience is improved by not doing a full page refresh when it isn't necessary.
  - dmitriid 7y ago
    One question: why? Or, rather, what for?
    - blotter_paper 7y ago
      Improving subsequent page load speed without sacrificing initial page load speed is an obvious win for user experience. Users don't like waiting.
      - dmitriid 7y ago
        How do you not sacrifice initial load speed if on initial load you need to load extra Javascript? How is subsequent speed increased? In case of static pages everything but content is already cached.
        blotter_paper 7y ago
        >How do you not sacrifice initial load speed if on initial load you need to load extra Javascript? Add the "defer" attribute to the script tag. This will cause the script to be ran after initial page load, and nothing will be waiting on it. This (along with NoScript, browsers that don't fully implement JS, etc.) is the reason for including anchor link fallbacks in the initial HTML payload. If the user clicks a link before the script is ran, the site behaves acceptably. >How is subsequent speed increased? In case of static pages everything but content is already cached. Let's say a user is browsing a blog they've never been to before, going between posts. There's a blogroll on the side of the layout that doesn't change between posts. Every time the browser requests a new static page it has to request this blogroll (as well as everything else) and render it all over again. Any images, scripts, and stylesheets used between pages will be cached, but the browser won't know which bit of text was for the blogroll versus the content; there's no real distinction in the DOM. Even for the elements that are cached, they'll be rendered all over again. The request time is practically nothing (just a cache check), but it's more time consuming to have the DOM render a cached image than it is to do nothing to an image that is already rendered and sitting in front of the user. Changing less is is less expensive than changing more, in terms of render time.
meerita 7y ago
Indeed. Some people never tried emmet on sublime or other syntax accelerators. You can write really fast HTMl without problem.
- cylinder714 7y ago
  It was flamed pretty badly when first introduced to HN, but I still think Steve Howell's Shpaml (http://shpaml.com/ http://shpaml.com/) completely removes the pain of writing angle brackets and keeping track of closing tags. Plus, it makes writing arbitrary XML really easy, just the thing for writing DocBook, I'll bet. And no need for a specific editor, just use your favorite. I'm definitely going to look at Emmet, though. Thanks to all for mentioning it!

dmitriid 7y ago

> working without a template will make nontrivial isomorphic rendering and rehydration way more developer-time intensive What are you talking about? This is static HTML and static CSS. There’s no isomorphic rendering ir rehydration. It already is “rehydrated”. And it will take significantly less time to download than for dozens of kilobytes of JS to do the same thing.

blotter_paper 7y ago
The beauty is that you can have it request the JavaScript after the HTML, so those kilos of JS don't slow down first render and by the time a user clicks something you're probably rehydrated and ready to request subsequent pages without a full refresh. On the offchance you aren't rehydrated by the time of a click you just fall back to the normal behavior of an anchor link. All the delivery/render speed of static HTML with the subsequent page load times of an SPA. I could see not liking this approach if you're trying to minimize bits downloaded, but if you're concerned about user experience I would idealise using this pattern on all internal links (pretty much -- there are weird exceptions like embedded content that refuses to run after initial render for security reasons). This approach is more complicated, but also more performant due to less overall DOM manipulation. Step 1: client requests page. Step 2: static HTML is delivered. Step 3: static HTML begins rendering on client. Step 4: client requests JavaScript attached to bottom of HTML document. Step 5: JavaScript is delivered. Step 6: JavaScript begins execution. Step 7: JavaScript goes through the document replacing normal anchor links with elements that have click events which request only the content, and not the template, for subsequent pages[0]. Step 8: user clicks a "link." Step 9: client requests content. Step 10: content gets delivered. Step 11: client updates part of the page and the URL bar, but doesn't cause a whole page refresh. [0]Exception: you can give yourself hooks for a template change if you want, and even a significantly different layout on the same site will often have some common factors like footers and background.
- icebraining 7y ago
  Why is this a better approach in terms of UX?
  - blotter_paper 7y ago
    Users don't like waiting for pages to load. Rendering fewer new DOM elements takes less time. Thus, user experience is improved by not doing a full page refresh when it isn't necessary.
- dmitriid 7y ago
  One question: why? Or, rather, what for?
  - blotter_paper 7y ago
    Improving subsequent page load speed without sacrificing initial page load speed is an obvious win for user experience. Users don't like waiting.
    - dmitriid 7y ago
      How do you not sacrifice initial load speed if on initial load you need to load extra Javascript? How is subsequent speed increased? In case of static pages everything but content is already cached.
      - blotter_paper 7y ago
        >How do you not sacrifice initial load speed if on initial load you need to load extra Javascript? Add the "defer" attribute to the script tag. This will cause the script to be ran after initial page load, and nothing will be waiting on it. This (along with NoScript, browsers that don't fully implement JS, etc.) is the reason for including anchor link fallbacks in the initial HTML payload. If the user clicks a link before the script is ran, the site behaves acceptably. >How is subsequent speed increased? In case of static pages everything but content is already cached. Let's say a user is browsing a blog they've never been to before, going between posts. There's a blogroll on the side of the layout that doesn't change between posts. Every time the browser requests a new static page it has to request this blogroll (as well as everything else) and render it all over again. Any images, scripts, and stylesheets used between pages will be cached, but the browser won't know which bit of text was for the blogroll versus the content; there's no real distinction in the DOM. Even for the elements that are cached, they'll be rendered all over again. The request time is practically nothing (just a cache check), but it's more time consuming to have the DOM render a cached image than it is to do nothing to an image that is already rendered and sitting in front of the user. Changing less is is less expensive than changing more, in terms of render time.

meerita 7y ago

Indeed. Some people never tried emmet on sublime or other syntax accelerators. You can write really fast HTMl without problem.

cylinder714 7y ago
It was flamed pretty badly when first introduced to HN, but I still think Steve Howell's Shpaml (http://shpaml.com/ http://shpaml.com/) completely removes the pain of writing angle brackets and keeping track of closing tags. Plus, it makes writing arbitrary XML really easy, just the thing for writing DocBook, I'll bet. And no need for a specific editor, just use your favorite. I'm definitely going to look at Emmet, though. Thanks to all for mentioning it!