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

151–160 of 354 posts

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

#151

Post by Mavvie »

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.

With something like Svelte, I see no reason an editor couldn't let me choose if I want to see the JS/HTML/CSS in the single file (as it is on disk) or split it up into separate editor tabs for me.

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

#152

Post by masklinn »

mstade wrote: post #60
minxomat wrote: post #26

Earlier quoted context omitted.

That pretty much describes Lua.

Thanks for mentioning it, I don't know much about Lua. I found the language I was thinking of, it's called hyperscript. Here's an article about how async works in that language: https://hyperscript.org/posts/2021-04-06-aysnc-transparency-...

So… bog standard blocking interface, except it compiles to JS so it has to "surface" the async during the compilation process?

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

#153

Post by masklinn »

williamdclt wrote: post #89
mstade wrote: post #59

Earlier quoted context omitted.

This is exactly how I remember it working in the language I mention (which, by the way, is called hyperscript[1].) The semantics where flipped such that you'd explicitly mark calls or functions as async, rather than await, if you wanted them to run asynchronously. I run into subtle bugs all the time due to missing awaits, it's incredibly frustrating. [1]: https://hyperscript.org/posts/2021-04-06-aysnc-transparency-..…

> I run into subtle bugs all the time due to missing awaits, it's incredibly frustrating. If you use TS, ESLint's `no-floating-promises` rule (or the equivalent in other linters) is _such_ a requirement

That assumes all promise-generating code can be and is properly annotated, though.

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

#155

Post by lhorie »

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…

(Disclaimer: I'm the author of Mithril.js)

I looked at this a few years ago and IIRC, it refers to a very specific optimization for recycling DOM nodes in very specific cases. Recycling basically just means reusing pre-existing DOM subtrees instead of naively creating new ones. To my knowledge, Inferno.js and Mithril.js implemented a similar optimization but eventually dropped it because it was difficult to compute when the optimization could be applied and it wasn't worth the complexity (when using virtual dom anyways; my understanding is that imba doesn't do virtual dom)

I recall Imba always had quite nice perf numbers. Recycling DOM nodes did indeed give huge performance increases in synthetic proofs of concepts I did for Mithril.js. A good real world example where it's supposed to shine is tabular data: typically you'd key your rows to get good array diff performance, but this means paginating recreates the entire table from scratch every time. Recycling means reusing the existing DOM instead of re-incurring document.createElement call overheads for the entire table. Of course, in practice it's quite a bit more difficult to deal with edge cases (e.g. DOM state such as element focus)

The two things that I thought were problematic with Imba were a) lack of typing (which has since been addressed) and b) compiled output readability (i.e. it looks nothing like source code). It looks very nice otherwise, and it has come a long way since 7 years ago.

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

#156

Post by xrd »

The thing I'm looking for, and didn't see it immediately on the example page, is how easily you can use JavaScript libraries. I'm sure you can, but is it like Svelte, where you can just use them almost as-is, or like React and Vue, where you need to wrap them inside special wrapper libraries that expose them as React hooks or whatever.

Svelte is so great because you can use libraries as is. React is great (if you like it) in that it has a huge number of converted libraries and a huge community that is quick to convert new libraries.

Anyone know what the story is for Imba in this light? It looks great at first glance.

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

#157

Post by handrous »

49531 wrote: post #98
xutopia wrote: post #94

I don't get that push to put so much logic in the frontend. Connections are getting faster and if we load only smaller amounts of data in each request we can have a really great experience without the hassle of all this complexity.

A couple reasons I can think of: - The less logic you do on the client means more data required to be sent over the wire. - Connections are getting faster but we aren't at the point where they're negligible. For example, if I need to do complex form validation in real time I could send the form value to the backend, have it validate, and receive a response which introduces a lot potential of failure points. Alternati…

I distinctly recall using a vendor's demo in a no-nonsense show-me-the-money kind of industry, about 4 years back. It was something that would definitely have been built as a "web app" at most shops I've known since, oh, 2012 or 2013.

It was remarkably responsive, fast, and light. Everyone who used it commented on how snappy it was.

It was PHP, doing full-page reloads on damn near every interaction, with minimal Javascript.

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

#158

Post by ehnto »

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?

As others have mentioned, it's being used when writing components. Why does it work so well for components though, since you could just as well still separate the CSS? I think it's because of code co-location. Everything that describes how a component looks and functions lives in one file only. That's also why inline styles and utility libraries are palatable now, it's easier to reason about if it's described directly on the element, and you don't need to remember to update all usages of the inline style since it's a re-used component. It's even one step less indirection than using class names in that context, which is handy.

I also think most people are quite bad at organizing CSS, so I'm personally thankful for this change even though I love a well organized simple CSS/HTML site. It means less projects I inherit are rabbit warrens of legacy CSS to unravel.

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

#160

Post by sam0x17 »

cwizou wrote: post #102
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…

I agree. The real difficulty in software engineering is at the seams where systems or components have to interact with other systems/components. The more seams, the more difficulty.

The key though is that componentization is useful when you find yourself writing the same code over and over again. That's where DRY steps in and says yeah this should be its own component.

This is one reason monoliths are great as an app structure, because they let you be as DRY as possible and have as few seams as possible (making a component within a monolith doesn't create an external dependency, no seam). Additionally, there are options nowadays (ruby on jets for example) that let you have a monolith repo structure but each controller endpoint gets deployed as a separate lambda. So you get to have your cake and eat it too.

The analogy really does work fairly well at every level of software engineering, from frontend components to backend services.

Post reply on HN