Any neurologist will tell you that your first night’s rest in a new location will be of a lower quality and depth than at your home. Despite knowing that, sleep studies are performed at the hospital in a room so uncomfortable that it makes the Holiday Inn feel like the Ritz. You’re then hooked up to a dozen different monitoring devices and asked to sleep in an uncomfortable bed with a camera observing your most vulnerable position. You should have no trouble falling asleep!

The second day is peppered with six attempts at napping within a short window, and if you enter REM within a threshold, you’re official diagnosed as narcoleptic. Otherwise you get a consolation prize of “idiopathic hypersomina” i.e. “sleepy person syndrome.” This methodology only selects for the most severe cases of narcolepsy, and as a result, allows insurance companies to gate-keep expensive medication.

I’ve read that a patient’s suspicion of narcolepsy and their final diagnosis is estimated around 8 to 15 years! IMO there is a subconscious characterization of known-unknown diseases as personal failing of the patient’s virtue. Convincing your parents, teachers, and doctors that you’re not just lazy is near impossible until the symptoms become too frequent to explain away. It also stands that doctors cannot be perceived as lacking critical information, therefore it is Not Allowed for their patients to be fatigued unless they’ve earned it, or put through the gauntlet that is our medical system.

Sadly there are many ways to experience negative social expectations at work. Several of my formerly heavy-set colleagues have observed the perception of their competence being a result of their weight loss. Most of the cis men I know use a combination of testosterone, Ozempic, hair plugs, lifts in their shoes, etc.

I don’t blame them; Perception is everything.

It’s quite bizarre at all levels — I often receive invitations from recruiters to apply to “women led startups”, but when I ask why I’m qualified there’s no real explanation other than I’m a woman who owns a computer. The same seems to be true of female founded startups. Doesn’t matter what the role is or what’s being built — Does she use a computer while in an office building? That’s women in tech! The purpose of most of these interviews is really about manufacturing consent: “It’s just too hard to hire women! Just look how hard we’ve tried!” I’m all for incentivizing under represented groups, but it wouldn’t be so bad if the phrase “women in tech” was short hand for “women who have written a lot code” and less about “brave women who uses their yonic powers to guide the brutish male code monkeys.” Attend a FAANG sponsored women centric event and you’ll see that I’m only exaggerating a little bit.

Ironically, my transition has been something like a rendition of Gift of the Magi: The more passable I became, the less experienced I was perceived by my peers. And worse, what was once thought of as confident display of technical ability is now seen as a lack of demure. Insecurity runs deep in this industry.

IMO the hiring problem isn’t about gender or race. It’s the fact that tech doesn’t have the luxury of an economic environment where all the money is imaginary. There’s really no era quite like the last two decades. Tech companies could burn through billions of dollars on intangible assets with no immediate need for deliverables. As the perception of innovation diminishes, companies feigned cutting edge leadership by leaning into the virtues, and as a byproduct, having the employees fight over who’s more oppressed.

I think everyone here has questioned if their skill set is actually worth their salary. “Sure, sometimes it’s a free ride, but those hard sprints are really why I’m paid six figures!” — It’s explanations like that which let software engineers hit the snooze bar on whether their employer’s solvency is transitive of their technical expertise, or rather just two decades of zero interest rate policies. It’s likely a little bit of the former and a lot more of the latter.

IMO most engineers are looking through the wrong end of the telescope, trying to find a job like the dating you do when you’re looking for a comfortable but uncommitted relationship. That time is over and our jobs are now akin to the blue collar trades who’s customers have a clear idea of what they’re paying you for, rather than a vague set of technical skills that might be worth exploring on their dime.

While I don’t have a write-up as detailed as this one, I spent a month on a similar journey optimizing an animated ASCII art rasterizer. What started as an excuse to learn more about browser performance became a deep dive into image processing, WebGL, and the intricacies of the Canvas API. I’m proud of the results but I’ve annotated the source for a greater mind to squeeze another 5 or 10 FPS out of the browser.

Maybe it’s time to brush up on those WebGL docs again…

- [1] https://asciify.sister.software/

- [2] https://github.com/sister-software/asciify/blob/main/Asciify...

Wanting to prove yourself isn’t a problem. It’s actually a sign that a developer is starting to form their own opinions. But it becomes toxic when the primary motivation comes from a desire to appear smart instead of actually solving a problem.

