What is Hackers' Pub?

Hackers' Pub is a place for software engineers to share their knowledge and experience with each other. It's also an ActivityPub-enabled social network, so you can follow your favorite hackers in the fediverse and get their latest posts in your feed.

0
0

Kagami is they/them 🏳️‍⚧️ shared the below article:

Ten years ago today I coined the shorthand “js;dr” for “JavaScript required; Didn’t Read” * https://tantek.com/2015/069/t1/js-dr-javascript-required-dead in reference to (primarily content) pages that were empty (or nearly so) without scripts. Since then js;dr found its way into a book: Page 88 of “Inclusive Design Patterns” by @heydonworks.com (@heydon@front-end.social) Cropped photo of part of page 88 of Inclusive Design Patterns at an angle and stickers! A hand holding about a dozen stickers with the “js;dr” in black on white text die-cut around the edges of the lettering At the time I made the claim that: “in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.” I’ve seen and documented many such sites, built with a hard dependency on scripting, that end up dead and unarchived. Many of these have been documented on the IndieWeb’s js;dr page: * https://indieweb.org/js;dr I have to ask though: does anyone remember building a site 10 years ago (Internet Archive citation) with a Javascript library/framework dependency to display content, that still works today? E.g. using one of the popular libraries/frameworks used to build such sites back then like AngularJS (discontinued 2022), Backbone.js, Ember.js, or even React which was still quite new at the time. The one almost exception I found was Facebook, e.g. this Smashing Magazine post on Facebook barely renders some content and all commentary is missing, in the earliest (2019) version saved on the Internet Archive: * https://web.archive.org/web/20191123225253/https://www.facebook.com/smashmag/posts/10153198367332490 You can extract the direct Facebook link if you want to try viewing it in the present. Regarding those libraries/frameworks themselves, I wrote: “All your fancy front-end-JS-required frameworks are dead to history, a mere evolutionary blip in web app development practices. Perhaps they provided interesting ephemeral prototypes, nothing more.” Of all those listed above, only React has grown since, likely at the expense of the others. However instead of fewer such libraries and frameworks today, it seems we have many more (though it feels like their average hypespan is getting shorter with each iteration). Since I wrote “js;dr”, the web has only become more fragile, with ever more dependencies on scripting just to display text content. The irony here is that Javascript, like XML, has draconian parsing rules. One syntax error and the whole script is thrown out. This means it’s far too easy for any such JS-dependent site to break, in one or more browsers, whenever browsers change, or Javascript changes, or both. You wouldn’t build a site today (or 20 years ago) that depends on fragile draconian XML parsing, so why build a site that depends on fragile draconian Javascript parsing? I’ll repeat my claim from ten years ago, slightly amended, and shortened: In 5 years nothing you (personally, not a publicly traded company) build today that depends on Javascript in the browser to display content will be available, visible, or archived anywhere on the web. There’s a lot more to unpack about what we’ve collectively lost in the past ten years of fragile scripting-dependent site-deaths, and why web developers are choosing to build more fragile websites than they did 10 or certainly 20 years ago. For now I’ll leave you with a few positive encouragements: Practice Progressive Enhancement. Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques. All content should be readable without scripting. Links, buttons, text fields, and any other interactive HTML elements should all work without scripting. Scripts are great for providing an enhanced user experience, or additional functionality such as offline support. Then make sure to test your pages and sites without scripts, to make sure they still work. If it's worth building on the web, it's worth building it robustly, and building it to last.

Tantek Çelik @tantek.com@fed.brid.gy

Ten years ago today I coined the shorthand “js;dr” for “JavaScript required; Didn’t Read”

* https://tantek.com/2015/069/t1/js-dr-javascript-required-dead

in reference to (primarily content) pages that were empty (or nearly so) without scripts.

Since then js;dr found its way into a book:

Page 88 of “Inclusive Design Patterns” by @heydonworks.com (@heydon@front-end.social)

Cropped photo of part of page 88 of Inclusive Design Patterns at an angle
and stickers!

A hand holding about a dozen stickers with the “js;dr” in black on white text die-cut around the edges of the lettering

At the time I made the claim that:

“in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.”

I’ve seen and documented many such sites, built with a hard dependency on scripting, that end up dead and unarchived. Many of these have been documented on the IndieWeb’s js;dr page:

* https://indieweb.org/js;dr

I have to ask though: does anyone remember building a site 10 years ago (Internet Archive citation) with a Javascript library/framework dependency to display content, that still works today?

