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

111–120 of 354 posts

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

#111

Post by recursivedoubts »

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…

https://hyperscript.org

and its async transparency in particular:

https://hyperscript.org/docs/#async

hyperscript isn't a general, full-stack programming language though, it's focused on pure front end stuff, sort of a modern jQuery replacement.

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

#112

Post by jl2718 »

moron4hire wrote: post #101
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…

I like the components. I do not like having to do everything through a JSX template. I do not like debugging through a transpiler. I do not like testing a DOM tree I didn’t build.

Just my novice view.

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

#113

Post by krmmalik »

Interesting. I haven't watched the video get but I'm interested to know how is Imba for low-coders like me? React has a huge ecosystem around it and while it is not low-code, component libraries make adoption a bit more of a no-brainer so I'm interested from that perspective.

I've currently been working on a Blockchain app with a low-code back-end which is almost complete now and the front-end is supposed to be done in React but I'm open to alternatives.

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

#114

Post by scns »

tiborsaas wrote: post #47
resonious wrote: post #44

Earlier quoted context omitted.

Personally I've always been kind of confused by the common best practice of separating everything. React and Vue single file components made so much sense to me. I guess if I were to rationalize my position, I'd say it's because I have a hard time finding related things when they're separate. If a button or "a" tag have a special click handler, I want to know when looking at it. If it just has classes, then I don't k…

It's fine if you have a few colors, but with 50+ lines of SASS/component I'd rather have them separately. > I have a hard time finding related things when they're separate. Store them in the same directory? I agree on the events/business logic that they make sense to couple with the template code.

And have to switch between three files back and forth?

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

#115

Post by nsonha »

methyl wrote: post #79
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…

It depends. If your work is to create a new counter app every day to support some specific, single usecase, in other words you write a lot of simple apps and not a single complex one, then it’s definitely a win for productivity.

> create a new counter app every day to support some specific, single usecase

sounds like the kind of thing that programming was invented to eliminate

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

#116

Post by cies »

somebee wrote: post #3

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

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

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

#117

Post by cxr »

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…

> DOM/UI speed of the project's JS toolkit generally has not been any meaningful impact in the projects I've worked on in the last several years

Maybe you're the exception among your peers or something, but I'd wager you're wrong. Benchmark or no benchmark, imba.io and the site for Scrimba are way snappy. In contrast, when I find myself having to derp around on a landing page or a UI made with React or contemporary frameworks, I can feel the bloat. Is it possible that being elbow deep in this stuff has dulled your senses?

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

#118

Post by linux2647 »

nailer wrote: post #84
micheljansen wrote: post #46

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.

One piece of feedback: it took me a moment to work out what 'pt', 'o' and 'fs' were. Single character variables are fine for algorithms but for demos you really want to use actual words.

I’d agree If I’m using css daily I might know what these mean, but I only edit css once in a while, so most of these properties are lost on me

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

#120

Post by klibertp »

ollerac wrote: post #50
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?

It's because of components. Web app dev has started focusing on single, separate, reusable components instead of trying to design everything on the page at once. Often, in these components, the HTML, CSS, and JS is still separated, but now (theoretically) you can plug that component in anywhere (even a different app) and, as long as you feed it the right data, it should just work.

> It's because of components.

Replying to you because this is the shortest expression of this sentiment, expressed in many different comments:

No, it's not because of components. It's because of emulation of components by means of precompilation or JS execution. First-class components are available already, there's no reason to continue to emulate them, unless you need backward compatibility, or have another goal other than separating components.

It's also not about "components" in the meaning of "widgets" - reusable bits of content+view+behavior - because these can be trivially made with standard HTML + CSS + jQuery plugin. It was done since before the DHTML was a thing (hello !).

Instead, it's all about web apps, how they achieve responsiveness, and the fact that the more the framework knows about the content (including how it should look in all its states), the easier it is to optimize it consistently. I get that, it's ok for web apps, and it gets better the more nice syntax you throw at the problem (up to a point, as usual), because once you have enough of syntax extensions to replicate the important features of HTML and CSS, you can go absolutely nuts on the actually generated code and nobody would care.

On the other hand, using web app frameworks to write web pages is bad - do you really need to optimize for responsiveness if almost everything you see on the page has exactly one (or two, with hover) state? The same is probably true for languages designed for web apps: using them to write web pages can be tedious and more trouble than it's worth.

TLDR: it's because ~components~ web apps.

Post reply on HN