3 ms·

I found the site's architecture quite interesting: It uses inline JS to transform the Markdown in HTML. view-source:https://jott.live/markdown/elementary_blockc

I found the site's architecture quite interesting: It uses inline JS to transform the Markdown in HTML. view-source:https://jott.live/markdown/elementary_blockchain https://jott.live/markdown/elementary_blockchain Ideally it would be as a Service Worker that pulls pages and transforms them into HTML, so you could serve your Markdown directly, without a separate build step.

foreigner 6y ago
For me there was a noticeable FOUC.
- crummy 6y ago
  FOUC = "Flash of unstyled content" https://en.wikipedia.org/wiki/Flash_of_unstyled_content https://en.wikipedia.org/wiki/Flash_of_unstyled_content
- deleted 6y ago
  [deleted]
- brrrrrm 6y ago
  I've never heard of this before. Speaking for myself, I don't mind it, but I'm curious if it tends to irk most people?
hombre_fatal 6y ago
Honestly it just seems like a beginner's weekend idea rather than something useful. If I squint, I can almost pretend I'm insulted that my browser/Javascript had to render the Markdown instead of their server doing it. I can't see how their infrastructure is making any real savings by doing this. There are usually more reasons to just cache the HTML next to the input Markdown. e.g. You can then make money breaking changes to the transformation without breaking old posts. Not to mention it now kinda pointlessly needs Javascript to do something trivial. Unlike what seems to be the prevailing opinion on HN, I'm quite pro-Javascript and pro-SPA. I never saw the need to damn webpages to server-rendered HTML just because it's the only client/server system with the quirk of being able to send markup from the server. But this sending Markdown over the wire with a 24kB Markdown script + `<script>$('post').markdown()</script>` is just cheeky. ;) Does it really matter though? Nah.
brrrrrm 6y ago
I'm not a web developer by profession, so I tried to keep things simple. It's just one Python process and one sqlite DB on a single cheap server. I like to think it's fair to ask the user to donate some compute for rendering as a tradeoff for maintenance costs.

foreigner 6y ago

For me there was a noticeable FOUC.

crummy 6y ago
FOUC = "Flash of unstyled content" https://en.wikipedia.org/wiki/Flash_of_unstyled_content https://en.wikipedia.org/wiki/Flash_of_unstyled_content
deleted 6y ago
[deleted]
brrrrrm 6y ago
I've never heard of this before. Speaking for myself, I don't mind it, but I'm curious if it tends to irk most people?

hombre_fatal 6y ago

Honestly it just seems like a beginner's weekend idea rather than something useful. If I squint, I can almost pretend I'm insulted that my browser/Javascript had to render the Markdown instead of their server doing it. I can't see how their infrastructure is making any real savings by doing this. There are usually more reasons to just cache the HTML next to the input Markdown. e.g. You can then make money breaking changes to the transformation without breaking old posts. Not to mention it now kinda pointlessly needs Javascript to do something trivial. Unlike what seems to be the prevailing opinion on HN, I'm quite pro-Javascript and pro-SPA. I never saw the need to damn webpages to server-rendered HTML just because it's the only client/server system with the quirk of being able to send markup from the server. But this sending Markdown over the wire with a 24kB Markdown script + `<script>$('post').markdown()</script>` is just cheeky. ;) Does it really matter though? Nah.

brrrrrm 6y ago

I'm not a web developer by profession, so I tried to keep things simple. It's just one Python process and one sqlite DB on a single cheap server. I like to think it's fair to ask the user to donate some compute for rendering as a tradeoff for maintenance costs.