E.g. using one of the popular libraries/frameworks used to build such sites back then like AngularJS (discontinued 2022), Backbone.js, Ember.js, or even React which was still quite new at the time.

The one almost exception I found was Facebook, e.g. this Smashing Magazine post on Facebook barely renders some content and all commentary is missing, in the earliest (2019) version saved on the Internet Archive:
* https://web.archive.org/web/20191123225253/https://www.facebook.com/smashmag/posts/10153198367332490

You can extract the direct Facebook link if you want to try viewing it in the present.


Regarding those libraries/frameworks themselves, I wrote:

“All your fancy front-end-JS-required frameworks are dead to history, a mere evolutionary blip in web app development practices. Perhaps they provided interesting ephemeral prototypes, nothing more.”

Of all those listed above, only React has grown since, likely at the expense of the others.

However instead of fewer such libraries and frameworks today, it seems we have many more (though it feels like their average hypespan is getting shorter with each iteration).

Since I wrote “js;dr”, the web has only become more fragile, with ever more dependencies on scripting just to display text content. The irony here is that Javascript, like XML, has draconian parsing rules. One syntax error and the whole script is thrown out.

This means it’s far too easy for any such JS-dependent site to break, in one or more browsers, whenever browsers change, or Javascript changes, or both.

You wouldn’t build a site today (or 20 years ago) that depends on fragile draconian XML parsing, so why build a site that depends on fragile draconian Javascript parsing?


I’ll repeat my claim from ten years ago, slightly amended, and shortened:


In 5 years nothing you (personally, not a publicly traded company) build today that depends on Javascript in the browser to display content will be available, visible, or archived anywhere on the web.


There’s a lot more to unpack about what we’ve collectively lost in the past ten years of fragile scripting-dependent site-deaths, and why web developers are choosing to build more fragile websites than they did 10 or certainly 20 years ago.


For now I’ll leave you with a few positive encouragements:


Practice Progressive Enhancement.

Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.

All content should be readable without scripting.

Links, buttons, text fields, and any other interactive HTML elements should all work without scripting.

Scripts are great for providing an enhanced user experience, or additional functionality such as offline support.

Then make sure to test your pages and sites without scripts, to make sure they still work.


If it's worth building on the web, it's worth building it robustly, and building it to last.

Read more →
0
0
0

블루스카이 CEO Jay Graber 가 SXSW 토크가 있었어요. 저커버그를 카이사르로 비유한 티셔츠를 입고 나와서 화제를 모았죠. 긴 영상 (약 1시간 내외) 이지만 초기에 어떻게 블루스카이 프로젝트에 참여해서 리더가 되었는지 부터, 인상적인 부분이 많아 정리해봤어요.

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0

Here's me rambling about libzfs and libzfs_core, the weird libraries that power the CLI tools and very little else. Along the way, we look at some of the other inadequate OpenZFS programming options that exist, the chats we've had about them the OpenZFS Production User Calls and the very first steps I'm taking to try and make sense of this whole mess.

With thanks to @bsdfund. Turns out that if you buy me some snacks I'll write whatever you want! 🤑

despairlabs.com/blog/posts/202

0
0
0
0
0
0
0
0
0
0
0

(The worst thing about finally having working Notion Workflows that actually work for me is that given its hosting location I will need to move away from it soon-ish and there's really nothing suitable as replacement)

0
0
0
0
0
0
0
0

‘기금이 고갈된다는 프레임때문에 공적 기금의 지향이 제대로 얘기되고 있지 못한것 같다’😤 ‘안심하고 아이 낳을 수 있다면, 고용이 안정된다면, 평등한 사회, 분배가 잘 되는 사회라면? 자연스럽게 국민연금 재정도 함께 건전해질 수 있지 않을까’👏 복잡한 국민연금의 세계(!)를 모두 이해하기에는 짧은 시간이었지만. 노후를 생각하며 너무 아득해지지만은 않을 수 있는, 사회 안전망이 갖춰진 사회를 조금 상상해볼 수 있었습니다😁

0
0
0
0
0
0

Edit: thanks guys! I love how much you love these questions.

__

I have 15 minutes on friday to try to Inform my coworkers about the side of internet we like, ie the parts not run by large companies. I can say whatever I like, including try to sell them on some integrity stuff.

While I have a sketch of a plan: anything you would say in my situation that shouldn't be ignored? (Open question to see if I've missed anything)

Boosts welcome.

0
0
0
0
0
0
0
0