i can't shut up about web dev

when you webdev

WHEN YOU TRADE USER EXPERIENCE

FOR DEVELOPER EXPERIENCE

the absolute state of web dev

This is from a real website of a modern "web developer".

I couldn't have painted a better picture of 21st century web dev even if I tried.

who cares?

haha, you must be insane for only listing html, css and js on your skills list.
that's the bare basics lmao. they'll look at people who have much more - react, vue, tailwind... the whole nine yards.

no one will GIVE A SINGLE SHIT if your website works without scripting or if it doesn't eat your user's ram.
or if your website (really a web app) is "accessible", like, at all.

they only care if you can make it in like 5 hours, and looks really good regardless of contrast issues.
they won't mind the 10 megabytes of javascript loading in the background.

the world moves fast, bucko. it's time for you to adapt.

who needs stability?

who needs performance?

who needs bandwidth optimization?

the world is burning, may as well roast a marshmallow on it.

on building a single page app

when I make one of these, I want one that works well on html as much as it would on a single page. easier said than done.

the backend & HTML stuff is piss-easy. it's the SPA-izing that gets me.

the single script file I end up making has hundreds of lines for sure (even more if you count comments).

i'm trying to create and fade in components dynamically from a json response, y'know, like a regular SPA thing. the extra work here, then, is matching what the JS generates to what I laid out in the HTML.

i'm using bliss.js for this since it has some shortcuts for common JS stuff.

come on... do it... you WILL use react...

maybe i will, but i won't like it much. at least, not until i forget what react is doing to users.

in fact, to me, all of this is worth doing as I'm learning a bunch of stuff.

like Prototype, even if i'm doing it to global js objects like String and Date. we do a little trolling

maybe a bit about Promise and addEventListener too, even if it's just the basic stuff really

hundreds of lines? yep, sounds like you're making your own shitty framework. it's not optimized and probably insecure

and?

my single script file so far is 30kb (9kb minified) + 12kb minified for bliss.js
what it's for does so much more than an extremely basic hello world in react (generated code: 130kb) lmao

you know the web sucks

• html

  • barely a standard
  • constantly getting toyed around by browser vendors (hello, browser wars)
  • everyone is picking elements for their visual appearance (see <h1> to <h6>)
  • one engine is dominant, there are no good browsers.

• js

  • most of js code is machine-generated or compiled, that's why everything's so bloated now
  • the ecosystem gets so big and unnecessarily complex that javascript fatigue is actually a thing. i don't see this shit in other programming (or scripting) languages.
  • places with mostly static content that block you if you have js disabled: fuck you.
    • "imagine disabling js": imagine prioritizing DX over UX, my comfort is your suffering.
    • everywhere should be treated as a privacy AND security nightmare with js enabled. can never be too safe.
    • if your site is ORDERS OF MAGNITUDE faster to navigate with js off, you've got serious issues.
    • how about the recent zero days huh? that's another reason to have noscript.

• css

  • the syntax doesn't make sense for a cascading language, oh, but it is designed to be "quick".
  • !important; !important; !important; !important; !important; are you coding son?
  • it's so hacky to get anything right in it
  • noooooooooo you have to use .message.-error! haha utility classes go tx-red.p-4.mx-3.bg-blue.h-4.bs-black:4.zoom.tf-serif

support cutoff

the best way to start thinking about absolute browser "support cutoff" now is from your own server

does it use https? good

now check what kinds of cipher it's using for connections and check the earliest version of a browser that supports it

like i said, it's kinda pointless to design specifically for a 90s browser but then you can't open it as-is on it

how scalable are you?

does it matter? i.e. you are a big shot of a company needing to accomodate hundreds of customers concurrently

does throwing more code than needed on your service make it more scalable?

can you explain what is being added and how does it impact your customers?

(even function calls take time!)

feature detection > user agent sniffing

user agent sniffing is how we got "Mozilla/5.0" on every visual browser UA

not sure if you need extra boilerplate to do that (cough Modernizr cough), feature detection should be as simple as if ("customElements" in window)

anti-user

cOnSidErEd hArMfUl:

• scripts obfuscated thru webpack and babel
• bloating the webpage with subversive patterns like utility-only css
• making the client do all the work (looking at you, react)
• fixed-unit sizing everywhere
• very low contrast designs where all the content is located
• failing to balance developer convenience with client soundness
• completely unusable site without javascript

the most minimal opengraph setup

just the sitename, image, basic html description. ez:

<title>Delectable Dinkums</title>
<meta property="og:site_name" content="My Site">
<meta property="og:image" content="https://http.cat/200">
<meta name="description" content="This is where I get to dump all my shitposts :^)">
<meta name="author" content="anon">

(note, og:image must be an absolute path)

here's how it'll show up in discord etc. :

.---------------------------------------.
| My Site                               |
|                                       |
| Delectable Dinkums            [Image] |
|                                       |
| This is where I get to                |
| dump all my shitposts                 |
| :^)                                   |
._______________________________________.

