I wrote JavaScript to avoid JavaScript | Hacker News Reader

I wrote JavaScript to avoid JavaScript

markentier.tech

74 pointsasaaki59 comments

I strongly advise against this style of justification:

  text-align: justify;
  text-justify: inter-character;

Justification is typically only particularly suitable for fairly narrow columns, combined with hyphenation. And inter-character justification is… hazardous, only to be entered into with substantial caution.

Sometimes layouts and what occurs to the inline-end [right] of the layout can also justify justification

But unless one of these conditions is true, I recommend against any form of justification, especially inter-character.

Another bit of CSS that I would like removed is the `html { cursor: default; }`. Apps can do that so that chrome uses the default cursor (and restore it to auto in content areas), but content websites shouldn’t do that. I want to see the usual I-beam when I’m hovering over text.

+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.

https://ux.stackexchange.com/a/93442

That link mentions no such studies. It has opinions from typographers, but no data on how text justification affects readability.

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 Meyer advises to turn it on on mobile (http://meyerweb.com/eric/thoughts/2012/12/10/should-you-hyph...).

Quickly googling around:

- dyslexic people have troubles with "white rivers"

- (1986) speed is lower when reading justified text https://journals.sagepub.com/doi/abs/10.1177/001872088602800...

- (2019) https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6722069/

> Guidelines for text readability and empirical evidence from the present study:

"Guideline: Use left-justified text with ragged right edge: Empirical support: yes"

> (...)Eye movements during reading are characterized by a sequence of jerky movements (saccades) followed by moments in which the eyes are held relatively still (fixations) on a target - typically a word - to allow its decoding and processing.

> (...)The use of Left-Aligned Text facilitates reading by reducing the number of fixations

Edit:

See also UK gov guidelines:

https://www.gov.uk/government/publications/inclusive-communi...

- Align text left for maximum legibility. - Avoid right aligning or justifying text. - Avoid using hyphens to split words between lines.

Thank you! In the 2019 readability study, the things that did not affect readability (null effects) are at least as interesting as things that did. Organizing Table 4 from https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6722069/ by reported empirical support:

Null effect:

- Ensure high luminance contrast between text and background

- Avoid using italics

- Use bolding to highlight

- Avoid underlining large blocks of text

- Use a plain, evenly spaced sans serif font

Partial:

- Avoid formatting texts in large-width columns

Yes:

- Limit the amount of content on a page

- Use a minimum of text size 12 pt or 14 pt

- Keep the between-line spacing of 1.5 point

- Use section headings

- Use left-justified text with ragged right edge

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.

Browsers already maintain hyphenation dictionaries (and/or know how to ask host OSes for them), it's just that because hyphenation and justification are two different knobs in CSS a lot of sites turn on one without the other.

Browsers also support some of the same tricks that designer tools support to encourage/support hyphenation such as supporting soft hyphens (https://en.wikipedia.org/wiki/Soft_hyphen). But those tools are something that require training and/or forethought and not something that average web content would likely include.

Thank you for the detailed response. Interesting links I will work through over time.

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

I do a lot of JavaScript, maintaining older and newer apps. I have been of the opinion for a decade that most apps and even static sites are way more JavaScript-heavy than they need to be and that we depend far too much on frameworks, so much so that even very good developers don’t know much actual HTML and CSS. Yeah I know it’s the old “too much abstraction” argument, but I strongly believe it. It’s a breath of fresh air when people write articles like this because it brings us down to earth. Now, I’m not saying going JS-free is appropriate for all cases or even most cases. Sometimes the customer has complex requirements or the project you’re brought in on uses JS at its core (Rails, React, Angular, any of the SPA frameworks). Heck, I’ve even written my own SPA framework because reasons. Point is, there is absolutely nothing wrong with the “old fashioned” static page apps in many cases - using forms, letting the back-end handle business logic, not having to worry about routing, etc.

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.

> I had to capitulate for google analytics.

Ask yourself how much you actually need analytics. I found I seldom looked at it. I myself replaced Google Analytics with self-hosted Matomo for a while, but then I just dropped it altogether because I simply don’t need it. Now I do have server logs that I can look at, and from time to time I do (and they reveal things like Atom feeds consume the substantial majority of the traffic and page loads, which client-side JS logging would never have revealed!), but it wouldn’t bother me to have no analytics at all.

I just want to know if what I write is being read and how is propagated/shared

If effort or time was not a limitation, you could opt for a tool that you can self host, instead of increasing Google's data.

access.log

I decided to have no (client side) tracking at all, for both usually it requires JS and cookies. And honestly I don't like to have both on my site if not strictly necessary (as a European citizen I'm also quite aware of all the shenanigans one has to do wrt privacy and consent).

Out of curiosity, what decision do you anticipate taking for your personal site that would be informed by data from Google Analytics? In a commercial setting, it would be for things like adjusting marketing budgets (presumably not applicable), reviewing hosting infrastructure (you seem to have that taken care of), adjusting content strategy (not an issue if you're publishing on your own terms?) etc.

Simply put: I want to know if what I am writing is being read and how is propagated.

Yeah, but what will you change based on what you discover? That’s the essence of what tweetle_beetle is asking and why many end up deciding that they don’t actually need analytics—because they’re not going to change anything based on what they observe.

like it or not, analytics can give you actionable information to drive some seo improvements in how your content is displayed and consumed

Can, sure, at least once you have enough volume of content; but will you use it? Almost no one actually does for personal blogs and the likes.

Perhaps its a professional blog and they’d like to know about their audience.

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.

Netlify offers this.

I did almost the same last weekend. I wanted to start a blog[1] but all options seemed too much for a simple purpose that is a blog. After researching about VuePress, Sapper, Next.js, Gatsby and so on, I finally decided that it wouldn't have any kind of JavaScript. I was tempted to create yet another static site generator, but I am sticking to the old HTML + CSS duo (and, regarding CSS, classless CSS) for my blog. Yes, it has some downsides, but hey, it only needs a text editor and internet connection and the blog is blazingly fast.

[1] https://boix.dev/

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 after <h*> tags, while doesn't, and as I wanted to just use HTML tags and not create my own version of the CSS, I found the easiest way to achieve that.

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.

You can use Jekyll for a JS-less markdown to static site generator.

Also zola, hugo, and other pretty light weight generators are quite okay. I'm using zola which runs nicely on Win/Mac/Linux. All you need to get started is some theme/template and your blog posts in Markdown. Then enrich it with whatever floats your boat.

> The only annoying part is still that the image dimensions are not reserved appropriately, even with present width and height attributes. So the layout can jump around if you scroll past the not yet loaded image. If you have an idea how to deal with that within picture groups, I love to hear about it.

See https://www.andyshora.com/css-image-container-padding-hack.h...

I used the trick on https://jessicakhope.com's blog-post pages. View the source on https://jessicakhope.com/blog/family-workcation-in-portland-..., for examples.

The site is static and is generated by hugo. The image container paddings are generated at compile time.

Thank you for the tip/link. Seems to be an appropriate solution, just have to fiddle with my build process for a bit.

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.

Aha? That sounds interesting. Usually those "I'm gonna use a full blown framework, although nothing special is needed." websites appear in pure white over the whole screen, with nothing to be seen. Which is usually when I close the tab. Are you saying, that NextJS encourages a design, which keeps no script in mind? Is it its default to render a noscript tag or something? This would definitely raise it in my personal rating.

Next has two different ways to deploy:

1. Next renders the React page server-side and sends it as html/css. Once everything is done loading on the client, it becomes a regular React page. Requires a server. 2. Next pre-renders your whole website with data fetched at build time, like Hugo or Jekyll. Drop it on a CDN and you're golden.

Is it able to somehow transform dynamic loading of content into expected clicking of links, upon which the server delivers another static HTML + CSS page? Or is this "prerendering" limited to already static parts of the website?

It would be great to have a web framework, which automatically transforms everything into links, which, when clicked, cause the server to deliver an updated HTML + CSS, which shows the same info, as one would have seen with a dynamic update using AJAX.

Something like this? https://github.com/turbolinks/turbolinks

Hmmm more like: "I actually have a JS framework website, which would use AJAX to load parts of the page to update pages and not reload the whole page, _however_, if you have JS deactivated or blocked, I will automatically work using normal links, which then work as if someone had taken the effort of writing all the code for making the dynamic portion of the page work by just using links and full page reloads." -- So kinda like magic.

But what you linked to is interesting nevertheless. :)

To add to what ruicaridade said:

> Are you saying, that NextJS encourages a design, which keeps no script in mind?

It quasi enables it, a NextJS site has three rendering stages:

1. static at build time 2. server side at request time 3. dynamic in the browser

It leverages React hydration for 1-2 and client side React for 3.

If you avoid 3, or rather build your site with progressive enhancement in mind (`noscript` can help but is often not necessary) then this framework makes it very easy for you.

I think https://reactjs.org/ is built with Gatsby (a similar framework, but not as dev friendly in my opinion). And you can browse it just fine with JS off last time I checked.

As a counterpoint, I just want to mention that I once wrote perl that wrote Javascript that wrote HTML.

And I'm not even ashamed of it.

Perl … haven't seen that old friend for a very long time.

I should be clear this was about 15 years ago.

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:

    <video autoplay="" loop="" muted="" playsinline="" poster="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.webp">
    <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.hvec.mp4" type="video/mp4; codecs=hvc1">
    <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.hvec.mp4" type="video/mp4; codecs=hevc">
    <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.h264.mp4" type="video/mp4; codecs=avc1">
    <source src="https://markentier.tech/posts/2020/10/wrote-javascript-to-avoid-javascript/pos-sticky.webm" type="video/webm; codecs=vp9">
    </video>

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?)

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.

