Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
typescript-imba-plugin
Discontinued Typescript Plugin for providing rich language functionality for Imba
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
typescript-eslint
:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript
I just want to compliment the OP on a very clear and comprehensive website at https://imba.io/. It clearly explains (by showing and telling) what Imba is, why I should care, how it works and how to get started. The floating demo applications even work well on mobile. Rare to see this level of polish for these things.
I think it has three reasons:
The more often a construct is used in a language, the shorter I like it to be.
It kinda groups variable definitions mentally by having them all the same length if they are "var", "let" and "con".
It would often make the code look more uniform which is more beautiful in my eyes. Example:
https://github.com/facebook/react/blob/cae635054e17a6f107a39...
I would prefer the lines 226 and 227 to start with "con" and "let". It would make the code visually more appealing to me.
Wow that's a very tight integration with JS&TS. Are you compiling into TS and then to JS? Or is it more of a seprate process for type-checking? When I was trying out ReasonML a few years back I ran into some problem with typings.
I checked out https://github.com/imba/typescript-imba-plugin for a bit and I'm still quite lost. Love to learn more!
Wow you are clearly a genius. The syntax looks beautiful! This is great. I don't want to use it (the best tool for the job for me is one that fits my own mental models, my own mind, and this is not it) but you are a genius.
Also -- wow those Nordics are super productive programmers/coders/developers/open-sorcerers (Sindre Aarsaether & Sindre Sorhus & Linus Torvalds & ......) -- could it maybe have something to do with: The low GNI, the high HDI and the great weather for coding? (cold, blistery, bleak, focused, electrons-and-light universe is only outlet in a desolate landscape)?
PS - I use my own memoized DOM with minimal/granular updates in my own quirky framework (https://github.com/i5ik/vanillaview)
CONGRATULATIONS, SIR!
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 :)
Really interesting project! I will definitely be trying it out today. One question—although you criticize some of the more common vdom benchmarks, I think it is still valuable to see where the dom updating strengths and weaknesses are in various approaches. Have you run any of the more standard frontend benchmarks on this and compared? I think it would be cool to see an entry for imba in the js-framework-benchmark table, especially considering your claim of low memory footprint.
https://github.com/krausest/js-framework-benchmark
Great work so far, I’m excited to give imba a spin.
Thanks for sharing, I really like projects like this. And the website is really informative.
I find it less of a new language and more of a JS preprocessor, removing lots of the cruft and integrating XML-tags and CSS in a very neat way.
What I miss:
1) I feel the web is shifting to more type checking. TS, Elm, Kotlin.js... I personally also prefer more typesafety, especially if the project grows in LOC/team size.
2) Compared to JSX, Imba does a much better job in integrating adjacent technologies. Though I much prefer these to be integrated in an eDSL fashion. For example how Elm does HTML templating (in Elm) or Kotlinx.html[1].
Just taste i guess. Good luck with yr project!
[1]: https://github.com/Kotlin/kotlinx.html
> Imba's Memoized DOM approach is an order of magnitude faster than Virtual DOMs (Vue, React). Learn more here: https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me...
Just in case...
Sciter's native built-in Reactor https://github.com/c-smile/sciter-js-sdk/tree/main/docs/md/r... is using that so called "Memoized DOM" approach, which as far as I understand the wording is "diffing with real DOM": you have real DOM tree on the left and virtual DOM tree on the right. Reconciliation in this case is just update the left tree from the right one.
Essentially Sciter's Reactor is a unification of React with WebComponents ideas into single entity.
You can cover this with eslint: https://github.com/typescript-eslint/typescript-eslint/blob/...
You could try using the https://github.com/phil294/coffeesense/ VSCode extension for that, released 7 days ago (disclaimer: I made it).
(being discussed here https://github.com/jashkenas/coffeescript/issues/5307)
I went through the same concerns and ended up building a little benchmarking tool for a simple reactive UI library I'm working on. It's not super user-friendly yet but doing a good job of profiling tasks.
You can write custom benchmarks by clearly separating pre-setup work than relying on ready-made benchmarks (a bit of a pain initially, but helps a lot to fine-tune at unit-level going forward).
It uses Chrome DevTools Protocol(CDP) through Puppeteer and allows to analyze execution durations separately (Scripting, Layout, Paint, etc).
Think it will be helpful: https://github.com/dumijay/pfreak