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 gotx-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*
orquerySelector(All)?
- can't immediately tell which elements have bound events
- could probably use something like
data-bound
or somethin
- could probably use something like
- you'll just make your own shitty library/framework anyway
- don't reinvent the wheel, even to learn!!!!
</strawman>
- don't reinvent the wheel, even to learn!!!!
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