i can't shut up about web dev

non-technical gripes with rust specifically

the language is pretty great from a technical standpoint. i see its benefits. i know. other languages have taken ideas from it. i use packages that emulate it. but i have not brought myself to use it, if i can help it. the borrow checker seems to be the least of my problems.

use of latest features

every new release of rust tries to maintain compatibility with most rust code that's been written (that is—every rust code in github).

but it's immediately nullified by everyone (including the rust-in-linux project) using nightly instead of stable, or use a very recent stable.

a fortnightly release schedule is also a nightmare for "stable" (read: glacial) projects wanting to ship rust, so the compiler shipped with those versions couldn't compile a lot of rust code because those code use the newer versions.

while i trust that backwards-compatibility is not an issue here, it's the issue of providers being expected to keep up with rust releases. which means you basically need someone to guard that post, along with the headache of trying to coordinate that with the provider's manager. supporters brush it off by saying, "get with the times, old man".

rust's release train mechanism is looking more like a hype train: the fact that "minimum supported rust version" (MSRV) is a common phrase, and that this website is a thing should tell you something about how frequently the language is updated.

some people like chasing trains like this, others don't.

obtuse method chaining

i'm fine with "method chaining". i use it quite often. under the condition that it remains clear-at a high level-what it's doing. what do rust libraries often do?

something.into().to_iter(), foo.unwrap(), std::iter::IntoIterator::into_iter(baz)…

just get to the point already! no, i don't buy that "it's not boilerplate because it makes it clear what you are doing exactly to your object," i just want to decipher the damn thing!

"this is just what you signed up for when you do systems programming, everything is laid bare unlike C where you need to keep it all in your head" except rust is not just used for "systems programming", but then where's the line? it's just a social construct is it? can i trust what i see with my eyes? no, of course not.

packaging

cargo's package culture seems to mirror that of npm. when people think of left-pad they think of:

1. the inadequacy of the standard library (javascript added a native left-pad after the incident, around 2016/17 to be exact)
2. many, many trivial packages often consisting of a single line, upon which many packages either depend upon, or is the root of a deep, deep dependency tree.

rust's stdlib is capable enough, so point 1 doesn't quite apply. point 2 however… it's not that trivial in rust to do things that are trivial in other languages, sometimes including even C.

i understand, rust requires you to really think about memory in a way that other languages don't (because memory management is quite important), so there's lots of utility packages that iterate on each other. really driving home the meaning of "not reinventing the wheel in an insecure way"

however. one big problem.

compile a rust project, look at the cargo dir.

how big is it?

the simple formula is this: take the large amount of small packages, and consider that each package is statically-compiled. what do you get? BOOM! megabytes of package cruft. at least node_modules, even with the ungodly amount of files, don't actually weigh that much.

culture

aka my biggest non-technical problem with rust.

one or two arrogant bad apples in a community—that's understandable. how about an entire culture? don't get me wrong—it's "welcoming", it's "pleasant", and i am sure it's a lot of fun to be around. however, consider that:

1. rust is positioned to be the cutting-edge in safe yet performant programming languages.
2. borrow-checking answers the "speed vs safety" question with "why not both?"
3. the same mechanism helps prevent data races, so 🔥fearless concurrency🔥 helping it be 🚀blazing fast🚀
4. result/options instead of exceptions allow for handling errors as soon as possible
5. the community is ✨welcoming✨, obviously

so all of those reasons easily position rust as the best choice for projects technically, objectively, even morally.

Key word: morally. what does that mean?

it means people who are obsessed with being morally correct are gonna flock to the language, and become its foot soldiers. normally it results in a latent culture where it gives them the "right" to be smug, obnoxious propaganda machines because, what technical recourse do you have?

after all, why be so wrong, when you can be so goddamn right?

yes, it doesn't appear all the time, but there is always a chance of this happening when the community interacts with others. what other language has both this kind of reach and can afford to be this smug?

this behavior underpins the attitude people have towards things that rust cannot support yet. "it's obsolete or not ready for prime time yet, you should trash it." "it cannot be secured, you should trash it."

are programming languages a fucking competition? use what works for the job, right? then why put your energy into demeaning others who improve themselves?

"you're just mad because it's true", yeah and also you are too fucking smug. i couldn't believe someone like that can get ahead in the world, but they often do. i just lack the charisma to make my smugness tolerable.

in fact, this entire culture is what made me rethink the way i talk about linux to non-users. because it had made me realize the linux community is exactly the same way, especially towards windows users. so at least i have rustaceans to thank for making me introspect.

i'm not sure where to put this, but i've heard someone responding to this white house statement along the lines of:

no one forgot about java, swift, ada, etc. as memory safe languages, it's just they suck

…which is exactly why the media forgot about them. again, most languages are memory-safe, but people think of only rust—it's like thinking of only C when talking about "real programs". incidentally steve klabnik wrote something about putting too much focus on "memory safety".

rust has a "brand" like it or not. not to be confused with how the rust foundation wants to control it, however.

it's what makes the hypeseeking crowd want to proudly advertise that it's "rust-based", "written in rust", etc. etc.
what are people saying about it? "it's so i know it's something i can work with" "it shows the capability of the language, especially if it's niche"

yeah, same. i can say my projects are "written in nim" because i want to show that:
1. nim can do this kinda thing
2. that programmers who know the language can contribute to or use parts of it in their own projects

but to the wider audience it means nothing. nim means nothing to them, at worst it's derogatory. as in, "lmao, written in discount python."

how about rust?

consider the 70% figure that's repeated to the point that it's a bit like a slur for Cniles. that's the implication that makes "written in rust" different than "written in python" or "written in nim". and some software advertises itself as written in rust in a way that imply that this alone automatically makes it safer than every other app.

it isn't a panacaea, but it's marketed as such. it's a cure to the illness that is programmers themselves.

it's heavier than even "written in go". what does that imply? that it's easy to contribute to? that it's built on proven technology? i'm not sure.

i am sure in due time, i will have to use it, and i will overcome its challenges. but this is something that has come up time and time again. and i kept getting fucking gaslit about this. i'm sick of it.

…but then again, sike, the "non-technical" gripes are actually technical gripes, so.

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