Search is a really tough problem in OSM for a few reasons, but I think a lot it stems from bad address parsing.
I’ve been working on geocoder which uses a trained model to parse and classify address queries into a tokenized form. In addition to being more accurate than traditional rule-based parsing, this approach also gives the search engine more to work with beyond the tokenized boundaries of each word. The model also attaches provenance annotations to the address components, allowing the geocoder to have a better understanding of the geographic hierarchy of the components makes sense, rather than matching a string in a database.
The code is changing fast but you can try it out entirely in your browser here! Let me know if you’d like to see any specific features not on the roadmap :)
As a narcoleptic I wish that the diagnosis was more accurate, or at least that the insurance companies were more holistic in their coverage of medication. The multiple sleep latency test hardly qualifies as science and has a terrible false negative rate. It’s also expensive so insurance is reluctant to cover it in the first place, and outright hostile to a second attempt.
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.
Much appreciated. I’m US based, but I travel a lot for work. It’s a blessing to have a wider perspective on gender roles, especially with so much of the journey now in the rear view mirror. AFAIK there’s no lower rung on the corporate ladder than a sad partially-baked trans person. Hormones are cheap but a remote tech job with a decent salary can make a transition affordable without jeopardizing your career, socioeconomic trends withstanding.
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.
If it’s any consolation, I haven’t gotten any favors as a trans woman, even with “passing privilege.” Both myself and the cis women in tech I know all hear the same thing: companies are tipping the scales to favor diversity hires. But in truth it seems to be a marketing tactic rather than a hiring strategy.
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.
I really enjoyed the author's technical deep-dive and approach to debugging performance issues. Mild spoilers for anyone who hasn't played Riven, but the method for fixing Gehn's faulty linking books is a perfect analogy for the author's more counterintuitive performance optimizations.
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…
The gist is something like a new cohort of front-end developers and some begrudging back-end folks who never actually learned how anything worked are now trying to inscribe their influence as the new smart people with tools like Tailwind and HTMX.
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 hope that I’m not the only one who feels the anger emanating from these sort of blog posts. It’s stuff like the Qwik developers claiming things like “Hydration is pure overhead” as if it’s the mathematical proof that keeps their reality from crumbling. It’s the same thing on YouTube with people like Theo, gnashing their teeth at how Tailwind is incredible; You’re objectively stupid for not liking what I like; You’re using it wrong; You’re a not as smart as me; I drew you as the Soyjak and me as the Chad. Please won’t somebody tell me that I’m cutting edge?!
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.
As a web developer, I’d like to think that we’re effectively alchemists who transmute vague ideas into products held together with absurd magic that’s constantly changing.
Can we get a bill going? I can’t decide between “Webmancer” and “www.izard.com”
Respectfully, those metrics are not proxies for productivity. They don’t seem to be grounded in a statical model either:
>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.
I just don’t buy how this is a productive way to build websites. Having the functionality of HTMX natively supported would be nice but you’d still need much of what React does. HTMX’s docs seem to hand wave away front-end state management as something that no longer applies. Simultaneously, they also assume that every API you interact with will return HTML partials.
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?
Lookup a stenographer’s keyboard. There is a learning curve but a chorded keyboard can exceed typical typing speeds. I imagine a T9 isn’t too different in this regard.
This is very cool. I suspect the author encountered that 12 pixel offset due to a default value on the canvas’s text baseline property. Setting this to `top` may resolve the issue, or invoking the `measureText` method and calculating the offset from the output. A fixed value for a monospace font is pretty good too!
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…
That is a wonderful question and is exactly the sort of thing that should be on the Babel website. You’ll find no such explanation or even a summary of trade offs that come with adding Babel to your app.
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.
I do appreciate your transparency, though I disagree with the sentiment that I’m arguing from a position of bad faith.
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…
6to5…err, I mean Babel, Already accomplished it’s mission to bridge the feature gap between older browser implementations. And like all bureaucratic melanomas, the maintainers made a strange decision to not only expand their domain to ES7, but to ALL FUTURE VERSIONS OF JAVASCRIPT FOREVER.
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.
IMO, ESBuild is the best option these days. It’s not as magic or batteries included as Webpack, but there’s very little kept secret from you during the compilation process. It’s fast too!
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.
This is really incredible work. If you’ve ever tried some of the more esoteric SVG features like filters and animations, you’re bound to have a horror story or three to share. In almost every case, Safari’s SVG performance lags behind Chromium’s offerings.
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.
The file handler is already tucked inside an asynchronous Promise based API. I think it’s reasonable that a mere attempt to get a handler synchronously is made possible. Whether to support synchronous read/write access is another matter.
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.
This is honestly very cool. VS Code uses a similar approach to their local file system provider, albeit with a wrapper around IndexDB instead of SQLite. There’s some interesting trade offs too, since IndexDB can store the browser’s native file handlers in a flat map — so there’s no need for a schema.
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.
I’ve been working on geocoder which uses a trained model to parse and classify address queries into a tokenized form. In addition to being more accurate than traditional rule-based parsing, this approach also gives the search engine more to work with beyond the tokenized boundaries of each word. The model also attaches provenance annotations to the address components, allowing the geocoder to have a better understanding of the geographic hierarchy of the components makes sense, rather than matching a string in a database.
The code is changing fast but you can try it out entirely in your browser here! Let me know if you’d like to see any specific features not on the roadmap :)
https://mailwoman.sister.software/