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

171–180 of 354 posts

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

#171

Post by klibertp »

kingdomcome50 wrote: post #146
klibertp wrote: post #126

Earlier quoted context omitted.

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.

I don't see a difference between switching between files and switching between positions in a file which is longer than a page or two. In both cases the switching is not free - unless you do something about it (like spliting panes/windows in your editor; bonus: it works for both separate files and long files in the same way!). It's also trivial (well... depending on the IDE/editor I guess) to make it open all 3 files when any one of them is opened and/or to make a command to cycle between files, similarly to how you can switch between .c and .h files in most environments.

For files where the logic, structure, and styling fits on a single page - yeah, splitting it into separate files doesn't make much sense.

> At worst you make working within the system a real pain.

That's what I don't understand - what pain? That it's better not to work with it using nano or notepad? It simply looks like a pain I would never experience, and I'm wondering if I'm right.

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

#172

Post by greggturkington »

linux2647 wrote: post #118
nailer wrote: post #84

Earlier quoted context omitted.

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

I write CSS everyday and I had no idea what "fs" meant.

"fz" is the typical shorthand used for font-size (at least by Emmet-style autocompleters). "fs" is used for font-style instead.

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

#173

Post by dmitriid »

dtagames wrote: post #145
dmitriid wrote: post #52

Earlier quoted context omitted.

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

leaf components as a term appears in various discussions on web components. Many people don't see the value in full-blown web components(as they have lots and lots of unsolved issues), but agree that they may fill the niche/need for "dumb" reusable components at the end of the DOM tree (hence, leaf :) ): date pickers, buttons, links, all that kind of stuff.

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

#174

Post by lhorie »

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…

I have to echo somebee about that benchmark suite. It's fairly well known in the framework-bulding community that this is not a very good benchmark (just ask Boris Kaul of Ivy.js, Ryan Carniato of Solid.js, Leon Sorokin of domvm, etc etc).

Some "frameworks" achieve good numbers there by being utterly unusable in real life, others miss the spirit of the benchmark completely (e.g. submitting a non-keyed implementation as keyed thereby gaining an unfair/misleading advantage), and as somebee said, the benchmark itself largely measures repaint time (and does so in a less than ideal way, by using setTimeout macro queue as a proxy for repaint time measurement, in band, instead of instrumenting performance via CDP). It lacks rigor in many ways (the most blatant was that initially it considered keyed and non-keyed implementations on par, but there are other issues such as putting a lot of weight into DOM creation compared to e.g. array diff, or as somebee said, not measuring low repaint load diffs)

IMHO, it only has two things going for it: a) it has a lot of frameworks listed b) it does at least attempt to measure repaint times unlike other benchmarks that only measure JS time (which has become somewhat irrelevant since V8 et al now offload repaints out of the JS thread)

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

#178

Post by dtagames »

dmitriid wrote: post #173
dtagames wrote: post #145

Earlier quoted context omitted.

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

leaf components as a term appears in various discussions on web components. Many people don't see the value in full-blown web components(as they have lots and lots of unsolved issues), but agree that they may fill the niche/need for "dumb" reusable components at the end of the DOM tree (hence, leaf :) ): date pickers, buttons, links, all that kind of stuff.

I've seen tons of libraries of these and every big company seems to make their own, then try to release it to "help others." It's a noble idea, but the reality is that most of the cruft in those component sets won't be useful to app developers who aren't making apps for that company.

In other words, you are likely to need too many customizations even to leaf components to be able to use someone else's.

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

#180

Post by yunyu »

masklinn wrote: post #153
williamdclt wrote: post #89

Earlier quoted context omitted.

> 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.

Typescript will cover this!
Post reply on HN