Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Imba – I have spent 7 years creating a programming language for the web

news.ycombinator.com

Post reply on HN
Print view View original

101–110 of 354 posts

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#101

Post by moron4hire »

jl2718 wrote: post #91

I read this and still have no idea what the ‘memoized DOM’ is. There is a broken link to ‘how it really works’. Apparently there is a huge speed-up over react. I don’t actually care about this; I’d rather know what the slow parts of browser DOM changes are, and how it gets around them. Forgive my ignorance if I’m missing something obvious; I am completely new to JavaScript, but so far have found react/vue/etc confusi…

I learned React to know what it was about and what people were talking about. I think a lot of people get the wrong idea about React. They say the virtual DOM is the most important feature, but I think it's actually the fact that it forces you to componentize your code. And it does this by making non-componentized code very painful to work with, so you have to componentize to be able to have any shot at getting React to work.

But if you already have the componentization mindset, I don't think React really adds anything. As you have said, managing raw DOM operations can be significantly faster. And because you have componentized your code, they are significantly easier to reason about.

The only problem is that working with a medium-sized smash of code is not as painful in vanilla JS as it is in React. So if you've grown your application over time, adding bits and bobs to it piecemeal, you're likely to end up with an application structure that is inherently difficult to manage. Then folks rewrite in React, get forced to componentize, and lo-and-behold, everything is much easier to manage.

At this point, whatever gets you there, gets you there, I guess. Personally, I make VR applications that run in the browser, so I coveteth performance.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#102

Post by cwizou »

dt2m wrote: post #31

Looks cool. I'm honestly curious as to why a lot of new web languages/frameworks are mixing logic and content in the same file again though. The distinction between HTML, JS and CSS always made perfect sense to me. Anyone care to enlighten me?

The pragmatic answer is that, for the the large companies usually behind those frameworks, they can have many independent teams that are working on split components, without marching on each other's toes.

But to me, there's a parallel to be made between both the newer trends of components and micro-services, and the old idea of Object Oriented Programming. In all cases, you get sold on the idea that everything should be cut down into tiny pieces.

Theoretically the separation of concerns has tons of merits, but in practice there are a lot of rough edges when those separate pieces have to interact with each others.

And the tradeoffs may not always be worth it when your project isn't on the scale of those large companies (it very rarely is).

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#103

Post by coding123 »

derangedHorse wrote: post #36
mstade wrote: post #23

This looks very cool, thanks for sharing! I took a cursory look at the docs and it looks like async/await is pretty much directly analogous to how it works in JS, with the difference that you don't need to mark functions as async in order to use the await keyword. Does this mean that if you use await in any function then any other function calling it will have to be refactored to add an await keyword, just like you h…

Asynchronous code can sometimes be difficult to write efficiently so having implicit awaits might help with avoiding accidentally made fire and forget calls. An interesting concept might be to explicitly call a function as asynchronous with a new keyword flipping the typical usage of ‘await’. I’d still advocate for the usage of ‘async’ in function signatures though as it helps when reasoning through an asynchronous c…

I think it would be awesome for Typescript to introduce sync functions. So think of that as completely flipping the dialog on async/await to await by default:

    sync function x() {
        const taco = getTaco() // getTaco returns Promise, but taco automatically resolves it in a sync function
        // Similarly, you can tell it to not wait
        const ptaco = nowait getTaco();
        // ptaco is a Promise
        const taco2 = ptaco; // taco2 is a Taco because the ptaco symbol is treated like (await ptaco) without nowait
        // Also, since ptaco has already "awaited", future
        // access would be 0 delay as it's basically a resolved promise.
    }
Of course, similar to an async function, sync functions would also return a promise.

Probably a dumb idea but I would use it personally.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#104

Post by 49531 »

jl2718 wrote: post #91

I read this and still have no idea what the ‘memoized DOM’ is. There is a broken link to ‘how it really works’. Apparently there is a huge speed-up over react. I don’t actually care about this; I’d rather know what the slow parts of browser DOM changes are, and how it gets around them. Forgive my ignorance if I’m missing something obvious; I am completely new to JavaScript, but so far have found react/vue/etc confusi…

Most frontend frameworks are not created to solve performance of vanilla web applications, but rather to make engineering larger and complex applications easier.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#105

Post by k__ »

savmat wrote: post #74

