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

141–150 of 354 posts

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

#141

Post by sebular »

jl2718 wrote: post #112
moron4hire wrote: post #101

Earlier quoted context omitted.

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.

You're going to struggle as a novice if you're quick to form opinions about things that you don't fully understand, especially if those opinions involve rejecting wildly popular tools used by people with far more expertise than you have.

People who understand React/Vue/Angular are free to criticize them (and have many valid reasons for doing so), but when you do it after following a beginner tutorial or two, you're just being ignorant.

How do I know this? Because you're criticizing React for forcing you to "do everything through a JSX template" and "debugging through a transpiler", which tells me that you aren't aware that React can be used without JSX and without any transpiling.

Since that information is available to you on about the fourth paragraph of the "Getting Started" page on reactjs.org, you clearly haven't bothered to learn much about it at all.

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

#142

Post by arodyginc »

scns wrote: post #114
tiborsaas wrote: post #47

Earlier quoted context omitted.

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?

For their demo https://imba.io/ they put styles in a separate file, how so?

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

#145

Post by dtagames »

dmitriid wrote: post #52
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?

Separation only works for so-called leaf components: buttons, links, tabs etc. that can actually be reused. And even then you will definitely run into issues such as "in this particular case this particular tab will look like this". While the web was mostly leaf components (text, articles, images, links) this separation kinda worked. The moment you move into app territory, there are not that many things that are reus…

Very true. Even in "leaf" components (I'd never heard them called that. Cool.), the actual appearance is often dependent on some state that only the parent knows. Is the button highlighted or dimmed? Blue or red? Well, the button component doesn't know. (It shouldn't). But the parent who spawned it must know and pass that information into the button by a param.

This should, ideally, be as short and sweet as possible. In reality, like you say, the two ideas (visual + biz logic) will always be married in any non-trival application.

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

#146

Post by kingdomcome50 »

klibertp wrote: post #126
scns wrote: post #114

Earlier quoted context omitted.

And have to switch between three files back and forth?

What? How is that a problem, why would it be something that's best avoided, and why simply displaying all three files at once in one of a million ways available is not a solution?

I don’t see any added value of separating pieces of a component into different files. The CSS, JS, and HTML are all logically coupled no matter how you organize them.

At best you will achieved a few smaller files. At worst you make working within the system a real pain.

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

#147

Post by arodyginc »

So, had gone through samples and my conclusion as a seasoned web dev with projects as big as having thousands of files with hundreds business scenarios, imba is not the setup for this scale.

When people come and go, requirements change, new tools come along, trading flexibility to some initial development boost is not worth it, imo

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

#148

Post by dtagames »

q-rews wrote: post #40
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 distinction makes sense on documents but it starts to break on apps. Javascript depends on HTML and HTML is generated by JS.

Your concept is right but that wording isn't quite right. JS runs fine without HTML and thousands of lines in any web app don't even touch HTML. Node is HTML-free, for example. Also, of course, HTML, can be generated in a thousand ways and has no dependencies on JS.

I think what you were going for is the idea that, beyond a trivial application, the visual appearance stuff is always going to be tied to some app logic or business logic or state or whatever word we want to use.

And that's very true regardless of what framework or language we choose.

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

#149

Post by gregsadetsky »

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.

Very true!

One small note to the author: the “We are hiring” at the very top, on mobile, is a bit broken. It appears on three lines. It looks great in mobile landscape, but not in mobile portrait mode.

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

#150

Post by lowercased »

cxr wrote: post #117
lowercased wrote: post #76

Earlier quoted context omitted.

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

Not sure how you got from this that I was saying that there's no different between react and imba, or that it's not snappy/fast.

I was just saying that for the majority of LOB apps I'm working on, whether a table of 2000 entries renders in .2 seconds or .3 seconds has no meaningful impact on the client projects I'm working on. Even though it's a 50% slowdown, or 33% speed up, depending on how you measure, that speed difference has no impact on these projects. If we got up to 20000 entries, and we were hitting 2sec vs 3sec, that might be noticeable and something to address.

Post reply on HN