somebee

We are finalizing an electron app as we speak. That will allow recording anything that runs on your own system

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...

Everything rerenders from the root of the editor (that is - not the syntax highlighting of the code itself - as that is handled by monaco).

The ltree extension is fantastic if you have data like comments or any other hierarchical structure.

The ltree extension (https://www.postgresql.org/docs/current/ltree.html) is perfect for this usecase.

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 :)

Sure, you can apply tailwind classes like `<div.w-32.h-32.rounded-full>` etc, but I'd definitely recommend using the built in styling as it is much more powerful (value interpolation, flexible modifiers etc).

You can definitely use 'just the language' part. I'm using it daily for scripting, and we've written a lot of apis and libraries at Scrimba that does not utilize any of the framework-ish features of the language. But to make the tags and styling work really well it (imho) has to be thought of at the language-level.

Tbh, var is actually deprecated since v1, so any mention of var in the docs is a mistake. Are there any other languages using 'con' for constants?

No, not right now. The current version of tags is relatively tightly coupled with the DOM for maximum performance. It should be possible to create a bridge like react-native but it hasn't been an area of focus thus far!

Relevant links for those who wish to look into it:

Repo: https://github.com/imba/imba

Docs: https://imba.io/language/introduction

Video: https://www.youtube.com/watch?v=8XS5q9xhaMc

Article: https://dev.to/somebee/imba-a-javascript-alternative-for-inc...

Site: https://imba.io

Discord: https://discord.gg/mkcbkRw

Twitter: https://twitter.com/imbajs

I'm Sindre, CTO at Scrimba (S20). We're about to launch a _major_ overhaul of Imba, the programming language we use for everything here (both frontend and backend). Imho the best frameworks are the ones that are extracted from real projects trying to solve real problems. Imba is like that, but at a language-level. It has been through countless iterations over the past 7 years, striving to be the perfect language for developing web applications.

We have added tons of cool things like touch modifiers (https://imba.io/events/touch-events), inline styles (https://imba.io/css/syntax), optional types and great tooling that integrates deeply with TypeScript. With this version we feel that we are very close to our vision for what Imba should be. In other words; it is finally ready for public consumption. I'd wholeheartedly advice you to look into it and give it a whirl if you are interested in web development :)

Check out this video (https://www.youtube.com/watch?v=8XS5q9xhaMc) building a counter in less than 1 minute.

- Compiles to Javascript, works with node + npm

- DOM tags & styles as first-class citizens

- Optional typing and deep TypeScript integration

- Blazing-fast dev/build tools based on esbuild

- Advanced tooling with refactoring++ across js,ts, and imba files

Yep - the scrimba site is using partial hydration heavily. Hope to get imba 2.0 final out in a few months :)

The veeery wip docs can be found at https://v2.imba.io :)

We do recommend using keyed elements (indexing using <tag@{mykey}> syntax) for large lists. It includes automatic pruning of cached unmounted elements etc if you reach a certain threshold of unique memoized nodes within a list over time).

It performs a lot better for a platform like scrimba at least - which is pretty dynamic.

I just hope other frameworks will adopt our approach, because it really is a huge step forward compared to most of what is out there today.

Please do! As I mention in the article, it's probably going to be a bumpy (but exciting) ride. We need to improve the documentation. The performance benefits are the real deal though :)