You’re absolutely right about typed classes and that’s how React Native does it. Writing and debugging CSS is hard for many of the same reasons that string-based templates exhibit. IMO the developers who push Tailwind are looking through the wrong end of the telescope. CSS is challenging because it’s a combination of declarative aesthetic UI and imperative state management. Choosing to represent that complexity with Tailwind guarantees what could have be a temporary ignorance into a more permanent crutch that retains the same faults of the underlying abstraction, tragically opting out of any of the benefits of embracing the system. Modern CSS is pretty great and learning how it works pays endless dividends.

I really wish these people would pick up a history book. Unlike back-end developers, whose worth is intrinsically recognized as necessary, front-end development was lowly micro-managed job that must simultaneously keep up with customer expectations in a variety of formats while also rendering whatever slop passes for a REST API. React’s adoption was a combination of talented marketing and a genuine empathy for the frustrations of a 2010s web developer. They gave us a white-lie to pitch the idea to our managers: “It’s just the ‘V’ in ‘MVC’!”

JSX freed us from the jQuery-Rails template spaghetti. A quiet revolution soon followed and everyone’s been butthurt ever since.

Look — Server-side templates, especially the “stringly” typed variety, are a demonic chimera suitable only for depraved alchemists. There’s no type-safety, no IDE references. You’re in Hokey Pokey Hell — we start with a string, now we’re interpolating, back again, now once more deeper and let’s really put your editor’s syntax highlighter to the test!

It’s no surprise that stringly typed tools like HTMX and Tailwind are so deeply admired by mid-career developers who are frustrated by their lack of experience and eager to prove their talent. That’s all very normal and healthy, but the problem isn’t that React is too complex. Building software as team is a complex task of communication, and pretending to be illiterate doesn’t make the hard words any less difficult to read.

There’s most definitely room for improvement in React, and the team at Svelte demonstrated that you could have your state and skip the boilerplate too. Svelte’s compiler is a genius move and unfortunately for them, React’s upcoming v19 will commodify their complement.

It’s never been about replacing React — it’s about empathizing with developers and making it easier to work together.

Comments URL: https://news.ycombinator.com/item?id=42143075

Points: 13

# Comments: 0

Can we get a bill going? I can’t decide between “Webmancer” and “www.izard.com”

>They reduced the code base size by 67% (21,500 LOC to 7200 LOC)

> They increased python code by 140% (500 LOC to 1200 LOC), a good thing if you prefer python to JS

Literally what? So they rewrote their app, which was most definitely in a state of affairs that warranted a refactor, and then concluded it must’ve been the limits of React. Oh, and rewrite the back-end too while we sing the virtues of this library claiming a lower technical investment.

Believe me, I’ve got plenty of gripes with React. It’s very easy to build the wrong things with it. And the ecosystem is an overgrown mess. But I’d still prefer a problem of technical curation over debugging a library which marries HTML and server-side templates with an untyped DOM runtime.

What could convince anyone to abandon the rich and bountiful lands of JSX and TypeScript? Who would prefer to move into a write-only and stringly typed HTML that competes with PHP for the slot of least performant debugging experience?

Maybe the answer is in the question…

Shameless plug, I’ve actually built the opposite of what the author has described. Asciify[1] is my very own highly efficient and over-engineered tool to generate animated text art. It started as an excuse to learn more about browser performance and just expanded out from there. I would love it if a greater mind could squeeze another 5 or 10 FPS on the spiral demo[2]. Maybe it’s time to brush up on those WebGL docs again…

- [1] https://asciify.sister.software/

- [2] https://asciify.sister.software/demo/spiral/

It’s assumed that if you want to support older browsers, the next logical step is to add Babel…forever. An incredible trick happens here, where the developer thinks they added the magic package which only bears a “tax” on the poor sap who’s stuck on Internet Explorer, presumably running eye watering amounts of polyfills on 32 bit limits of RAM.

In my opinion, the Babel team should start looking for a strategy that aligns with a world of evergreen browsers, and untangle the web of feature polyfills from syntax transformations.

It’s also not too wild to think that Babel is a symptom of a larger problem. JavaScript lacks a versioning mechanism when new features are added. A more self-aware Babel could use their connections with the TC39 team do what all successful JavaScript libraries do: become part of the standard library a la jQuery and CoffeeScript.

Alternatively, reconsider the velocity that Babel introduces to the JavaScript ecosystem. These tools might actually be self perpetuating their existence by making new features so readily accessible.

The Babel team has not shown a moment of interest in lowering their role in the JavaScript ecosystem to anything short of kingmakers. I think the facts are self-evident, but I can easily back up my claims by citing pretty much any document the team has ever produced. Have a gander at their GitHub README and what do we see?[1]

