Will try to push a fix in the next few hours. We are instantiating the monaco editor with a custom font (Source Code Pro) before we're sure the font has loaded, which throws of the char box measurements in monaco. We did have a fix for this in the old (non-backend IDE), so I'll port that over ASAP. Thanks for notifying us :)
Right now, only js is supported out of the box, but I guess any language that can run via web assembly or other techniques could work. WebContainers has experimental python support, but it won't work with a lot of the dependencies you would usually utilize in python etc.
In my experience the accuracy is at least a bit better than whisper-small on their enhanced models. But we've just started using it so haven't had time to do many direct comparisons with whisper. Their word-timestamps are _much_ better, which is important if you want to be able to edit the audio based on the transcription.
As for speed I have no idea how they make it so fast, but I'm sure they've written about it somewhere. My guess is at least that they are slicing the audio and parallelising it. Will look into Conformer-1 as well!
Did you try their enhanced models? We're using it for relatively high-quality audio files and their accuracy is better than the whisper small.en model. More importantly, their word level timestamps is worlds better than whisper.
We've been researching different speech models at Scrimba, and went for Whisper on our own infrastructure. A few days ago I stumbled onto Deepgram, which blows whisper out of the water in terms of speed and accuracy (we need high precision word level timestamps). I thought their claim of being 80x faster than whisper had to be hyperbole, but it turned out to be true for us. Would recommend checking it out for anyone who need performant speech-to-text.
Yes, I've also had this experience with React. I've created several imba apps with more complex UI than an average webstore and still rerender from root without even being close to spending 16ms on a full rerender. It does work. https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me...
Brilliant! We're well on our way to migrating. The experience has been buttery smooth so far. And the codebase itself is really well organized. Huge thumbs up!
What a coincidence seeing this on HN. Great lib! I actually experimented with replacing our use of node-postgres with this today. Your lib was the reason I finally got around to shipping support for tagged template literals in Imba today (https://github.com/imba/imba/commit/ae8c329d1bb72eec6720108d...) :) Are you open for a PR exposing the option to return rows as arrays? It's pretty crucial for queries joining multiple tables with duplicate column names.
I played through it myself and tbh I think the video doesn't do it justice. I haven't been this blown away in years. Until I got to take over the controls I was utterly convinced there had to be pre-rendered video thrown into the mix.
If you have a compatible console I'd really recommend checking it out!
Yeah, it's not really optimized for that. The floating labels over the code examples are offset in 3d space (for a subtle parallax effect while scrolling), so when HW acceleration is off it may end up repainting the page on every scroll. The effect is probably not worth the tradeoffs :)
I will try to add v2 to that benchmark relatively soon - it is a lot faster than v1 and has a much lower memory footprint and faster initial load time :) Should probably combine it with a few pull requests to the benchmark itself - as I consider it pretty flawed (see another comment here).
Tbh, I think the js-framework-benchmark is flawed. It mostly tests the performance of the browser. I should write a whole blog post about this. Just as an example, all the table benchmarks uses a table with non-fixed width, which results in a full repaint AND layout of the whole table+page whenever a cell changes. If you change the table to a fixed width (as all real tables are) the relative difference between the frameworks increase by a factor of 5 or more.
And when you benchmark the speed of creating 10000 dom elements in an instant, less than 5% of the time should really be spent inside the framework one is supposed to test.
I stand by my claim in the mentioned article that tiny changes to a larger dom tree is a far better indicator of real world performance than anything else. Here Imba is really orders of magnitudes faster than react.
The last time I tested it, Imba was more than 10x faster than Svelte as well, but I'm not proficient enough in Svelte to claim that as a fact, and I have tremendous respect for Rich Harris and everything he's done with Svelte and other libraries.
You can typeset variables, parameters etc (ie. see the code in https://dev.to/somebee/global-type-augmentations-with-automa...). But declaring standalone types is still done in `.d.ts` files. Imho, the type inference in ts/js is getting so good that I very rarely need to declare any explicit types in my own projects.
Yeah, the typescript-imba-plugin does quite a lot of magic and might be a little rough to get into.
We essentially do the type-checking by compiling the files to js with jsdoc annotations, and for some features we also generate `.d.ts` files (see https://dev.to/somebee/global-type-augmentations-with-automa...). There is still a lot of work to be done on the integration. There are bugs and missing featyres, and the type-checking only happens in the tooling atm. The compiler could not care less about your types.
Since it is developed as a ts language plugin, references to imba files (like goto definition etc) works from ts/js files (you can include imba files in js/ts), and renaming methods / files works across all ts/js/imba files in your project.
Yes, there are plans for an imba course on scrimba! It is almost comical, but scrimba was originally created with the sole purpose of teaching people Imba. Here we are, 4 years later, finally preparing to make a course :D
There is built-in type-checking, but currently only via the tooling. It integrates with TS as a language service plugin (https://github.com/Microsoft/TypeScript/wiki/Writing-a-Langu...) so you get great warnings/errors, type inference and much more. To define standalone types or interfaces you still need to use `.d.ts` files, but that may change in the future :)