guntis_dev

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"));

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.

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.

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.

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.

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,
    }
  }

Like the simplicity approach - single-file tools are underrated.

One thing to note: if you ever want "install as app" functionality, you'd need to host them (even on GitHub Pages). File:// URLs don't support service workers, which means:

- Can't properly "Add to Home Screen" as a PWA

- Can't use Cache API for offline-first functionality

- Limited to localStorage (~5MB) instead of IndexedDB

- CORS restrictions prevent fetching from external APIs/CDNs

But if your tools work fine with localStorage and file:// access, no need to overcomplicate. The current approach is valid too.