Thanks! Let me know if you run into any issues or need additional codecs/formats.

I know this is a thing of taste, but have you considered a syntax closer to SolidJS's approach? Something that feels a bit more vanilla JavaScript, where signals are just tuples with getter/setter and you use JSX instead of template strings and components are just plain functions?

For comparison, here's how this example would look:

  import { render } from "solid-js/web";
  import { createSignal } from "solid-js";

  function Counter() {
    const [getCount, setCount] = createSignal(0);
    return <button onClick={() => setCount(getCount() + 1)}>{getCount()}</button>;
  }
  render(() => <Counter />, document.getElementById("app"));

I've worked with WebAssembly on several real world use cases

Codec support: Built video and audio decoding in Wasm to bring codec support to browsers that didn't have it natively. Also helped with a custom video player to work around HLS latency issues on Safari.

Code sharing: We had business logic written in C that needed to run both frontend and backend. Compiled it to Wasm for the frontend, which guaranteed identical behaviour across environments.

Obfuscation: Currently exploring Wasm for "hiding" some JavaScript logic by rewriting critical parts in Rust and compiling to Wasm. We tried JS obfuscators (including paid ones), but they killed performance. Wasm gives us both obfuscation and better performance.

To hide parts of JavaScript my best recommendation is to just not send the undesirable JavaScript to the browser in the first place. There are performance and security improvements to that which would be lost when trying to remove this same code after it does arrive to the browser.

That modification could be as simple as opening the concerned code file in your back end application as a large string and slicing out the parts you don't want. This will likely require some refactoring of the JavaScript code first to ensure the parts you wish to remove are islands whose absence won't break other things.

Without revealing too much, the business logic must remain client side for this use case, and it's a common problem across our industry.

I've explained the security reality to the business many times - any JavaScript sent to the client can be read, executed, proxied, or tampered with. That's just how browsers work.

The current directive is - make it as difficult to understand as reasonably possible. We're not trying to stop determined adversaries (that's impossible), but we can raise the bar high enough to deter script kiddies and casual attackers from easily abusing it.

are any of those codecs open source? A idea for a side project is browser based VLC (play any format). More ideally, a library that lets you play any old format in the browser.

For open implementations, look at ffmpeg.wasm - it's FFmpeg compiled to WebAssembly and supports a wide range of codecs. It's open source and actively maintained.

Some truly open/royalty-free codecs you could use - video: VP8, VP9, AV1. audio: Opus, Vorbis, FLAC.

That said, building a VLC in the browser gets complicated quickly because of licensing - even if the decoder implementation is open source, some codecs have patent licensing requirements depending on jurisdiction and use case. For example, H.264's basic patents have mostly expired, but I'd verify the specific profiles you need.

I've built orienteering training app for Garmin smart watches. Helps me to train in forest without physical orienteering prisms. https://apps.garmin.com/apps/92dfaa42-ebf3-45dc-88f2-ea81859...

Also it was interesting programming journey to use their Monkey C programming language.

A colleague of mine is developing an internal tool nobody needs in a large IT corporation. Since it's not client facing, there's no rush from project managers. It's dragged on so long that other internal tools have already implemented most of the needed functionality - so there's no good value proposition now. The only argument keeping it alive is sunk cost fallacy. Colleague works minimal required 3 day weeks, spends maybe 2 hours in the office drinking coffee, and tells me how he enjoys life with lots of hikes and outdoor activities.

Google search quality has declined significantly over the years. For many of my searches now, I can ask an LLM and get better results faster - especially for technical questions where I just need a direct answer.

Though I suspect this won't last once LLMs start inserting ads and promoted content into responses.

I imagined truman show / scenes from truman show where they show ads from your last line.

Spoiler alert if you haven't watched truman

But That is incredibly uncanny and I think this is the reason why, I think truman must have caught what's happening and also I saw this youtube video trying to explain that truman knew about the show the whole time and the scene and the time he was digging dirt in the first scenes of the movie, he was actually digging his escape route.

Source: https://www.youtube.com/watch?v=6mCXYfv-URg

I think there's a reason these wrappers keep appearing - different tools for different use cases. Not everyone needs to become an ffmpeg expert, especially if they only need it occasionally.

For example this one is also ffmpeg wrapper, https://lorem.video and built for devs and QAs who just need a quick placeholder video without diving into ffmpeg syntax. It's optimized for that narrow use case to generate test video by typing a URL.

Nothing wrong with learning ffmpeg properly if you use it regularly, but purpose built tools have their place too.

Last time I checked, Dart+Flutter on web renders everything to canvas, which means you lose browser fundamentals: native text selection, accessibility features, screen readers, right click context menus, inspectable DOM elements, and SEO. You also can't use browser dev tools to inspect the UI like you normally would.

The bundle sizes are also quite large compared to typical web frameworks, and you don't get progressive enhancement - it's all or nothing JavaScript.

Maybe things have improved in recent years, but I haven't seen much adoption or buzz around it.

Not exactly a bug, but I was given a company written video player that receives a video stream, decodes it via the browser WebCodecs API, and renders via WebGL. Users complained that video was laggy and often froze on their iPhones. My task was to make it perform better - using the browser's built-in player wasn't an option.

After profiling, I found two bottlenecks: converting frames to RGB was happening on the CPU and was quite costly, so I rendered the decoded YUV frames directly on the GPU without conversion. Second, I moved all logic off the main thread since our heavy UI was competing for the same resources.

The main thread thing was that I was iterating through the frame buffer multiple times per second to select the appropriate frame for rendering. When heavy UI animations occurred, the main thread would block, causing the iteration to complete late - by then, the target frame's timestamp had passed, so it would get skipped and only the next frame would be drawn, creating visible stuttering.

Quick question - would something like this cover the basic cancelable promise use case, or am I missing something important about what LazyPromise does differently?

  function cancelablePromise() {
    const promise = new Promise(resolve => setTimeout(resolve, 1000))
  
    let cancel: () => void
    const cancelPromise = new Promise((_, reject) => {
      cancel = () => reject("promise canceled")
    })
  
    const wrappedPromise = Promise.race([promise, cancelPromise])
  
    return {
      promise: wrappedPromise,
      cancel: cancel,
    }
  }

Yeah, I think this will cover the basic use-case, although the way I'd approach this is by starting with AbortSignal API and then maybe creating a wrapper around it. In a way `eager` and `lazy` functions from LazyPromise library are such wrappers.