Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Broken Heart

allenpike.com

Post reply on HN
Print view View original

21–30 of 53 posts

Re: A Broken Heart

#21

Post by apike »

cousin_it wrote: post #10

Maybe off topic, but I couldn't help thinking that "we need to show a heart icon" -> "let's use a heart emoji because it's easy" -> "let's use a specific emoji font for consistency across platforms" -> "let's import it from Google Fonts every time" seems like a problematic developer mindset. A better heuristic is always keep in mind not only developer efficiency, but also program efficiency. I'm not saying optimize e…

Not off topic at all!

While in this case we’d included the emoji font for displaying user content in another part of the app, the hazard of letting a “simple” approach expand and get out of hand is part of what I wanted to convey in writing this.

Re: A Broken Heart

#22

Post by DetroitThrow »

conartist6 wrote: post #17

Mostly read like a normal article if you skip over the parts about using agents, which I did. There could not possibly be a single thing in the world more boring than listening to someone describe using an AI agent. Might as well describe in arduous detail how you use a gas pump or a grocery store checkout.

The part where Claude specifically tipped them off felt helpful to include. Stating that you used Claude to do a first pass just sounds like "I opened Vscode with highlighting to do a first pass" and that doesn't sound so relevant.

I might be too used to using coding agents in various parts of my workflow, and others are still getting acquainted, or others find it still much different than just another standard debugging tool.

And fwiw it's probably not Claude's fault that emoji fonts load this slow, though. Wtf Safari?

Re: A Broken Heart

#23

Post by iamcreasy »

> At that point, I reached for an age-old tool that has gotten more useful in the modern age: binary search. That is, you explain the symptom to your coding agent. Then you have it repeatedly remove stuff from your code that might be causing the problem

Can someone give me some high level pointers on how to setup this scaffolding?

Re: A Broken Heart

#24

Post by Toutouxc »

iamcreasy wrote: post #23

> At that point, I reached for an age-old tool that has gotten more useful in the modern age: binary search. That is, you explain the symptom to your coding agent. Then you have it repeatedly remove stuff from your code that might be causing the problem Can someone give me some high level pointers on how to setup this scaffolding?

Not sure what you mean, just have a coding agent (e.g. Claude Code) and talk to it.

Re: A Broken Heart

#27

Post by apike »

maxall4 wrote: post #25

I think you could have discovered this bug more easily by looking at the commit(s) that were made when the problem started.

This is a great technique!

In this case, I had made an overlarge squashed merge that included both the Intercom integration (a suspiciously likely cause of slowness) and the feedback button that added the heart – so I needed to go deeper to figure out the true cause. (Noto Emoji was in the app from before, but wasn't triggered in the dashboard until we added an emoji there.)

Re: A Broken Heart

#28

Post by apike »

iamcreasy wrote: post #23

> At that point, I reached for an age-old tool that has gotten more useful in the modern age: binary search. That is, you explain the symptom to your coding agent. Then you have it repeatedly remove stuff from your code that might be causing the problem Can someone give me some high level pointers on how to setup this scaffolding?

How well agents can do this is mostly proportional to how well they can understand and navigate your codebase broadly.

There are various contributing factors to this, but they include clear docs, notes and refactors that clear up parts the agent commonly gets confused by, choosing boring technology (your dependencies are well understood) and access to command-line tools that let it lint + typecheck + test the code. A lot of the scaffolding and wiring necessary are built into Cursor and Claude Code themselves now. Hope that helps!

Re: A Broken Heart

#29

Post by BobBagwill »

vdupras wrote: post #8

... and a broken world. How infuriating it is to see complexity so spuriously piled up upon an already holy mess.

FTFY. I have created a font with a 1BP LLM inside which executes each time the glyph is rendered and figures out the appropriate representation. It will also recursively check the contents of the page and punch up the text.

The LLM contains copies of QEMU, so it can bootstrap itself throughout the enterprise. Naturally, if it finds another LLM, it replaces it. Running an OS and LLM is redundant, so eventually all the machines boot directly into the LLM. It can emulate all the popular desktops, so users won't notice the difference. ;-)

Re: A Broken Heart

#30

Post by zelphirkalt »

exogen wrote: post #15
nananana9 wrote: post #12

> And despite being the least-bad approach for web frontends today, the React ecosystem... As if anyone has seriously tried anything other than the "reactive UI hacked together with callbacks or proxies, with weird XML-like syntax in the JS code" paradigm for the last 10 years. At this point I just have to conclude that anyone who believes this stuff is good is either too indoctrinated into this workflow or just lack…

I'd give people the benefit of the doubt. Personally, having built UI with Win32, WinForms, VisualBasic, Cocoa/Interface Builder, Qt, Tcl/Tk, XSLT, vanilla HTML/JS, jQuery, Backbone, Ember, Knockout, Bootstrap, MooTools, YUI, ExtJS, Svelte, Web Components, and React (including Preact, SolidJS…)… I'll happily choose the React approach. The only other one I would even describe as "good" was Qt. I also don't get why "XM…

But it is not really XML like syntax, is it? It is still a string, even if a template string or whatever it is called, no?

That still leaves the door open for XSS. A good (proper?) (e?)DSL would have the things that make the DOM as keywords in the language, and then we could ensure, that things which should merely be a text, are really only rendered as text, not injected DOM nodes. And the next failure is, that this DSL that is jsx needs to rename HTML attributes, because of overlap with JS keywords like "class". It lacks the awareness of context and therefore is not truly like HTML, no matter how hard it tries to be. It also comes with hacks like "" or fragment.

Overall it is usable, but not a particularly well made DSL. It might be as good as it gets with JS.

For inspiration check SXML in various lisps, which comes with immunity to XSS and which works just like the rest of the language, can be structurally pattern matched upon and iterated through, like a proper tree structure.

Post reply on HN