css class methodologies

bem (broke)

<section class="card">
  <div class="card__image">
    <img src="example.jpg" alt="Example image">
  </div>
  <div class="card__description card__description--flashy">
    <p>Hey lookit me!!! I'm fancy</p>
  </div>
</section>

.card {}
.card__image {}
.card__description {}
.card__description--flashy {}

smacss (just got out of bed)

<section class="card">
  <div class="card-image">
    <img src="example.jpg" alt="Example image">
  </div>
  <div class="card-description is-flashy">
    <p>Hey lookit me!!! I'm fancy</p>
  </div>
</section>

.card {}
.card-image {}
.card-description {}
.card-description.is-flashy {}

idunno what this is called, it's not like it's better or anything (woke)

<section class="card">
  <div class="_image">
    <img src="example.jpg" alt="Example image">
  </div>
  <div class="_description -flashy">
    <p>Hey lookit me!!! I'm fancy</p>
  </div>
</section>

.card {}
.card ._image {}
.card ._description {}
.card ._description.-flashy {}

directly tying it to markup order (awokened)

<section>
  <div>
    <img src="example.jpg" alt="Example image">
  </div>
  <div>
    <p>Hey lookit me!!! I'm fancy</p>
  </div>
</section>

section {}
section div:nth-of-type(1) {}
section div:nth-of-type(2) {}

utility-only (BESPOKE)

<section class="flex-horiz:lg flex-vert:md">
  <div class="h-3">
    <img src="example.jpg" alt="Example image" class="w-100p h-100p">
  </div>
  <div class="px-4 py-4 grey-100 flex-grow">
    <p>Hey lookit me!!! I'm fancy</p>
  </div>
</section>

xhtml seems like a good idea?

draconian error handling, actual validation, remains untouched by people who wanna put fucking DRM on it, what more can you ask for?

but please, stop using text/html as the content type

the only problem now is fouc (see below)

it's completely inevitable with the xml renderer, no anti-fouc fuckery will save you now. but i accept that lmao

also if you use text/html, shortform empty tags like <div/> won't work anymore

always remember

every html element is a <div> or a <span> if you wish for it hard enough

so there's no excuse for picking elements solely based on how they look

framework 👏 review 👏

I looked at a review of vanilla vs js frameworks

points taken:

• hooking to random elements can be hard, have to use getElements?by* or querySelector(All)?
• can't immediately tell which elements have bound events
  • could probably use something like data-bound or somethin
• you'll just make your own shitty library/framework anyway
  • don't reinvent the wheel, even to learn!!!! </strawman>

looking at independent demos made from those frameworks and you might've guessed that they require JS just to display the page

svelte I feel fares a bit better because you can make it so that it renders HTML from the get go. the realworld demo is a project that aims to put all of these frameworks and libraries to the test, and even the vanilla app!!! requires javascript.

svelte team's on the other hand, has enough conscience to load the basic elements without javascript. sawir's implementation is even better, because you have everything rendered out already using php and I bet alpine is a sweetener.

but then most of these frameworks have syntax that just looks uncanny:

• react has jsx
• you have colons as attribute names in vue

why single page apps?

oh its only like .3% who disable javascript and they're autists anyway

that number will rise alright, as more people have slowdowns thanks to the absolute metric ton of js being used on every website worth a damn

you know, this idealism probably won't work and that I should go with what the industry is doing anyway

I hear another point of SPA is shifting rendering logic from the server to the client

the problem is that clients will have absolute shit machines

getting rid of timezone disparities

pretty good idea but even that can be adjusted for separately

not having to store sessions since variables are global

looks like your app is pretty stateful

if you really need to use a framework

might i recommend svelte (compile-time builds, major performance perks!)

or even better, alpine.js (4kb goodness) it's 36kb.
not bad, but i dunno where i got that ridiculously low number from.

elementals.js is also pretty good (25kb)

fouc doesn't actually matter anymore

...because the either the page loads without the styling or the entire render is blocked until the style is loaded

anti-fouc measures can be decidedly anti-user by making the site completely unusable without javascript, as an anti-fouc approach includes covering the page with a loading screen and applying classes which makes elements hide.

if javascript is disabled, the anti-fouc hooks won't run, so nothing will be visible to the user

a surefire way to prevent fouc is ensuring the user is operating on text/html at any time

custom elements

turns out a few browsers don't actually support custom elements and the page will shit itself if any functionality depended on it.

last I checked that's pale moon and seamonkey

proprietary js

sometimes I wonder if webpack is an exercise in proprietary js. just look at what it outputs, it's completely opaque shit, but at least you won't use as many bytes

utility-first

they told me that it's utility-first CSS, not utility-only, and that @apply is the solution.

problem is, does anybody even use @apply????

i think more people should do this (tailwind as an example):

.button {
  @apply
    px-4
    py-2
    bg-blue-600
    text-white
    rounded
}

granted the output won't be very optimal, but it is a good step