No doubt the browsers are constantly leapfrogging each other, so this isn't always the case. But, anecdotally: switching from Chrome to Safari actually felt like I got a new computer. The difference was that apparent.
Safari is fast and performant but once you load a heavy web app that uses a lot of memory safari will kill the tab. It’s incredibly frustrating to have a page reload with a banner simply saying the site was using too much memory and was reloaded. Especially when you’re on a maxed out MacBook with plenty of resources.
I agree, in practice I see this occasionally on gigantic GitHub pull requests with 1000+ files, or very clunky Atlassian/Confluence pages. I'd say both sides need to work on their resource management!
(On that note, many complaints about Safari I hear from developers fall on my ears as "I don't care about web compatibility!" as it has never NOT been the case on the web that you need to care about feature support and resource management.)
I will also note that Safari is almost /too/ deeply integrated in the system, when I'm running a high-stress task elsewhere, my browser would jitter or hang, the same couldn't be said for chromium, for some reason.
A few years ago, I made a model skinner for Tribes 2, a ~25 year old game that still has a loyal following: https://exogen.github.io/t2-model-skinner/ (if you check out the Gallery link there, you'll notice this app resulted in a whole new wave of skins, and even a Halloween skin contest)
To satisfy the urge of doing something else ambitious in the browser, I'm now doing the same thing for Tribes 2 maps: trying to make a web-based map viewer and editor: https://exogen.github.io/t2-mapper/ (editing/creation part still in progress)
I got this working for most maps pretty quickly. It translates the mission object tree from the Torque .mis files into a Three.js scene graph. Eventually though, I noticed that some mission definitions were more dynamic – Torque .mis files are really just TorqueScript .cs files with a different extension and some pragma/magic comments. So, to actually handle every map would require not just a mission file parser, but a whole TorqueScript runtime. Implementing THAT part seemed really tedious and, frankly, uninteresting to me. So I had Claude Code get a whole TorqueScript transpiler and runtime working. Now, when you load a mission, it actually runs all the same scripts that Tribes 2 runs to load the mission, all the way from server.cs and its `CreateServer()` function.
Currently, I'm continuing to get its rendering matching Tribes 2 as closely as possible, and setting things up so that live editing of missions will work.
In today's world, yes. But as with a LOT of complaints about "web developers!!!!" the answer is usually "because of the way the web WAS."
Before IE became Edge (and maybe even in the earliest versions of Edge), there were certain styles and descendants that simply did not work on a <button> element, like Flexbox and Grid positioning. So, if your button had content like an icon, and you were trying to align it a certain way with the label, you simply couldn't use some features of CSS like you could with a <div>. It was a pain in the ass.
In the same vein, do you remember the period where some browsers wouldn't allow you to make a button look like a link using CSS, because they thought it might deceive people and thus be a security issue? I do.
And similarly when people complain about the complexities of webpack and bundlers in general, do you remember including the jQuery <script> tag on the page and then almost always needing to call `jQuery.noConflict()`? And how in those days, most people got even THAT wrong, because atomic <script async onload> behavior didn't work correctly in all browsers yet, so other code could actually run in between a <script> and its onload callback, meaning the jQuery.noConflict call was ineffective and something else could steal it? I remember. webpack fixed that by automatically scoping everything.
Nowadays, a lot of those workarounds are unnecessary (depends what browsers you're supporting). But it's not like there was never a reason for them.
A cool thing about a lot of the agency work I did early in my career is our audience was not actually the stated audience, it was the staff at the company that hired us. And one of the companies was on IE7. So yeah, I've nine-sliced a gif or two and done a few clearfixes in my time, haha. Never ran into a lot of these, but these weren't apps so much as brochures that happened to be online. Luckily enough we could control the environment pretty well to avoid actually needing noConflict() on jQuery.
But that was in 2011–'13 and things have gotten a bit easier since then and it's up to us to stay abreast of what's possible on the platform.
This is also how I build most of my static sites, usually deployed to GitHub Pages. For example, here’s the demo page for a library I recently developed: https://exogen.github.io/turbo-colormap/
Are all of Next.js’ features overkill for such sites? Sure, but the convenience such frameworks provide is worth it. And the reason to prefer it over something like Vite is simply routing, which Vite doesn’t cover out of the box, so as soon as I want to add a second page, I now have another problem to solve.
Next.js’ best feature is simply that you’re up and running with `npm i react react-dom next` and step two is just writing the pages.
Location: Seattle, WA
Remote: preferred
Willing to relocate: no
Technologies: TypeScript, Python, React, Next.js, Django, Postgres
Resume: upon request
Email: exogen@gmail.com
Your classic web and open source hacker with over 20 years of experience, most fluent in JS/TS and Python. I've tackled a wide variety of interesting problems and domains, e.g. graph isomorphism, query expansion, geocoding, dev tools, performance, data visualization, API design, server-side rendering, entity matching/record linkage, web scraping, games, reverse engineering binary formats, typography, codebase migrations, and more. Both startup and big-corp experience, but I prefer working with small teams.
Ask me about the time a stolen bike led to creating an arbitrary-precision math library and discovering a bug in Mathemetica...
`JSON.parse` actually does give you that option via the `reviver` parameter, which gives you access to the original string of digits (to pass to `BigInt` or the number type of your choosing) – so per this conversation fits the "good parser" criteria.
To be specific (if anyone was curious), you can force BigInt with something like this:
//MAX_SAFE_INTEGER is actually 9007199254740991 which is 16 digits
//you can instead check if exactly 16 and compare size one string digit at a time if absolute precision is desired.
const bigIntReviver = (key, value, context) => typeof value === 'number' && Math.floor(value) === value && context.source.length > 15 ? BigInt(context.source) : value
const jsonWithBigInt = x => JSON.parse(x, bigIntReviver)
Generally, I'd rather throw if a number is unexpectedly too big otherwise you will mess up the types throughout the system (the field may not be monomorphic) and will outright fail if you try to use math functions not available to BigInts.
Sorry yes, i was thinking of the context object with source parameter.
The issue it solves is a big one though, since without it the JSON.parse functionality cannot parse numbers that are larger than 64bit float numbers (f.ex. bigints).
A comment I made when I started noticing the magenta gradient at the end of the progress bar: it's a bit anxiety-inducing for those who remember needing to degauss their monitors, because it looks almost exactly like when you mess up a CRT with a magnet.
(Aside from that: not a fan, it makes the chrome of the video player more distracting.)
I know I sound silly and dumb for feeling so strongly about something so small, but the gradient really gets on my nerves. It is indeed so subtle as to make it feel like something is wrong with the display, but not subtle enough that I don't notice it _every time_.
Similarly, the "glow" they introduced a while back makes it feel like I'm getting the worlds worst backlight bleed.
Mercifully I use FreeTube to watch YouTube which saves me from these design choices.
That glow I think you're referring to is "theater mode" and fortunately it can be disabled on the gear menu. It's incredibly distracting, especially in Firefox it can sometimes be laggy.
I think you mean "ambient mode". Theater mode is like the halfway point between normal-size an fullscreen-size.
As an aside, does anyone know of any good YouTube settings extensions? I usually open YouTube in incognito tabs to avoid the personalization "features", but this means none of my preferences around ambient mode and "stable volume" are saved.
Oh, thankyou for finally naming it. I've had a vague sense of anxiety for months seeing that gradient - like something is wrong and I need to fix it somehow. I just had no idea why I felt that way until I read your comment just now.
It's more overwhelming than underwhelming. There are many more views now than just "photo grid" and "photo detail" and lots of annoying "smart" albums, which have more special treatments than just a grid of album photos. It feels unresponsive and I often get stuck in a view with no idea how to just get back to the camera roll. I often quit the app in frustration hoping it'll just get me back to my latest photos. Probably the most unnecessary update I've ever seen on iOS.
MusicBrainz is great! Every now and then I'll get an email notification that someone has updated an attribute on some obscure local band that I put on there.
ca. 2017 I undertook the considerable task of building a GraphQL interface to MusicBrainz, to support a side project of mine. This was a great experience for learning the breadth of MusicBrainz and how to design things with GraphQL. Sometimes I look at the documentation generated from the resulting schema and wonder when I ever had that much time: https://github.com/exogen/graphbrainz/blob/master/docs/types...
