Hacker Newsnew | past | comments | ask | show | jobs | submit | burntcaramel's commentslogin

This prompted me to make a JavaScript syntax highlighter in WebAssembly that’s 99.9% in agreement with Shiki in 12.7 kb: https://qip.dev/syntax-highlight-comparison

I’ve been surprised how feasible static allocation has been. I thought it would be too restrictive and you’d be constantly hitting a wall. I’m writing WebAssembly in Zig/Odin/C and I’ve been able to have a linter reject the `memory.grow` wasm instruction and just use fixed-sized buffers in my code.

It me you think “ok, how big do I want the maximum image to be?” I’ve settled on 25 megapixels, which in the hundreds of megabytes. Since most images are much smaller, I believe on all mainstream hosts the memory isn’t paged in until it is first read/write so the memory footprint is much smaller.


From listening to Chris Lattner in interviews my guess it’s learning from when Swift became open source. The beta versions of Swift had massive language changes in how value types worked like with Array. Mojo is trying to get this language design locked down first, which is easier to do behind closed doors.

A compiler promising source stability is a different commitment than the compiler’s code being ready for outside contributors. Which is also different to having ABI stability, which took until 5.0 for Swift to achieve (I think Mojo does not have ABI stability as a goal as it doesn’t have to link to OS frameworks).


Massive language changes are easier to do without users. Whether the source code is visible to external people or not is completely irrelevant. I have a few programming language implementations on my GitHub and let me tell you, making manor breaking cha he's to those are easy as pie when I'm the only user.

If Mojo's goal was to make evolution easier, they would have a limited closed beta like what Jai does. But they're not doing that; they make the toolchain available to everyone, they just did this marketing push around releasing version 1.0 of their language. They're making it harder to make breaking changes by seeking users among the general public.

I have no idea why you started talking about outside contributors though, nobody's arguing that they should accept outside contributions. You do t have to do that. It's a completely orthogonal issue to what we're talking about, which is releasing the code under a FOSS license.


That doesn't really make sense, as being open source really has nothing to do with whether the language has an open evolution process. And if they've already declared 1.0, then they've already decided they're stable, so the original point doesn't apply any more.

I feel like they're going to remain closed until Qualcomm is convinced they can't make any money from it being so.


They didn’t follow their own advice for their accessibility practices page https://www.w3.org/TR/wai-aria-practices/


If you have a cancel button inside a form, you can point that button to another form dedicated to deleting with the form attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

I agree with some of this post but the argument feels muddled. "Clicking a logout button navigates the current page to a logged-out one" is wrong — it changes the state of the session, which is more than just a navigation. "Relative links can jump around the current page" — this _is_ a navigation.

I too weighed up the differences between a button and link and referenced the now sadly defunct WAI-ARIA Practices document which I found pretty clear: https://components.guide/accessibility-first/navigation


Even better, don't put it inside that form. If it isn't submit (or clear) the form then the button has no semantic business being parented by the form.


I love the line “This friction synchronizes people.”

Part of the understanding that is missed being learned by the team are the failure modes: how can this system fail and how catastrophic is it?

Now I fear only the users will learn via data loss, leaks, and hacks.


Yet another example where using <form method="post"> and <input> with zero JavaScript would be a better user experience. If you are going to write custom code you have to clear the minimum bar of what the browser provides.


Thanks for your honest thoughts. It bothers me because there’s many places to check all the time. It seems every tool has an inbox and wants to send me notifications about it. I have to read them all to keep up to date, and my job becomes piecing them all together into a cohesive story just to make sense of what’s going on at work.

It can feel super useful as an engineer to find a line of code in PR or a sentence in a Notion document, and then add your feedback directly there. But then I find the conversation half happens on Slack, and then continues in a Zoom meeting, and then the comment on the Notion doc is out of date. So I have to keep track of all of this in my head with which piece of feedback is stale and which one is still relevant, and then reconcile that with feedback from others.

It’s assumed that we need another tool, something that can do the job of retrieving all of these comments and reconciling them into a total order. My article asks whether reconciling decisions into a total order is actually part of the job of leadership. If we defer to AI to make sense of what we’re saying and deciding then we risk the people and the org becoming weaker from lack of clarity.


Basically this but for communications and knowledge tools: https://xkcd.com/927/


> if you can use AI to achieve full test coverage, are there actual benefits in static typing for coding agents?

Full test coverage doesn’t tell you if the tests behave correctly. So you could prompt an AI agent to write 100% test coverage where those tests could be exercising all code paths yet contribute 0% to the story of what the code does. You need human understanding of what the desired contract is that the tests check.

Imagine a contract lawyer who blindly signs any contract that they are given: they aren’t doing their job. They ought to have an idea in mind of what their client’s goals and limits are so they can determine if a given contract fulfils those needs.

Types are a declarative contract, so they can be a lighter yet more limited way to enforce a contract. The compiler can verify if all the declared types across the program agree with each other. This is especially helpful with refactoring, such as ensuring the adding a field has been rolled out everywhere.

Types aren’t to be just checked by the compiler, but checked by the human authors too. That’s why explicit type signatures are valuable, especially if they are kept intelligible. They encode the different variations in state and possible branching on that state. So you can whittle your types down as a way of whittling the solution down to be more focused. The problem in your head is reflected in the types, and any simplifications in the types then simplify the problem in your head, and any tests derived from that understanding.


I’ve found canvas + WebAssembly works great together!

Here’s an example of Sudoku running in WebAssembly (it was vibe coded in Zig) and then rendered to canvas. The interface between the wasm module and the browser is function calls for keyboard and mouse events, and then another that renders to a pixel buffer to copy to the canvas.

https://qip.dev/play-sudoku

And this approach also works for simple forms, such as a URL input that gets turned into a QR code. Again the interface is simple, here converted a URL into SVG markup. As you type in the input we call the WebAssembly render function again.

https://qip.dev/qr


The sudoku example has something massively wrong with it's performance. Latency is over a second per click and it halts after a few clicks.

The QR example works fine though


Thanks, I had shipped a bug in the event system. The performance should be much improved now.


Can confirm it's working now :)


Do you really think this "works great"?

I'm using a brand-new MacBook Pro with a high-end M5 processor, and this site is extremely unresponsive for me. Huge latency between clicking and getting feedback.

It also breaks accessibility.

The QR code use case seems far more reasonable to me, you're generating a static image.


It definitely wasn’t “working great”, I’ve now fixed a bug in the event system that was causing loops. The performance should be improved now.

Yes, accessibility is a key concern of mine, I’m keen to explore html-in-canvas as a way to have an accessibility tree combined with a rendered interaction.

I’m personally at a stage where React and CSS have pushed to DOM to extremes of complexity and difficultly in optimization that I desire simpler ARIA-based HTML combined with custom rendering. I’m hopeful that it will be easier to test, lighter for users, and faster for everyone.


Try a WebAssembly implementation of solitaire: https://solitaire.xaml.live/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: