<purr>
<locks> paws = portal the programming language
eligrey has quit [Quit: Leaving]
fujisan has joined #elliottcable
Navarr has joined #elliottcable
Hrorek has quit [Ping timeout: 244 seconds]
Hrorek has joined #elliottcable
fujisan has quit [Quit: Connection closed for inactivity]
<purr>
<whitequark> plastic food is awesome.
alexgordon has joined #elliottcable
Hrorek has quit [Ping timeout: 240 seconds]
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
fujisan has joined #elliottcable
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
fujisan has quit [Quit: Connection closed for inactivity]
<purr>
<alexgordon> I'm impressive!
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
alexgordon has joined #elliottcable
alexgordon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
eligrey has joined #elliottcable
<ELLIOTTCABLE>
fucking purr
<ELLIOTTCABLE>
fixing this RIGHT NOW.
* ELLIOTTCABLE
glowers
alexgordon has joined #elliottcable
<ELLIOTTCABLE>
alexgordon, love
<ELLIOTTCABLE>
speak to me speak to me speak to me
<alexgordon>
hello elly
<ELLIOTTCABLE>
<3
<ELLIOTTCABLE>
how is life
<ELLIOTTCABLE>
-didja @ alexgordon
<purr>
alexgordon: didja write a paws yet? didja? didja!?
<alexgordon>
noja
<alexgordon>
I did not write a paws yet
<ELLIOTTCABLE>
-noja
<ELLIOTTCABLE>
brb fixing purr fuck this shit
<ELLIOTTCABLE>
also fuck Twitter so hard
<ELLIOTTCABLE>
Day Ruined™ -_-
<ljharb>
?
sigfig has joined #elliottcable
<ELLIOTTCABLE>
ljharb: → twitter.com/@ELLIOTTCABLE read the last few reply-threads for yourself.
<sigfig>
hello friend
<ELLIOTTCABLE>
but also just don't, it's not healthy and I love you <3
<ELLIOTTCABLE>
o7!
<ELLIOTTCABLE>
oh, wow, is it your first time in here
<sigfig>
probably
<sigfig>
i hardly ever check into irc
<ELLIOTTCABLE>
lol welcome （ ゜ρ゜)ノ
<purr>
lolol
<ELLIOTTCABLE>
give me a sec though, I'm fixing a thing in this goddamn bot before he makes me cry
<ELLIOTTCABLE>
sigfig: So, I hear this argument a lot:
<ELLIOTTCABLE>
Something like your ‘There's nothing to justify this size!’
<ELLIOTTCABLE>
and/or something else you also said earlier, ‘So much of this code does nothing!’
<ELLIOTTCABLE>
Like … I mean … well, I definitely haven't examined every byte of code shipped by Twitter, personally, but, it really doesn't stand to reason that the majority, or even *much of it at all*, Does Nothing?
<ELLIOTTCABLE>
It may do something *unimportant to you*, and that I'd buy - saying something like “Most products on the web are bloated”, that seems like a reasonable argument (even if *I'd* posit that it's out-of-touch with the state of the web, I guess, but ... again: different argument)
<sigfig>
my frustration with js is not that i end up with 2mb of nops
<ELLIOTTCABLE>
but specifically claiming that the *code* is bloated, in the absence of the product being bloated (i.e. “This product could exist precisely as it does, and service precisely the users it does in precisely the way the engineers creating it want to, with 95% less code”) seems … Very Unlikely.
<sigfig>
ok give me a bit to fully explain this
* ELLIOTTCABLE
nods
<sigfig>
so i'm working on a site now right
<sigfig>
(i'm doing a wc sum rn lol)
<purr>
lol
<sigfig>
the total source code for the site is 490 lines of cljs
<sigfig>
it is currently 1.7mb large
<sigfig>
there are a number of things that contribute to that size bloat
<sigfig>
the biggest causes are the react dependency and some poorly architected cljs libraries
<sigfig>
react, i think, was a bad choice for this project mostly for this reason
<sigfig>
it is a library that does a lot, it almost fully abstracts over the dom, and i'm not using hardly any of its features
<sigfig>
i'm just asking it to render a couple times. i could have done that with my own template system and spared myself like 400kb of oop framework
<sigfig>
cljs dependencies, also, are too big for what i could possibly need them to do
<ELLIOTTCABLE>
oh, remind me to wax nauseous on language-choice, too. curious what you think / how you'll respond.
<sigfig>
the json serializer is the actually, somehow, the biggest dependency
<sigfig>
the most popular one (in cljs, that means the only one you can actually use) is written with its own v special snowflake serialization spec and written in common clj
<sigfig>
the goog closure pass on it optimizes almost nothing because the way its written
<sigfig>
this is largely true of most cljs libs, because the optimization pass happens unaware of the language itself it doesn't really work
Navarr has quit [Quit: Connection closed for inactivity]
<ELLIOTTCABLE>
hold on a sec, there's an interesting observation here
<sigfig>
so i have this 1.7mb project, and all i can think when i look at its size is, i did not want this, this only happened because i dared to use a library
<ELLIOTTCABLE>
which has been lurking under my argument the whole time, but I've avoided stating explicitly ...
<ELLIOTTCABLE>
but basically, a lot of the time, the arguments for “You don't need 2,000 kb of JS!” is basically “You could *write* this in 20kb!”
<ELLIOTTCABLE>
but ... development time is money. What if <product> *couldn't exist*, economically, if the developer-time to manually write all that shit is exponentially higher than the time working in some admittedly-hugely-bloated framework?
<sigfig>
in my case it would have been a lot faster to just write it myself
<ELLIOTTCABLE>
I mean, basically, given that ... instead of arguing against bloat, you're ending up arguing against ... a current lack of tooling, I guess? The need for better tree-shakers (a term I'm quickly coming to hate, but w/e :P), HTTP2, etcetcetc.
<ELLIOTTCABLE>
you know?
<sigfig>
i can understand why large page sizes happen in business environments but i don't think that _excuses_ it
<sigfig>
if your development strategy and dependencies routinely produces software big enough to cause users problems you should not continue doing that
<ELLIOTTCABLE>
See, I agree strongly from an accessibility perspective:
<ELLIOTTCABLE>
<snip> that entire reply, tbh.
<ELLIOTTCABLE>
I just return to the fact that I must have stated my point Very Fucking Badly. I dunno, I feel like I conveyed what I was trying to say as well as I could have, but nobody seems to be understanding it, save rabcyr;
<ELLIOTTCABLE>
Another attempt to phrase it really simply: This seems like Linux Crowd™ trying to appropriate third-world users' concerns so that they can change a background colour or browse Twitter from the command-line? /=
<sigfig>
i am not sure that concern is meaningful in any way
<ELLIOTTCABLE>
If I were building a business (I'm not. This is all philosophical. Hell, to be honest, I've been out-of-touch with the web for *years*. ¯\_(ツ)_/¯), though, my solutions to “My product is inaccessible to people with slow Internet connections” might not satisfy users who want to be able to browse my site with NoScript, or AdBlock, or who want to use
<ELLIOTTCABLE>
custom CSS, or … whatever; does that make sense?
<ELLIOTTCABLE>
And casting this as a combined problem that equally affects both those groups, as if they're equally-largely-sized groups, will preclude *real solutions* to the group that deserves to be addressed, if those solutions don't also satisfy the ‘customizability’ hangers-on.
<sigfig>
noscript and adblock are employed mostly for accessibility reasons
<sigfig>
well, there is a lot of moralizing adblock but it does cut down bandwidth use _a ton_
* ELLIOTTCABLE
nods
<ELLIOTTCABLE>
even *I* use whatever-it-is on newer iOSes to speed up sites.
<sigfig>
noscript is also a useful tool for nonstandard browsers
<sigfig>
js is not a safe language and if your browser does not effectively sandbox it u have a bad time
<sigfig>
i've seen production js code heap spray itself its crazy
<ELLIOTTCABLE>
heap-spray?
<ELLIOTTCABLE>
*whoosh motion*
<sigfig>
copy code into a bunch of places in to the heap, usually in an attempt to grab pc
<ELLIOTTCABLE>
*production*?
<sigfig>
a js closure in the wrong loop iteration at the wrong time can end up all over the heap
<ELLIOTTCABLE>
not, like, an intentional exploit?
<sigfig>
this was an accident yeah
<sigfig>
i never debugged why the closure was copied instead of just spamming the pointer to it, but i dont get paid for this idc
<sigfig>
never look into the heart of javascript if you don't have to
<ELLIOTTCABLE>
Heart of JavaScript
<sigfig>
but ok, back to main thread
<sigfig>
the libraries being too big is a problem
<sigfig>
the lack of an actually useful optimizing compiler for js is a huge contributor to that
<sigfig>
but even still it should not be the case that all popular libraries are 300kb or more
<sigfig>
what happened to the microframeworks fad? that actually made sense for js
<sigfig>
did the lack of module systems kill it
<sigfig>
if i could get the event abstraction parts of react as a separate lib i'd be a lot happier
<ELLIOTTCABLE>
oh wow sorry, I tabbed away
<ELLIOTTCABLE>
sigfig: so, this is the kind of thing that are basically Only A Problem™ because of weird technical issues that shouldn't exist, and only do because of technical debt, as far as I can see it.
<ELLIOTTCABLE>
As I just spent like half an hour typing up in tiny tweets to @eevee, and then deleted because Just Not Worth It™,
<sigfig>
yeah, but, that's the entire web
<sigfig>
as long as it continues to suck this much i feel confident complaining about it
<ELLIOTTCABLE>
hold on
<ELLIOTTCABLE>
*RIGHT NOW*, this is a direct clash between developer-tool-choice and user-desires.
<ELLIOTTCABLE>
like, there's stuff emerging, HTTP2, ‘tree-shaking’ being built into tools, pseudo-micro-macroframeworks (ugh kill me words ugh kill me) like lodash's selectable-components crap … that will make all of this a non-issue
<ELLIOTTCABLE>
but for the last few years, and right now, exactly what you described happening to you, is what is happening to these big companies (and smaller companies … and other individuals like you and me …):
<sigfig>
what on earth is http2 going to do to spare me the pain of js
<ELLIOTTCABLE>
o_O
<ELLIOTTCABLE>
do you ... write a lot of JS? I mean, you ask why ‘microframeworks’ died ... that's why.
<sigfig>
i debug a lot of js
<sigfig>
i write very little
<ELLIOTTCABLE>
all of the bundling mess and pre-compiling and shit: devs really, really, really hate doing it. It's so much easier to just grab a giant all-included macroframework, and have the tool you want be at your fingertips when you want to run it. ¯\_(ツ)_/¯
<sigfig>
i would imagine the only thing that can revive microframeworks is es6 module support in browsers
<ELLIOTTCABLE>
it's kinda a widely-known-thing that the serverside npm approach of “tiny single-purpose modules” is going to explode all over the client-side, despite having failed the last time that was kinda attempted, once it's easy to do so *without complicated pre-bundling steps*
<ELLIOTTCABLE>
where you can literally require(tiny-lodash-function) in a simple JS file *when you need it* (well, idk, `import from` or wtfever.), and it gets piped over a live HTTP connection without the overhead of a new one
<sigfig>
oh thats neat, i didnt know a connection pool for js was part of http2
<ELLIOTTCABLE>
I mean, it's not? we must be talking across eachother here
<ELLIOTTCABLE>
HTTP2 is, as I understand it, a huge part of the reason the ‘Loader’ shit for ES2016 matters: Very Soon™, instead of require(bundle.js), you'll have `import {blah} from widget`, and you can do that *only* on the pages that actually use widget, without those pages opening fifty HTTP connections for the fifty things they may use that other pages
<ELLIOTTCABLE>
may-not-use
<ELLIOTTCABLE>
ljharb: ↑ i be in ur wheelhouse
<ELLIOTTCABLE>
idk I don't care too much about this stuff: but, point is, I've heard “HTTP connection overhead” and “precompilation being a mess” as the reasons that monolithic JS tools are The Reasonable Path right now; and it seems pretty obvious to me that it follows that 2MB-of-JS sites are The Reasonable Path right now
<ELLIOTTCABLE>
and I'm *not* arguing, to repeat, that that *isn't* directly at odds with some serious accessibility concerns.
<sigfig>
then why mock people who suggests the large sizes are bad?
<ELLIOTTCABLE>
but when the Linuxeers come around and complain ‘Ugh it'd be so easy for you guys to write ur own solution in 5kb …’, well … no? it'd actually be significantly harder? and sure, maybe I *will* do so, because accessibility is important to me ... but I'm going to do it for people who *can't afford* faster internet, and whom I care about for social
<ELLIOTTCABLE>
reasons; or for a chunk of my userbase visiting over LTE … I'm *not* going to do it because some user was upset that my site wasn't customizable enough for them, or didn't support their favourite arcane way of browsing the web. /=
<sigfig>
that is understandable
<ELLIOTTCABLE>
Another way to rephrase *all* of the above:
<ELLIOTTCABLE>
I feel *morally bad* if economic (not just money, but side-project time, or wtfever.) concerns prevent me from making My Thing™ accessible to some marginalized user.
<ELLIOTTCABLE>
(and I thus lose them as a user)
<purr>
<incomprehensibly> gqbrielle: I mean the specific mountain goats song
<ELLIOTTCABLE>
I do *not* feel Morally Bad if you choose to use NoScript, or Obscure Browser 2.0, and my website doesn't work for you because I don't have the economic ability (again: money or side-project-time or pull-request-triage-spoons or wtfever) to cater to your tiny user-group, and I lose you as a user.
<ELLIOTTCABLE>
And I always feel Hella Skeeved Out when the latter group tries to attach themselves to the former group, simply because some of the technical considerations to cater to them *may be* the same (they don't know. they don't know my codebase, my userbase, my limitations or needs or concerns or economics) as the considerations that must be addressed for the
<ELLIOTTCABLE>
former group. /=
<ELLIOTTCABLE>
↑ that is what I was, apparently terribly, trying to get at with my tweets.
<sigfig>
i can understand that feeling but i am not sure how it is applicable to the thread that started this
<ELLIOTTCABLE>
Er.
<alva>
One thing I just don't understand tho, going back to that post, is why websites choose to display a bunch of shit before it's actually usable. I come across it all the time on my terrible home connection. I don't understand how ppl write these things.
<alva>
Why would you show a bunch of buttons that do nothing, and then later be like OK now let's make them work
<ELLIOTTCABLE>
alva: Ugh, yeah, that's like 50% of where eevee nails it hard.
<alva>
Just don't show them and maybe indicate that it's still loading.
<ELLIOTTCABLE>
The ‘web-app development is in a super homogenous, closed-in bubble right now’ thing strikes hom *so* *hard*
<ELLIOTTCABLE>
Goes back to the old quote: “If you want to build fast apps, use a slow phone.”
<ELLIOTTCABLE>
here it translates to “If you want to build accessible websites, use a slow connection / slow computer / non-graphical browser …”, so on and so forth, but the sentiment remains the same
<ELLIOTTCABLE>
‘Chrome on Mac Pros’ though, I dunno about that.
<purr>
<drparse> sometimes things are too hard to parse because they're too complicated, simplify them and it's easy
<ELLIOTTCABLE>
I'm not sure where the disconnect is?
<ljharb>
yeah http2 is part of it
<ljharb>
also static dependency graph analysis
<sigfig>
well, the disconnect appears to be between me and this page
<ELLIOTTCABLE>
this is making me feel like holy crap I'm a terrible communicator. I feel like what I wrote above very closely mirrors what I tweeted originally; I just *can't see* the disconnect, somehow!
<ljharb>
ELLIOTTCABLE: fwiw i agree with you
<sigfig>
is dependency analysis on es6 any better
<ljharb>
ELLIOTTCABLE: noscript people aren't a problem. fuck them. the problem is the users that scenario *represents*, which you seem to sympathize with (along with me)
<ljharb>
sigfig: not yet. it will be once ES6 modules exist
<sigfig>
the web is too slow
<ELLIOTTCABLE>
ljharb: I mean, my entire argument was an attempt to say that without resorting to a hard ‘fuck you’, I guess.
<ljharb>
ELLIOTTCABLE: right. i def don't think you conveyed that well :-)
<ELLIOTTCABLE>
I wanted to phrase a similar sentiment but leave a window for people to explain to me Why They Matter if it's not an a11y issue?
<ljharb>
sigfig: it's not too slow for the elites. that's why "too slow" is a problem.
<ELLIOTTCABLE>
I feel “fuck ur disagreement w/ me” isn't very productive. I wanted something productive.
<ljharb>
oh totally
<ljharb>
ELLIOTTCABLE: but "noscript" isn't the people anybody was defending there
<sigfig>
ljharb: i meant, specification is too slow i want modules nooooooow
<alva>
Oh, I was just informed that my Sonic service is now active. Hope it's faster than AT&T. I often disable Wi-Fi on my phone when home because it's faster that way.
<ELLIOTTCABLE>
(clearly, I didn't achieve it: I made two enemies, one of whom I respect ridiculously highly, and the other of which is famous.)
<ljharb>
sigfig: lol oh
<purr>
lolol
<alva>
Maybe websites will work better now.
<ljharb>
sigfig: the JS spec progresses faster than almost anything else, fwiw
<sigfig>
that not true
<ljharb>
what moves faster?
<sigfig>
ghc language extensions
<alva>
Feels like even C++ has been faster lately.