I’m sick of programming languages that use “fast typing” and “productiveness” as a selling point. There’s no selling point in being productive doing a counter in a few seconds, production scenarios are far more complex and very often all those new programming languages fall short to their promise. Btw I don’t want to be fast or productive, I want to write code that works decently and is great for other humans myself…

I don't see the value in being able to "type fast".

I see it in less visual clutter.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#106

Post by [deleted] »

lowercased wrote: post #76
somebee wrote: post #71

Earlier quoted context omitted.

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 fr…

Flawed in what sense? I don't doubt that there are some conceptual drawbacks, and this only benchmarked chrome, not other browsers. I do think there's some utility in relative comparisons that have a standard/fixed baseline, as it would still seem to show what overhead a framework/library brings to the table. FWIW, my initial impression of imba is that it's very impressive. I do think you rightly point out that, at t…

[deleted]

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#107

Post by codesections »

lowercased wrote: post #68
yewenjie wrote: post #58

Quick question - how does the memoized DOM compare with no-virtual-dom-at-all approach of something like Svelte?

https://krausest.github.io/js-framework-benchmark/2020/table... This lets you choose from multiple frameworks - comparing svelte against a few react variations, what I saw was that svelte was always fastest, but usually by a factor less than 2 (any react was 1.x times slower than the svelte). The imba vs react numbers (from the article at https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me... ) shows a 30-40…

This is a very misleading way to report those results (likely unintentionally). The JS Framework site includes benchmarks for imba-v1.5.2 and svelte-v3.29.4 and reports that they are equally fast (1.04 and 1.05). It shows both as similarly faster than React.

As described in your second link, that benchmark is timing something a bit different – and we don't know how well Svelte would perform on it (I'm guessing fairly similarly, since the overall approach seems similar. But there's no way to know without measuring.)

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#108

Post by dalmo3 »

TekMol wrote: post #86
jt2190 wrote: post #81

Earlier quoted context omitted.

> ... [W]hy [are] a lot of new web languages/frameworks are mixing logic and content in the same file again...? In olden days, the DOM was treated like something shared. This could lead to a single DOM elements receiving changes from all over the place: Multiple CSS selectors would include it and apply style rules, and multiple JavaScript scripts might select and manipulate it. Spitting the CSS/HTML/JavaScript into m…

If you isolate the DOM elements from each other, then how do they share common styles? You certainly do not want to define the font type for each DOM element individually, do you?

The development is isolated, but the components are still placed somewhere in the dom, so regular hierarchy/specificity rules apply.

Granted, some UI frameworks do add a lot of redundant code to maximise component independence, then offer JS-based or class-based theming to keep development DRY.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#109

Post by sidlls »

49531 wrote: post #104
jl2718 wrote: post #91

I read this and still have no idea what the ‘memoized DOM’ is. There is a broken link to ‘how it really works’. Apparently there is a huge speed-up over react. I don’t actually care about this; I’d rather know what the slow parts of browser DOM changes are, and how it gets around them. Forgive my ignorance if I’m missing something obvious; I am completely new to JavaScript, but so far have found react/vue/etc confusi…

Most frontend frameworks are not created to solve performance of vanilla web applications, but rather to make engineering larger and complex applications easier.

Your comment reminds of the Facebook blog complaining that Apple couldn't handle their app's scale, and that's why it was so slow.

Most "larger and complex [frontend/client] applications" don't need to be as large and complex. By "most" I mean "almost all." In fact, I can't think of a single web application or mobile app I've used that can justify all the terribly complex garbage that goes into many of them.

Re: Show HN: Imba – I have spent 7 years creating a programming language for the web

#110

Post by codesections »

somebee wrote: post #71
lowercased wrote: post #68

Earlier quoted context omitted.

https://krausest.github.io/js-framework-benchmark/2020/table... This lets you choose from multiple frameworks - comparing svelte against a few react variations, what I saw was that svelte was always fastest, but usually by a factor less than 2 (any react was 1.x times slower than the svelte). The imba vs react numbers (from the article at https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me... ) shows a 30-40…

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 fr…

Setting aside performance comparisons, how does Imba's approach compare to Svelte's from a design perspective? From your Meet the Memoized DOM article, I take it that Imba is basically converting declarative code into imperative code that mutates the DOM – on first glance, that sounds very similar to Svelte's compiler-driven approach.

Are the two strategies as similar as they sound, or am I misunderstanding something?

Post reply on HN