I think I should just remove the poster, it was initially replacing the GIF, which was megabytes in size. Given that the sizes of the WebP and WebM animations are pretty close I can live without it; all major browsers support both formats anyway.

I cannot help with the caching fun here, quick tested in both Chrome and Firefox. There's probably something strange in the video tag, either by design or by implementation.

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.

That's interesting. I'll have Mac access only next month. The setting `max-width: 100%` actually breaks the design completely, chopping it down to a half.

I have to try this solution[1] to see if that helps to avoid the scrolling.

[1] https://stackoverflow.com/a/56382662/653173

Nice! Pagespeed Insights is also happy with your site ;) I especially liked the new format stats, pretty impressive. Now if only I found a good node module for avif conversion...

Thanks.

If you're okay with a non-node/js solution, use https://github.com/kornelski/cavif-rs - it does the job for me pretty well.

For node it looks surprisingly disappointing right now, the only real candidates being the packages @saschazar/wasm-avif (v1.0.0) and avif (v0.0.1-alpha2) — I'll probably never understand the ecosystem and community, the format is out for some time and fully supported in the most widely used browser, yet barely noticeable support in the JS world.

Thanks for the tips - I'm tied to node at the moment - wasm-avif has serious issues with thready safety an memleaks :( tried it.

If you're in control of the environment, you might want to consider the yak shaving road and build a node package with a C, C++ or Rust library then. ;-)

Sharp lib is veeeerrryyy close to AVIF support: https://github.com/lovell/sharp/issues/2289 (you can compile a version to use for yourself, it's just not production stable yet).

At first glance, the title is a bit misleading I think a more accurate one could have been "I don't write Javascript to avoid it" or "I just avoid to write Javascript", etc. Anyway great that the author remarks the idea to avoid Javascript bloat but honestly that's not something new.

He used the stones to destroy the stones.

I don't like the style this site uses. Ugly color choice, typography and whitespace all over the place, and emoji ridden visual noise. Like why spend all the time picking exotic fonts and optimizing images if the presentation is simply put, awful?

Reply on news.ycombinator.com