- “Babel is a compiler for writing next generation JavaScript.” I suppose they left out “indefinitely” to avoid the obvious. Don’t forget, you’re here forever.

- Over a dozen sponsor logos. An embarrassment of riches.

- A literal audio recording of a song in praise of the project. The call is coming from inside the house, people!

The Babel team has a well documented history of their priorities[2], emphasizing the need for a modular approach that has no exit strategy[3]. At best, we have a case of accidental entrenchment and long term dependence on Babel brewing as early as 2017![4] At worst, we have a group of aspiring Carmack-wannabes looking for their big break into the incestuous and lucrative class of technorati standards committees.

Don’t believe me? It doesn’t take an inner-join on the TC39 roster and the Babel maintainers to see our own version of regulatory capture forming right before our eyes.

Compare this infinite circus to the humble but popular Normalize.css, which has the express purpose to stop existing.[5]

If the Babel team wants to raise some money, they can start by putting a plan together that would codify an exit strategy. It’s certainly more noble than their current plan of barnacling onto every NPM package…

- [1] https://github.com/babel/babel

- [2] https://github.com/babel/notes

- [3] https://github.com/babel/notes/blob/master/2016/2016-07/july...

- [4] https://github.com/babel/notes/blob/master/2017/2017-04/apri...

- [5] https://nicolasgallagher.com/about-normalize-css/

Babel became Webpackified and splintered into poorly understood preset bundles of the latest revelations of the TC39. A fractal of API documentation could then be written and rewritten again for the next mission: Newer is better. Modularize everything. Maintenance is a virtue.

I’m guessing that the brain trust at Babel HQ saw how the left-pad situation panned out and something clicked — we could turn our discrete task into an indefinitely lucrative operation as a rent seeking dependency for everyone. Every week could be infrastructure week so long as JavaScript kept adding features.

But what their hubris didn’t factor in was a petard hoisting much higher on the food chain — the Chromification of the web. Now that everyone who’s anyone is building a browser on the same engine, there’s no need for a second cabal of feature creatures to get a cut of the action.

It’s the same reason Firefox’s Wikipedia page has to be disambiguated with the term “cuckhold”; the same reason core-js can’t ask for a dime without macro fiscal policy being invoked by armchair techno economists. Why are you running out of money? Simple — We already paid for it!

These projects have transmuted one kind of technical debt into another, and the sooner they’re gone, the better we’ll all be in their absence. I would pray for a cosmic force to come and topple Babel back to earth, but the irony would be lost on them.

Another tricky alternative is to just use TypeScript’s compiler. Combined with the new import maps spec, you can target most modern browsers and skip bundling all together.

Last year I was designing an animated cloudy sky with a sunset. I created a reusable pattern for each cloud type, and added groups for different speeds of movement to give the scene a parallax effect as they scrolled from one end to the other. This proved to be borderline impossible to animate smoothly when more than a dozen cloud paths were in motion. The only fix was to instead move the path translation code to CSS. An instant jump in performance.

The next issue was simulating how sunlight would move across the surface of the cloud patterns. Every single attempt to use an SVG filter or light source would have devastating effects on the frame rate. In my experience, the most powerful primitives of SVGs are not suitable for any task that combines their powers, and as far as I can tell, SVG lighting currently has no use beyond a proof of concept.

I ended up using CSS to get something close to a smooth frame rate. Ironically, reaching for something like Three.js might've saved me a lot of headaches. It’s funny to think that a 3rd party runtime library for WebGL would have a better performance than a universally understood DSL for vector graphics.

I’m sure the web is full of low hanging fruit like this. The hard part is figuring out how we can reaching through the thorns of backwards compatibility.

I would be delighted if handlers were more akin to byte arrays that could be written and read synchronously, albeit with an asynchronous function to persist changes to the disk.

IMO, the Chrome team is being a bit deceptive with their phrasing on synchronous file handles. The problem is that the entire API is wrapped up in an asynchronous ceremony. `createSyncAccessHandle` is only available in a worker context. So you can only communicate with the worker using an asynchronous postMesssage event dispatcher. And even when you’re in the worker, file handles can only be accessed through methods that return a promise.

I understand the need for such boundaries when working with a single threaded language, but limiting the synchronous APIs to just workers seems like one too many layers of indirection. I recently attempted to write a POSIX-style BusyBox library and this sort of thing was a total show stopper.

A picture’s worth a thousand ping…

https://thenerdstash.com/lan-party/