Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I wrote JavaScript to avoid JavaScript

markentier.tech

Post reply on HN
Print view View original

31–40 of 61 posts

Re: I wrote JavaScript to avoid JavaScript

#31

Post by dgb23 »

zelphirkalt wrote: post #20

Someone must have gotten the a hold of the credentials of the device, where I put my brain dumps and made it into a blog post. I wish more people did approach web development in this kind of minimalist most accessible and responsive way, that does not require me to trust all their scripts and simply lets me access a hypertext document to get the information I seek.

The OP mentions things like Nextjs, which I find odd. A well crafted site built with the help of Nextjs (and similar) works w/o JS just fine: The site becomes progressively enhanced through hydration, but if you disable JS altogether, you can still read and navigate the site.

For sites with minimalist designs, straight forward data models and low to no interaction (like a blog or similar) I agree that any sort of JS can be overkill. But professional web devs use these technologies because they tick some important boxes (trade-offs) ranging from expressivity, structure to performance and provide a uniform way to write front-ends.

Re: I wrote JavaScript to avoid JavaScript

#32

Post by vanderZwan »

So whenever I see an article about this topic I like to open the Network tab of Developer Tools, disable cache and refresh to see how this work out in practice.

This page loaded in just under a second, and had 1.30MB of data in total. Pretty good!

However, when looking at where all the data is there seems to be something fishy going on. Basically, for some reason it loaded both a .webp and .webm file for the sticky header animation. The webp is a 450 KiB choppy animation, the webm a 770 KiB smooth one. If we skipped the webp that would be a 33% reduction in data and presumably equivalent speed-up of page load, so why bother loading a choppy gif?

Looking into the page source I get this tag:
So I'm wondering if there is a point in adding a poster like that, given that it's not going to be seen for most people and probably going to be a major part of the data budget on any page that has any number of video tags on it.

(Also, my browser acts a bit funny here: if I refresh again it only downloads the webp, but still shows the webm - despite cache being disabled. Could it be that the video tag ignores my cache settings?)

Re: I wrote JavaScript to avoid JavaScript

#33

Post by vanderZwan »

anonymoushn wrote: post #6

On OSX Chrome, this page is always horizontally scrollable because the navbar is wider than the rest of the content by a margin of the vertical scrollbar's width. You can set max-width: 100% on the navbar to fix this.

I suspect scrollbars are among the most underrated source of unexpected CSS bugs across different browsers/platforms. I never see anyone online complain about them, yet at work we constantly have to work our way around them.

Re: I wrote JavaScript to avoid JavaScript

#34

Post by muspimerol »

Dionakra wrote: post #25
muspimerol wrote: post #18

Earlier quoted context omitted.

For ease of maintenance and portability I think markdown is really the king of formats for blog content. Are you writing the posts in HTML? Why are you intermittently using for paragraphs and to wrap other elements?

Yep, I am writing the posts in HTML. The reason to avoid Markdown (which I love) and other things is to avoid any kind of building tools. I tried to install Gatsby on a Windows machine and I had several errors. I wanted to remove any dependency on external software. I wanted it to be modifiable with just a text editor and nothing else. Regarding the use of is because the tag with the chosen CSS leaves too much space…

I definitely understand the desire to avoid a build-time tool. Especially Gatsby is way harder than it should be to get up and running. But for me, portability and data integrity trumps ease-of-publishing. If you want to move your blog to a new system in 5 years, you'll have to migrate a bunch of HTML. If you had the posts in markdown, chances are it would be a plug-and-play with the new system.

That's the reason I pointed out the usage - your source of truth for your data is HTML, but in this case it's already getting mixed up with design-related oddities.

Not bashing your choice for your blog, I think it's reasonable. I just wonder if HTML is the most resilient way to store blog data. It's something I considered a lot when redoing my blog last year.

Re: I wrote JavaScript to avoid JavaScript

#35

Post by infensus »

vanderZwan wrote: post #32

So whenever I see an article about this topic I like to open the Network tab of Developer Tools, disable cache and refresh to see how this work out in practice. This page loaded in just under a second, and had 1.30MB of data in total. Pretty good! However , when looking at where all the data is there seems to be something fishy going on. Basically, for some reason it loaded both a .webp and .webm file for the sticky…

I've had similar experiences with video cache and never fully understood it. For example, when I want to block a webm with ublock, adding a rule and refreshing never works, I need to close and reopen the tab for it to take effect.

Re: I wrote JavaScript to avoid JavaScript

#36

Post by tiborsaas »

gbrindisi wrote: post #9

Wonderful! I am so irritated with JavaScript bloat... completely unnecessary cruft 99% of the time. I built my blog with the goal to have zero js but I had to capitulate for google analytics. The blog is a static website deployed on a CDN and I have no access to access.log - I honestly couldn’t find any analytics solution that won’t require js.

That's great, but try to work with 25-50 other frontend developers on the same product. You will soon run into challenges which you can only solve by adding more and more layers abstractions. It's not a defense of bloat, but just an explanation that why some products look incredibly complex on the frontend stack.

Re: I wrote JavaScript to avoid JavaScript

#37

Post by raxxorrax »

jakub_g wrote: post #28
zelphirkalt wrote: post #22

Earlier quoted context omitted.

Huh? Can you link such a study? I always found it easier to read justified text. Already the annoyance, that the text is not ending at the same "column" on the screen on the right side of the text is distracting. It also looks like no one really took care and simply dumped a ton of words, when it is left aligned, at least to me.

In print, you have fixed, known in advance width; hyphenation; sophisticated multipass algorithms; manual review of the typesetter. Justification can make sense. On the web, with responsive design, container width is dynamic. Algorithms are less sophisticated. Hyphenation is kinda supported but only for few languages and few websites use it ( https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens ) although Eric Me…

I think the lacking hyphenation is the main problem for web content, since it creates large empty spaces in conjunction with justified text.

But having hyphenation would mean that browsers would need to have an extended dictionary for all languages.

For reading I actually prefer it when done right, but that is subjective, I never stopped the time.

Re: I wrote JavaScript to avoid JavaScript

#39

Post by RobertKerans »

zelphirkalt wrote: post #22
jakub_g wrote: post #19

Earlier quoted context omitted.

+1. Justification is something that you feel like you should do to have "nice layout" but it hinders readability according to many studies. Check BBC, NYTimes, The Guardian, Reuters, AP News, Wikipedia, HN - none of them uses text justification.

Huh? Can you link such a study? I always found it easier to read justified text. Already the annoyance, that the text is not ending at the same "column" on the screen on the right side of the text is distracting. It also looks like no one really took care and simply dumped a ton of words, when it is left aligned, at least to me.

It doesn't really need studies per se because [specifically for web] justification doesn't work properly without significant overhead. You can easily justify badly (normally with a single property applied to the text), but to make that work well, the browser (or app, same is true there) will blindly split words and drastically adjust the tracking between words, leaving huge rivers in the text which unequivocally make things difficult to read. When setting text on the web, it's far more practical to set it ragged right, as it avoids this problem (with the trade-off that it may not be as pleasant to read as properly justified text).

In print, if I'm typesetting, I a. have a fixed container size within which to apply justification, b. have access to advanced justification settings that allow for smart word breaking based on word length, language and regex patterns, and c. on top of that as a final step I can work forwards through the text, manually breaking words or adjusting tracking on a per space basis to remove any remaining rivers.

On the web, this isn't available, so justification there is an extremely blunt and not particularly useful instrument

Re: I wrote JavaScript to avoid JavaScript

#40

Post by strzibny »

gbrindisi wrote: post #9

Wonderful! I am so irritated with JavaScript bloat... completely unnecessary cruft 99% of the time. I built my blog with the goal to have zero js but I had to capitulate for google analytics. The blog is a static website deployed on a CDN and I have no access to access.log - I honestly couldn’t find any analytics solution that won’t require js.

Netlify offers this.
Post reply on HN