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

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

1216 points by somebee 4 years ago | 345 comments

Hey all

My name is Sindre, and I am the CTO of Scrimba (YC S20). For the last 7 years, I have written all my web apps in a full-stack programming language called Imba. It compiles to JavaScript and its main goal is to make web developers more productive.

I just launched a major overhaul of Imba, so I wanted to share it here on HN, in case anyone are interested in learning more about it. It is very opinionated, so some of you might not like it, but I would love to hear anyones feedback regardless. Constructive criticism appreciated!

The backstory:

Imba initially started in 2012 as an effort to bring the elegance and conciseness of Ruby into the browser, and also because I felt that JavaScript and the DOM should be more tightly coupled together. Over the years, I have taken inspiration from React/JSX, and also Tailwind.

Since 2013, I have built several business-critical apps in Imba, so this is not a toy project or an academic exercise, it is extracted from a real project trying to solve real problems. Today, we are currently a small but passionate community of devs who use Imba all over the world.

The nitty-gritty details:

As mentioned, Imba compiles to JavaScript, and it works on both the frontend and backend. The quickest way to get a feeling of how it works is by checking out this video: https://www.youtube.com/watch?v=8XS5q9xhaMc

Alternatively, here is a list of the main benefits of the language:

* Clean syntax with built-in tags and inline styles

* Imba's Memoized DOM approach is *an order of magnitude* faster than Virtual DOMs (Vue, React). Learn more here: https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me...

* Imba works with Node and the npm ecosystem, and integrates tightly with both JS and TypeScript

* Blazing-fast dev/build tools based on esbuild

Each of the benefits above are explained more thoroughly in our docs here, so please check it out if any of the above points spark your interest: https://imba.io

With this version I feel that I am very close to my vision for what Imba should be. In other words; it is finally ready for public consumption. I'd wholeheartedly advice you to look into it and give it a whirl if you are interested in web development :)

Hope you like it, and please share any feedback you might have in the comments!

PS! We're also hiring Imba developers at Scrimba - see https://jobs.scrimba.com/. We don't expect you to be a seasoned Imba developer, but we expect you to pick it up fast :)

micheljansen 4 years ago |

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.

lhorie 4 years ago | |

I've noticed that some projects being complimented for having good docs come from CTOs (esbuild is another example). I'm hoping that by pointing out this little correlation, people might feel more inclined to spend more time on writing docs for their projects if they aspire to climb in the career ladder :)

jbverschoor 4 years ago | | |

PostgreSQL, FreeBSD, Debian, rails all have superb docs.

Also, the software quality is high. This used to be the case for Apple and windows sdks. Not anymore.. now it’s “read the code“ or stack overflow

vijaybritto 4 years ago | | |

Thats a very good point. In my company whoever writes the most valuable and extensive docs are looked up by people automatically. Either for clarifications or just networking. For the past couple of months I have been making devtools for QA and documenting them and just recently found out that every single team uses them and got recognized for it in the all hands!!

gregsadetsky 4 years ago | |

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.

nailer 4 years ago | |

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.

rawoke083600 4 years ago | | |

Oh YES ! 100% - or if the demo spans "multiple files" but the code-snippets doesn't include a filename comment.

I.e //app.js ...

//my-todo.js ....

linux2647 4 years ago | | |

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

scotty79 4 years ago | | |

Those shorthands are optional.

antattack 4 years ago | |

One thing that site does not specify is the Imba's license (MIT)

Bellamy 4 years ago | | |

What does it mean for projects build using imba?

system2 4 years ago | |

Exact opposite of Elastic.co.

meepmorp 4 years ago | | |

Every time I consult their docs, I feel like I have less of a handle on the topic than when I started.

js6i 4 years ago | |

Is it just me? This website is super laggy on my PC (which can run modern games just fine). Hardly hits 50 fps when scrolling. How slow can one get and still claim to be fast?

Shorel 4 years ago | | |

Firefox 91 on Windows. 2011 CPU. Radeon RX 570 GPU.

I have a low spec PC, and it is running just fine.

Maybe some extension slows down your Firefox? I don't use an anti-ads and anti-spam extension, I deal with that via hosts file.

p1necone 4 years ago | | |

Not just you, I have a pretty beefy desktop and it's noticeably laggy when scrolling for me too.

EDIT: ah - butter smooth in edge (and presumably chrome too), but laggy in firefox.

dtagames 4 years ago | |

Very true! It's a great landing page for a language that gets into the meat of it right away with clear examples in code blocks. Nice work.

fwip 4 years ago | |

I love the font chosen for the demo code, the descender on the f is very charming.

cutemonster 4 years ago | | |

I thought so too

somebee 4 years ago |

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

cies 4 years ago | |

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

gdotdesign 4 years ago | | |

If you want something like that, check out Mint (www.mint-lang.com) :)

davedx 4 years ago |

I have to say, I don't know if I'll use this language as I'm not a fan of Ruby syntax really, but the landing page presenting Imba is just phenomenally well done.

1. The live demos that you can easily click to open and edit the examples (but doesn't load in a slow, clunky, ad-infested live code editor like some sites do)

2. Those arrows pointing out language features, so compact, succinct and useful

3. A short list of very well thought-out demos showing off different aspects of the language. (I almost laughed with pleasure at the "autorender=1fps" part).

Great work.

Griffinsauce 4 years ago | |

Totally agree, this is obviously the work of someone who knows how to teach.

pier25 4 years ago | | |

The authors of Imba care a lot about education and are working on Scrimba.

dang 4 years ago |

Past related threads:

Launch HN: Scrimba (YC S20) – Interactive video for learning to code - https://news.ycombinator.com/item?id=24579699 - Sept 2020 (72 comments)

Imba – Create complex web apps with ease - https://news.ycombinator.com/item?id=20487972 - July 2019 (36 comments)

Imba the new JavaScript based language having Python,Ruby inspired syntax - https://news.ycombinator.com/item?id=18487942 - Nov 2018 (3 comments)

IMBA the new programming language for web apps - https://news.ycombinator.com/item?id=17505816 - July 2018 (2 comments)

Imba – 10 times faster than React - https://news.ycombinator.com/item?id=14837231 - July 2017 (1 comment)

Imba: A new programming language for web apps - https://news.ycombinator.com/item?id=10901054 - Jan 2016 (128 comments)

Imba - create complex web apps with ease! - https://news.ycombinator.com/item?id=10863827 - Jan 2016 (8 comments)

Imba – A new programming language for the web - https://news.ycombinator.com/item?id=10091454 - Aug 2015 (171 comments)

mstade 4 years ago |

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 have to refactor any call sites in JS if you make a function async?

I remember seeing someone here on HN showcasing a language where they did the opposite, making it so that await is implicit, so calling fetch or anything async doesn't require an additional keyword, and functions don't need to be refactored just to sprinkle async/await everywhere. I'll see if I can find that language again, but it seems to me there may be some idea sharing between the two that could perhaps yield some amazing features...

dt2m 4 years ago |

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?

brundolf 4 years ago |

I disagree with a couple of the choices made here, mainly the (apparent) lack of static typing

But with that said, the author has done an amazing job with the website and materials, and it's clear this language has a lot of upsides given that it's already been running in production as much as it has

I am also a big believer in the premise that we need a dedicated Web Language that incorporates client/server and logic/markup/styles into a coherent package (disclosure: I'm also working on my own version of that)

All in all, cool stuff, lots of takeaways to be found here at the very least

savmat 4 years ago |

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 included

jl2718 4 years ago |

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 confusing, outdated, and unnecessary for my performance needs, versus going raw with the latest features. It sounds like I might be missing something that could hurt me down the line. Thanks.

jsf01 4 years ago |

Really interesting project! I will definitely be trying it out today. One question—although you criticize some of the more common vdom benchmarks, I think it is still valuable to see where the dom updating strengths and weaknesses are in various approaches. Have you run any of the more standard frontend benchmarks on this and compared? I think it would be cool to see an entry for imba in the js-framework-benchmark table, especially considering your claim of low memory footprint.

https://github.com/krausest/js-framework-benchmark

Great work so far, I’m excited to give imba a spin.

somebee 4 years ago | |

I will try to add v2 to that benchmark relatively soon - it is a lot faster than v1 and has a much lower memory footprint and faster initial load time :) Should probably combine it with a few pull requests to the benchmark itself - as I consider it pretty flawed (see another comment here).

archibaldJ 4 years ago |

That's a very tight integration with JS&TS! Are you compiling into TS and then to JS? Or is it more of a decoupled process that was set up for the type-checking (like how tsconfig and babel works together)? When I was trying out ReasonML a few years back (and being unfamiliar with OCaml) I ran into some problems with bridging across types.

I checked out https://github.com/imba/typescript-imba-plugin for a bit and I'm still quite lost. Love to learn more!

Also, what is the cross-file refactorings in the tooling? Thanks!

somebee 4 years ago | |

Yeah, the typescript-imba-plugin does quite a lot of magic and might be a little rough to get into.

We essentially do the type-checking by compiling the files to js with jsdoc annotations, and for some features we also generate `.d.ts` files (see https://dev.to/somebee/global-type-augmentations-with-automa...). There is still a lot of work to be done on the integration. There are bugs and missing featyres, and the type-checking only happens in the tooling atm. The compiler could not care less about your types.

Since it is developed as a ts language plugin, references to imba files (like goto definition etc) works from ts/js files (you can include imba files in js/ts), and renaming methods / files works across all ts/js/imba files in your project.

jazzyjackson 4 years ago |

I am glad you persevered. I’ve been working on a language for 3 years now and sometimes I lose faith. It’s good to know that sometimes, projects can be finished (or at least shipped ;)

soheil 4 years ago |

This read like gibberish to me

  <header[fs:xl fw:700 ta:center c:gray8/40 p:2]> name

Why are we moving away from elegant legible HTML/JS/CSS stack to no nightmares like this and React where everything is smooshed together?

> bringing the elegance and concision of Ruby into the browser

As a big fan of Ruby how does this tap into the elegance of Ruby? Ruby is readable, this is not. In Ruby it's very difficult to write code that makes people suffer greatly to understand, this seems to be the opposite.

> It is very opinionated, so some of you might not like it

As if that's the reason people won't like this. Give me a non-opinionated language and I'll show you as many people not liking it. Create a good language and people will flock.

nsonha 4 years ago | |

> Create a good language and people will flock.

What a truthfully useless statement. "Good" means having opinions about things that dont matter? Like "I don't like that css uses full words, I prefer these acronyms"

Who gives a shit? Is this language designed to prevent copy pasting? You may be on to something here.

soheil 4 years ago | | |

No that's not what good is, I in fact love languages with concise syntax, Java is probably the worst in that department.

geenat 4 years ago | |

Thought this at first but it's just tailwind css aliases. They are interchangeable with the full name.

fs = font-size

fw = font-width

ta = text-align

c = color

redbar0n 4 years ago | | |

what I don't understand is why not have these abbreviations as snippets (text expansions) in the IDE, instead of language primitives?

So that the primitives match what people are familiar with from before, and match the actual web standards/specifications.

So that code which is reproduced and communicated online is also immediately readable for people who are not familiar with the abbreviations.

To gain adoption, reducing onboarding friction is key, and judging from my impression of Imba, as well as others' comments here, I think a lot of that unnecessary friction could be reduced.

On the other hand, if pros like reading very terse code, maybe an IDE plugin could be made to toggle the abbreviations.

armchairhacker 4 years ago |

Usually I think trying to make your own language for anything more than a DSL is a bad idea. But this project looks very impressive.

I've never heard of Imba before this post and haven't seen any real-world projects (besides Scrimba). If this is as good as it looks we'll probably get some soon.

Reminds me of Elm which took a similar route and seems to be successful.

As someone else said, one thing you probably want is static typing. Also make sure your language works well on larger projects. Everyone thinks they're making a simple website, but then it scales.

brundolf 4 years ago | |

> Usually I think trying to make your own language for anything more than a DSL is a bad idea.

Depends what "your own" means. If it's a one-off language just for one specific project, then you're right. But this one is much more than that. Surely you don't think people should stop making new languages entirely?

armchairhacker 4 years ago | | |

No i mean that a single person or small group can’t make a general-purpose language that would beat TS, Rust, Java, Swift, Go, etc.

All these languages are supported by huge groups. They have hyper-optimized compilers or JIT, IDE integration, libraries, and adoption.

If you can form a huge group, then you can beat these languages. Or if you target a niche. Or if you can use existing tooling (transpiling, LSP, effective existing libraries), and spend a lot of time and effort. Imba seems to be taking the third approach.

rawoke083600 4 years ago |

Looks really good ! Well done ! One "warning" I might give is I see "imba.commit" can become a problem.

This reminds me of the AngularJS(1) days, where if something didn't work (update), you will add a few well placed $apply or $digest everywhere. And of course if it doesn't work, you throw that $apply & $digest calls in s "setTimeoutLoops"... it got ugly fast.

This was of course was not the "correct way" of doing it in a "well written application" but many programmers working on one codebase, eventually somewhere someone gets frustrated with their code not working and in 12 months, you have these little "performance suckers" all around your code.

I don't really have a solution, maybe make it more "robust" or just keep in mind, programmers of all skill level and frustration levels, might just litter the codebase with these "magic-might-fix-my-issue-calls"

Congrats again on Imba !I do really like it :)

Tucanix 4 years ago |

This is just a clone of Svelte? It even has one of the same examples.. and similar syntax.

Better productivity is nice, but putting an abstracting in the way could be worse because it hides stuff from you you would otherwise learn or even make better yourself, this is also how we get slow apps which web based applications are infamous for. We need more native apps and new areas to explore not more of the same billion JavaScript libraries etc. JavaScript is brain rot for programmers and places creative people in tiny bloated slow sandboxes where they create carbon copies of each other. I hope someone finds it useful, i don't mean to rag on about this particular project.

redbar0n 4 years ago | |

It's more like the other way around..

The truth about Svelte: https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...

Svelte was a minimalistic and familiarity-optimised response to Imba:

"These projects are all very cool, but there's a reason they haven't hit mass adoption: they want to control the entire world. You can't adopt Elm or Imba incrementally" - Rich Harris of Svelte

Imba: Created in 2010. Released some 7 years ago, Github repo in around 2015. https://imba.github.io/imba-guide/lvl0/about/

Svelte: Initial release November 26, 2016. https://en.wikipedia.org/wiki/Svelte

yewenjie 4 years ago |

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

MatekCopatek 4 years ago |

You call it "full-stack" and mention memoized DOM, which makes it sound like it's not only a language but also a framework.

Is there a clear separation between those two parts? Could someone take just the language without the framework and use it for something that's not web related?

somebee 4 years ago | |

You can definitely use 'just the language' part. I'm using it daily for scripting, and we've written a lot of apis and libraries at Scrimba that does not utilize any of the framework-ish features of the language. But to make the tags and styling work really well it (imho) has to be thought of at the language-level.

juanramos 4 years ago |

Imba looks great! Now that v2 is out, what would you say are your priorities regarding Imba? Is there a roadmap somewhere?

0xcoffee 4 years ago |

Really amazing landing page, normally I just scroll though in one second but now I'm really taking the time to try and understand the examples.

Small note, the clock demos don't update every second in Firefox for some reason. On Edge it worked fine.

adventured 4 years ago |

Meta Imba -

https://i.imgur.com/k35ObtV.jpg

derangedHorse 4 years ago |

I wonder if there are plans for an imba course on scrimba. I think it would be a fun concept and could be a used as a free introductory course (both familiarizing more of the world with the language and the scrimba platform)

somebee 4 years ago | |

Yes, there are plans for an imba course on scrimba! It is almost comical, but scrimba was originally created with the sole purpose of teaching people Imba. Here we are, 4 years later, finally preparing to make a course :D

rtcoms 4 years ago | | |

So meta

A course for learning Imba on scrimba, which was made using Imba to make people learn Imba.

laserpistus 4 years ago | |

Yep, we will be making both individual scrims to use as examples and tutorial about building something more comprehensive.

edu 4 years ago |

Wow, congrats. It looks great, need to try it. The video gave me the same feeling I had when I watched the original rails demo video [1].

1. https://www.youtube.com/watch?v=Gzj723LkRJY

xutopia 4 years ago |

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.

49531 4 years ago | |

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. Alternatively I could write some logic on the frontend to validate, and this problem expands as the amount of fields in your form increases.

shatteredspace 4 years ago | | |

I'm just starting out in the journey of front-end development as a hobby and have been doing server-side infrastructure automation for my career for almost a decade now - so please bear that in mind with might seem like an ignorant question.

Let's say I have the client-side pick up the bill for logic/computing for form validation. Now for security reasons would I also want validation on the server-side as well due to the fact that client-side JavaScript can be manipulated? Or am I totally off-base in this line of thinking.

I'm personally opposed to how much logic happens on the client-side but I'm open to having conversation and changing my opinion on that.

handrous 4 years ago | | |

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.

valyagolev 4 years ago |

is there any particular reason why there doesn’t seem to be built-in type-checking system? i know it still seems to be a “personal preference” whether to check one’s types, but i wonder if any thought was given to including it?

somebee 4 years ago | |

There is built-in type-checking, but currently only via the tooling. It integrates with TS as a language service plugin (https://github.com/Microsoft/TypeScript/wiki/Writing-a-Langu...) so you get great warnings/errors, type inference and much more. To define standalone types or interfaces you still need to use `.d.ts` files, but that may change in the future :)

valyagolev 4 years ago | | |

that is to say, the types are not part of the syntax in any way?

k__ 4 years ago | |

Interesting.

I had the impression "tightly coupled with TS" would mean type checking.

That's sad.

xrd 4 years ago |

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.

trafnar 4 years ago | |

You can import any node module and use it with imba syntax. I’ve never had a problem doing this.

codesternews 4 years ago |

Congrats

How do you make money out of it?

Are you working full time on this?

Why YC funded this, could you tell me opportunity here?

mstade 4 years ago | |

As far as I understand it, the language came first and in order to teach it to others the founder created a screencasting tool of sorts, which became a company in its own right: https://scrimba.com

Ironically, it seems the company focused on content to teach primarily other technologies while using Imba to build it all. It's a rather fascinating story actually, which I'm paraphrasing and probably mostly got wrong, but if you're interested you can read more on their hiring page: https://scrimba.recruitee.com

N.B.: I'm not in any way affiliated with Imba or Scrimba. The first time I heard of the technology and the company was today, through HN, so I have no skin in this game. I'm probably also mostly wrong about everything above, so you know..

kvakkefly 4 years ago | |

They funded https://scrimba.com, an interactive coding tutorial platform, that is written in Imba.

Artistry121 4 years ago | |

Scrimba

peey 4 years ago |

1. Would it be correct to describe memoized DOM approach as combination of direct manipulation (like hand-written jquery, or what svelte compiles to) + a mechanism to avoid invoking selectors by caching references to DOM elements? Or is there more to it?

2. It'd be a good experiment to separate out the memoized DOM implementation from imba codebase in a way it can be used by different frameworks, just as virtual DOM libraries got popular after react. If someone were to attempt this, where would you recommend that they start with the imba codebase?

ita 4 years ago |

Is there an example of importing js functions to imba, or calling imba from inside js or ts? I could not find this.

In Scala js, this interoperability is quite painful, so I wanted to see how easy it is in imba.

arodyginc 4 years ago |

Using two-way databinding, how do you control the updates when it triggers other updates and so on? Is there any kind of loop control like say in Angular?

debarshri 4 years ago |

Hey there! I think it is really cool language. You can basically get started in minutes.

Does imba also have native app framework too?

somebee 4 years ago | |

No, not right now. The current version of tags is relatively tightly coupled with the DOM for maximum performance. It should be possible to create a bridge like react-native but it hasn't been an area of focus thus far!

trafnar 4 years ago |

I made a new video showing the process of installing Imba and getting to "Hello World" for anyone who wants a little help getting started.

https://www.youtube.com/watch?v=olyFE__fNQQ

nwienert 4 years ago |

I think the general idea is good, but then again I built a whole startup from the same principles ~6 years ago.

It’s actually pretty impressive how similar Imba is to motion, our project. We forked Babel at the time, added a “view” expression that worked like a class but far simpler, and within view bodies you’d have full reactivity of variables. What’s nicer than Imba, I think, is that you get mostly vanilla JS syntax, nothing new to learn, and it’s 100% React so click handlers are plain JS expressions just like React.

We ended up not launching it, and we were re-writing it but never ended up launching the re-write or the original (though the original is on my GitHub somewhere I think).

Best of luck!

https://youtu.be/HHTYHm6qLFY

redbar0n 4 years ago |

I'd like to see a discussion around:

1. The two-way data-binding. I'm sure a lot of developers have gotten it ingrained that "two-way data binding is bad and doesn't scale to large apps and teams".

2. Server-side rendering. 2.1 How does it work? 2.2 Is it limited to sending html strings like in the landing page example? 2.3 Will Imba render the app/page on the server before sending it to the client? 2.4 How does it compare architecturally to a React/NextJS combo?

The landing page could beneficially have addressed these two concerns briefly, and linked to a follow up discussion. I'm sure it is top-of-mind of many developers, and a potential (unnecessary?) turn-off.

lowi 4 years ago |

1. Do you have a recommanded way for i18n integration? 2. What's the performance of updating/adding/deleting a single entry in an array? Will imba just update the html element in O(1) or it will iterate the array to delect the changes?

akvadrako 4 years ago |

This looks pretty good, but it would be better if you compared the performance and rendering approach to Svelte instead of React and Vue. It's well known that virtual DOMs are not good for performance.

xavloper 4 years ago |

This is very cool. It seems like the perfect language for making web components. Do you have a "compile as component" mode to output components or component-like packages (like Angular Elements)?

th3h4mm3r 4 years ago |

First of all really a great work! Incredible!

Second, in my opinion, looking at the documentation, I don't understand all immediately or, better, I've got a little bit of confusion regarding a lot of things.

I'm unable to find "connections" with other languages / frameworks that I use every day (for example Angular, Vue and so on). So my question is: is somewhere some big example in the style of "Angular Heroes" example?

I really want to understand better every single part of Imba and I think that with an extensive example it could be more simple and fast.

Thank you.

habosa 4 years ago |

Congrats on the new launch! Scrimba, which could not exist without Imba, is one of those insane magical web things that is criminally under-appreciated. I hope Imba takes off!

krmmalik 4 years ago |

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.

aabbcc1241 4 years ago |

The author mentioned it's liberating to not need to manually manage the state.

This is also the downside of react compared to angular. You have to explicitly call function to update state, as oppo to transparent state update in angular or stencil.

I made a react hook (use-state-proxy) using proxy to auto call the set state function but it's still doing the work behind.

Memorized dom in lmba, solid.js and surplus look like more efficient and reasonable design.

jokethrowaway 4 years ago |

Looks neat and the website is simply awesome.

I personally wouldn't use it.

I'd rather go for something closer to JS or for something closer to FP like elm (if only they didn't have that dictatorship fixation issue).

I would recommend investing in fast and safe tooling. After years of typescript I switched to swc (written in rust) and the difference in productivity is night and day. No more OOMs, much faster, no more hanging processes with vscode.

Best of luck!

soheil 4 years ago |

How does one create a (for profit?) company around a programming language and starts posting jobs? There is nothing about monetization on their website.

shireboy 4 years ago |

Looks great! I’ll definitely be checking this out for my web work. One thing I see- and only mention because the rest of the product seems like it has an eye for detail- the “we are hiring” link and paint component on imba.io have minor layout issues on iOS Safari on iPhone 12 Max Pro. I haven’t tried other devices, but mobile responsiveness is one thing I look at when evaluating tools like this.

wccrawford 4 years ago |

How does it know whether to run the code client-side or server-side? How easy is it to accidentally end up creating SQL statements client-side and running them on the server?

If all the code runs server-side, is it not possible to create modern web apps on it where most interactions happen client-side, or does every request have to wait for the server's response?

shaunxcode 4 years ago |

This is the first time I have seen a language that extends/integrates markup in a way that does not feel superfluous.

k4runa 4 years ago |

Would it be possible with this to just apply tailwind css classes instead of learning this built in style syntax?

somebee 4 years ago | |

Sure, you can apply tailwind classes like `<div.w-32.h-32.rounded-full>` etc, but I'd definitely recommend using the built in styling as it is much more powerful (value interpolation, flexible modifiers etc).

k4runa 4 years ago | | |

Great! I am interested in trying out the language and learning more but there would be a lot less friction and mental confusion on my side if I can get started and apply tailwind classes and use something I'm familiar with.

quickthrower2 4 years ago |

It’s a double take to see scrimba as a YC company because I used them a while back so feel like they are an established company not a startup. In any case the experience of learning React on that platform is wonderful and gave me the best long term recall performance of any course I have done.

philmcp 4 years ago |

Very cool, good luck! I'm sure you'll do great

p.s. if you would be open to listing your positions on a 4 day work week (even at 80% salary) I'd be more than happy to promote them on https://4dayweek.io + the newsletter for free

mkl 4 years ago |

Hi Dan, I noticed that the links in the post are actual links here, unlike usual and what https://news.ycombinator.com/formatdoc says. Is this new? Is it just for Show HNs?

dang 4 years ago | |

We linkify text submissions for Show HNs and other interesting text posts where it's clear that the feature isn't being misused. I did that on the OP.

Q: How do I make a link in a text submission?

A: You can't. This is to prevent people from submitting a link with their comments in a privileged position at the top of the page. If you want to submit a link with comments, just submit it, then add a regular comment.

c-smile 4 years ago |

> Imba's Memoized DOM approach is an order of magnitude faster than Virtual DOMs (Vue, React). Learn more here: https://www.freecodecamp.org/news/the-virtual-dom-is-slow-me...

Just in case...

Sciter's native built-in Reactor https://github.com/c-smile/sciter-js-sdk/tree/main/docs/md/r... is using that so called "Memoized DOM" approach, which, as far as I understand the wording, is "diffing with real DOM": you have real DOM tree on the left and virtual DOM tree on the right. Reconciliation in this case is just patching of the left tree by the right one.

Essentially Sciter's Reactor is a unification of React with WebComponents ideas into single entity.

errantspark 4 years ago |

Very cool stuff, as a baseline I have about zero interest in a compile to JS language but this seems like it might actually lift more than it weighs! Really appreciate the documentation, examples and terseness of the code.

P.S. Nobody calls it San Fran :`D

burlesona 4 years ago |

This looks awesome, thanks for sharing! I love "bringing the elegance and concision of Ruby into the browser." I happen to be about to spin up a new project, so I'll give this a shot and see how it works in practice. Cheers!

qwerty456127 4 years ago |

Looks great. What are the cons? Why should I not use it? Every technology has some.

nsomaru 4 years ago |

Just wanted to say thank you for the purchasing power parity discount on scrimba.com

Very very cool!

mixmastamyk 4 years ago |

As a person who knows the big three H,C,J, I'm still a bit lost in the docs. They assume a lot of knowledge about web components, React, javascript tools, and other things.

I didn't make it to a hello-world page.

dvt 4 years ago |

Congrats on the launch! Like everyone else, I wanted to say great splash page and the syntax looks quite beautiful. Will do more of a deep dive once I get some free time, but it's quite promising.

turtlebits 4 years ago |

I wanted to like Imba, but there was no hash based router. (Required for static sites without having to redirect on the server). Quickly looking at the docs looks like that is still the same.

ArlenBales 4 years ago |

Really cool. This looks like an ideal language for super quickly developing small apps. I am probably going to use this to write a very minimalist hiking photo blog I've been putting off.

adam_ellsworth 4 years ago |

Absolutely stunning work. Love that it's able to work so well with TS. Also please tell Puppetmaster Pumpkin 'Hello' on my behalf and give some head scritches :3

agd 4 years ago |

This looks great however I’m skeptical about dom memoization. VDOM + immutable data structures seems to be much simpler conceptually and may provide even better performance.

redbar0n 4 years ago | |

VDOM is certainly not faster. Svelte says "VDOM is pure overhead", and VDOM approaches are generally beaten by Imba and reactive libraries like SolidJS:

https://krausest.github.io/js-framework-benchmark/2021/table...

https://svelte.dev/blog/virtual-dom-is-pure-overhead

jvalencia 4 years ago |

I came in thinking "ug" like this will go anywhere. Then I looked at imba.io and it totally made the case for it. Great job! Now I want to try it.

thomasfl 4 years ago |

Always impressed by what you are able to achieve Sindre.

SkyMarshal 4 years ago |

You had me at "indentation-based syntax". :)

daveidol 4 years ago | |

Lost me there tbh :)

cdeutsch 4 years ago | | |

Agreed. I was excited for a couple minutes, then 1 minute and 15 seconds into the video saw "indentation based" and checked out.

Nothing good is indentation based. I will die on this hill

hydroxideOH- 4 years ago |

There's a lot of css issues on mobile on imba.io

ttroyr 4 years ago | |

With a few minor exceptions, the responsive view looks great to me. The issues mentioned in this thread seem less to do with imba's architecture and more to do with rushed, last-minute marketing decisions (e.g. adding in the "we're hiring" chip; which, by the way, is fixed now). No excuses, of course, although as someone who painstakingly builds nice mobile views for complex web apps, no matter how good the library is (I was using Theme-ui), the process is still like building a house on-top of jello.

hydroxideOH- 4 years ago | | |

True, I wasn't even saying that as an accusation on the web framework, just pointed it out since the broken banner was a bit distracting.

warent 4 years ago | |

Yep, I'm on mobile and the website doesn't really give me much confidence in how Imba works with responsive development

johschmitz 4 years ago | |

True, it doesn't seem to work so well, see screenshot: https://pasteboard.co/KgkhOEo.jpg

zenosmosis 4 years ago |

Beautiful project.

Imba website looks great and the code examples explain it well. The React-like server-side rendering with the .html imports is phenomenal!

canada_dry 4 years ago |

OP, could you add some code to detect when javascript is disabled. A small thing, but a pretty common thing you should deal with.

sfusato 4 years ago |

What's the story about payload/bundle size for the compiled JS? imba.io stands at 3.76MB & scrimba.com at 2.15MB

prionassembly 4 years ago |

> Getting started > > The best way to get started with Imba is to use npx to get a brand-new project up and running.

What is npx?

politelemon 4 years ago | |

It's a tool that comes with NodeJS.

npx will run the node package from node_modules if it's present, else it will npm install the package and then run it.

rovr138 4 years ago | |

It's a command from node that allows executing commands from node_modules.

mleonhard 4 years ago |

How useful are the compiler error messages? I would like to see an example compiler error on the intro page.

nickthemagicman 4 years ago |

Looks great!

From a first look, I love the dimension types and the tags which compile down to native web components.

Hope good things for this.

mleonhard 4 years ago |

Does Imba have good tools for testing? I didn't find 'test' in the Imba docs.

divs1210 4 years ago |

The product is really cool, and so is the language! Congratulations and all the best!

throw_m239339 4 years ago |

Looks great! Congrats for being a YC alumni. One day myself perhaps...

math0ne 4 years ago |

Some cool ideas here, I love that everything looks so small and cute!

ampdepolymerase 4 years ago |

Are there any companies using Imba in production aside from Scrimba?

keithnz 4 years ago |

is there direct support for websockets? channels or something?

pier25 4 years ago | |

You can use all browser APIs as if you were using JS.

soheil 4 years ago |

> Amazing Performance

With no benchmarks to back up that statement?

pier25 4 years ago | |

Here are some results for v1:

https://krausest.github.io/js-framework-benchmark/current.ht...

(but the author claims v2 is much faster)

dmead 4 years ago |

does this take any inspiration from links?

https://links-lang.org/

abdellah123 4 years ago |

Does Imba support SSR? is it in the roadmap?

whiddershins 4 years ago |

How would you compare this to svelte?

k__ 4 years ago |

Reminds me of my LiveScript days.

I'm impressed!

still_grokking 4 years ago |

It feels indeed snappy and fast.

I'm impressed!

thobond 4 years ago |

Are there any other commercial companies, or is there someone who has used imba to develop their web apps except for OP?

arodyginc 4 years ago |

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

mleonhard 4 years ago | |

Next time, please explain why.

nsonha 4 years ago |

I can't believe it, this even has a dsl on top of css, baked in, as if that alone isn't a controversial thing. The rest of the language is really just around "least amount of characters", a really lame motivation that has been done countless times in my lifetime.

I'm all for new programming languages but you need to justify it with actual new ideas and new ways of thinking not some opinion about syntax. Guess what? everybody has one, they're all different.

mg 4 years ago |

One thing that irks me about Javascript is "const". I think it should have been called "con". "var", "let", "con".

So the first thing I did here is look up the docs and see how variables are declared. Aaarghh.. "let" and "const" again :)

lucideer 4 years ago | |

Why do you think this?

"const" seems clearer to me. "con" seems very open to misinterpretation: could mean many things.

Are there any advantages to "con" over "const"?

mstade 4 years ago | | |

My guess is the OP dislikes the difference in keyword length.

__ryan__ 4 years ago | |

I've thought about this a lot. I considered "con" for constants. I don't hate it. It also works as a double entendre-- "con" in Spanish means "with". So the following code could be read as "with name equal to Brad".

  con name = 'Brad'

I can't help but feel that it's somewhat jarring though.

If I had my druthers, I think I would choose "var" and "def" to declare mutable and immutable variables, respectively.

  def PI = 3.1
  def degreesToRadians = degrees => degrees * (PI / 180)

  var degrees = 180
  var radians = degreesToRadians(degrees)

Edit: After thinking about it some more, I think I prefer "const" over "con", but "def" over both.

Shorel 4 years ago | | |

Spanish native here. I would never read it like that.

I have programmed in a couple languages where every single keyword was in Spanish: Logo and some flavours of Visual Basic.

Either everything is in English, or everything is in Spanish. There's no middle ground with mixed keywords.

'Var' and 'def' both sound good to me.

Zababa 4 years ago | | |

> It also works as a double entendre-- "con" in Spanish means "with".

Triple even! In French it's the equivalent of "cunt".

amalantony06 4 years ago | |

Why does const irk you? const sounds a lot clearer than con. Is that your primary criteria for picking a language? ;)

mg 4 years ago | | |

I think it has three reasons:

The more often a construct is used in a language, the shorter I like it to be.

It groups variable definitions mentally by having them all the same length if they are "var", "let" and "con".

It would often make the code look more uniform which is more beautiful in my eyes. Example:

https://github.com/facebook/react/blob/cae635054e17a6f107a39...

I would prefer the lines 226 and 227 to start with "con" and "let". It would make the code visually more appealing to me.

veidr 4 years ago | |

You are obviously right.

The 'const' nomenclature is an abomination before science and human progress. However, given the prior art, I don't think we can hold it against a new/emerging language.

Anders, help us! Do the right thing. You are the only one who can.

(Of course, 'const' could be grandfathered and still work forever. Right-minded people, please upvote this obviously-right person at least back to a neutral #000.)

somebee 4 years ago | |

Tbh, var is actually deprecated since v1, so any mention of var in the docs is a mistake. Are there any other languages using 'con' for constants?

veidr 4 years ago | | |

No, but there should be!!

OJFord 4 years ago | |

I've never used a language with a 'cons' keyword, but nevertheless that's what I'd assume your 'con' was, if you didn't tell me otherwise.

I'm no particular JS fan, but 'const' is much clearer, it's a complete syllable, just like 'var' or 'func'. Yes 'fun' is used, but I think that's awkward for the same reason.

scns 4 years ago | |

Good idea IMO. That feature should be pretty easy to add (famous last words).

nsonha 4 years ago | |

if we want to nitpick I hate the fact that many dynamic languages need keywords to express very little information.

If js was made with types then the syntax `any x` (yeah lose the colon too, who gives a shit) is suficient to express that x is a variable, then `number x` could mean variable of type number, and `const number x` could mean constant of type number.

Zababa 4 years ago | |

Is the difference in length bothering you? In that case I find that let for immutable and var for mutable is pretty good, although for a language that's lose to JS that might not be a good idea. Maybe let for mutable like in JS, and val for immutable? (inspired by Scala).

jazzyjackson 4 years ago | |

Personally I don’t use any languages with reserved words

therufa 4 years ago | | |

that limits the number of languages to a handful. like brainfuck and similar ones. doesn't it?

graderjs 4 years ago |

Wow you are clearly a genius. The syntax looks beautiful! This is great. I don't want to use it (the best tool for the job for me is one that fits my own mental models, my own mind, and this is not it) but you are a genius.

Also -- wow those Nordics are super productive programmers/coders/developers/open-sorcerers (Sindre Aarsaether & Sindre Sorhus & Linus Torvalds & ...<please insert other names below to educate me>...) -- could it maybe have something to do with: The low GNI, the high HDI and the great weather for coding? (cold, blistery, bleak, focused, electrons-and-light universe is only outlet in a desolate landscape)? I have been to Oslo. The architecture is great.

PS - I use my own memoized DOM with minimal/granular updates in my own quirky framework (https://github.com/i5ik/vanillaview)

PPS - BTW memoized DOM is a great term of art. I perhaps shall be using it from now.

CONGRATULATIONS, SIR!

PPPS - Also what you are doing with Scrimba is so incredible. And GOOD. You are such a fuqing genius. Wow!

CRConrad 4 years ago | |

> please insert other names below to educate me

Bjarne Stroustrup, Anders Hejlsberg.

redbar0n 4 years ago | | |

Other Norwegian CS super-heroes, and what they invented.

-- MVC and DCI, invented by:

Trygve Reenskaug - https://en.wikipedia.org/wiki/Trygve_Reenskaug

-- Simula language, invented by:

Ole-Johan Dahl

Kristen Nygaard

https://en.wikipedia.org/wiki/Simula

Simula: first OO-language, introduced objects, classes, inheritance and subclasses, virtual procedures, coroutines, and discrete event simulation, and inspired languages such as Smalltalk, Java and C++.

derangedHorse 4 years ago | |

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

coding123 4 years ago | | |

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

jessmartin 4 years ago | | |

I literally googled to see if this existed last week. Would also use!

Osiris 4 years ago | | |

I started working in node around version 0.8, before both native Promises and async/await.

I worked with guys that started after async/await.

The new guys just think of everything like it's synchronous. They don't understand Promises. They never look at code and think "I can run this in parallel with Promise.all and a reducer". They just await each thing one at a time.

So, I'm not sure the async/await annotations are really helping us when devs just use them like decorations that just have to be there for it to work.

tsian2 4 years ago | | |

I'm new to NodeJS but it was my understanding that using await like that would help by not blocking the thread, leaving node free to process other requests.

gregoryjjb 4 years ago | | |

await won't block Node from handling other requests but it will block the thread that is awaiting. For example, these will execute one after the other (the "bad way"):

  await slowThingOne();
  await slowThingTwo();

but these execute in parallel, awaiting until both are finished (the "good way"):

  await Promise.all([slowThingOne(), slowThingTwo()]);

hmsimha 4 years ago | | |

Minor clarification, the latter example will only await until both have resolved *or* one rejects. To await the resolution of all promises, you should use the truly gamechanging `Promise.allSettled` , though you will have to transpile it if it's not supported by your target environments.

z3t4 4 years ago | | |

Don't forget to put each await in a try/catch. You are handling all errors aren't you!? ;)

inlined 4 years ago | | |

But then how do you gather promises together to run them in parallel? For sophisticated apps this is crucial.

redbar0n 4 years ago | | |

Each promise you create are executed already on creation.

But you gather them by using:

`await Promise.allSettled([promise1, promise2, promise3])`

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Osiris 4 years ago | | |

I would assume they would create an array with a bunch of Futures that would resolve at the end of the assignment, or the std lib would offer some ability to explicitly make things run in parallel.

hashkb 4 years ago | | |

Or queues, graphs, or other chaining behavior I can't predict you'll need as a tool author.

mstade 4 years ago | | |

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

williamdclt 4 years ago | | |

> 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

masklinn 4 years ago | | |

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

yunyu 4 years ago | | |

Typescript will cover this!

minxomat 4 years ago | |

That pretty much describes Lua.

mstade 4 years ago | | |

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

masklinn 4 years ago | | |

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

recursivedoubts 4 years ago | |

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.

dathinab 4 years ago | |

(Disclaimer not a web but backend dev.)

In my experience it's much more important to modularize/capsulate/segmentate by groupings of business logic then by groupings of implementation details.

Applying this to web applications (not simple text focused websites) this would mean that its preferable to have everything (HTML+JS+CSS) related to a specific widget (e.g. counter) in one place, instead of splitting it into many parts sprinkled across many files potentially in different folders. Similarly you also would e.g. want the CSS to be encapsulated as to the component as far as possible.

Its a bit of a different matter for classical html documents where the HTML made sense without JS or CSS and both where thinks you added "on top" to "just make it a bit nicer" but this isn't the think anymore for modern webapps (and many fancy websites).

Also if you work in a situation where you have many huge teams working on the same UI at the same time touching the same logical component (but normally different aspects of it) then having a more clear segregation can also make sense, but >99% of all companies are not ever in that situation.

This is also for example a major critic I have with react, it splits one logical unit across different files making it much harder to reason about it for the benefit of adding a bit more decoupling which isn't needed by >99% of dev teams.

alanbernstein 4 years ago | | |

Interesting, that makes sense. I'm thinking about a CLI analogy: you could write a program in C for the logic, some table specification markup language for the terminal layout, and a stylesheet for the colors and text styles. It would feel so cumbersome. The distinction between creating a document and a program is critical.

resonious 4 years ago | |

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 know if that are for style or if they're for behavior. I know there are some conventions out there where you prefix classes with "js-" etc, but if you just use "onclick" then it's obvious and you don't need a convention.

lhorie 4 years ago | | |

Personally I think it's not so much about separation of concerns/technologies per se, it's that this debate boils down to a different debate under the hood: the one about folder-by-type vs folder-by-feature[0].

The gist is that folder-by-feature is generally preferrable because it requires less context switching (in the literal sense of jumping between multiple different far away folders and scanning each for the thing you're looking for)

Single file components force you to organize code in a folder-by-feature structure, to a large extent. You can use folder-by-feature structure alongside with separation of technologies, it's just not that common to see it because the tooling to support it is not quite as optimized.

[0] https://softwareengineering.stackexchange.com/questions/3385...

cableshaft 4 years ago | | |

> You can use folder-by-feature structure alongside with separation of technologies, it's just not that common to see it

Angular is a pretty good example of this. The HTML, CSS, unit tests, and code are all in separate files, but they have the same base name and are grouped together in the same place.

tiborsaas 4 years ago | | |

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.

Mavvie 4 years ago | | |

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.

scns 4 years ago | | |

And have to switch between three files back and forth?

tiborsaas 4 years ago | | |

I usually split my IDE to multiple planes. A 4k, large monitor helps though :)

arodyginc 4 years ago | | |

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

klibertp 4 years ago | | |

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?

kingdomcome50 4 years ago | | |

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.

progx 4 years ago | | |

Or up and down in one file.

tannhaeuser 4 years ago | |

> The distinction between HTML, JS and CSS always made perfect sense to me.

Really? HTML is already heavy on syntax, and the whole point of SGML-style angle-bracket markup is to invisibly structure text hierarchically and sneak in rendering properties or other "metadata" not rendered to the user, via attributes. In which universe, then, has it ever made sense to write

    <div style="color: red">

rather than

    <div color=red>

in a document representation language? Let alone today's CSS atrocities. Mind, I'm not talking about CSS' out-of-control layout model complexity, but inventing a new syntax (or a thousand microsyntaxes really) on top of already syntax-heavy markup.

If you think about it, CSS appears to have gotten these ninja super-powers because HTML was locked in a decade-long stagnation while W3C was busy with XML, RDF, and whatnot. Then again, in the last decade using <div>s for nearly everything was frowned upon, so with the precedent set in the decade before, CSS just had to re-order, re-place, re-arrange ad absurdum without any discernible mental discipline. Or, maybe the CSS WG people just couldn't stop.

The end effect is that CSS isn't approachable for even seasoned graphic artists let alone laymen; another effect being browser complexity resulting in monopolies.

A false separation-of-concerns narrative has ruined many languages and approaches (such as enterprise OOP); for the web it was particularly idiotic given it's founded on composable documents.

JS? Once it was out there, evolution of HTML and declarative UIs basically stalled because there wasn't anything you couldn't do using JS. Nevertheless, CSS had also grown into outlandish complexity. Basically, the "web stack" of today is what any standardization effort should've avoided.

dtagames 4 years ago | | |

> The end effect is that CSS isn't approachable for even seasoned graphic artists let alone laymen; another effect being browser complexity resulting in monopolies.

This is so true. CSS has become a multi-headed Hydra whose parts appear completely unrelated to each other. I've been a developer and designer for more than 20 years and I have no idea what the parameter names and orders are for position, versus grids, versus float, etc. It's parameter soup. Who said the hardest part of programming is naming things? The CSS folks didn't get the memo.

To do any real work with CSS means you have memorize a bunch of conflicting weirdness and/or keep a reference page open at all times. The idea of CSS frameworks to simplify or fix this doesn't work because, in order to write or debug what you create in those frameworks, you must know regular old CSS!

It's turtles all the way down.

tekknik 4 years ago | | |

> To do any real work with CSS means you have memorize a bunch of conflicting weirdness and/or keep a reference page open at all times.

I agree with CSS being complicated, but this statement is true for pretty much everything. Not a day goes by I don’t close 20+ reference tabs at the end of the day, not counting what I closed throughout the day. It’s simply impossible to be a polyglot and not use references.

dtagames 4 years ago | | |

This is certainly true and we had paper books open on the desk at all times at IBM.

Who said the hardest part of programming is naming things? Some people do a better job than others. CSS is really wildly inconsistent within in itself. Is it another case of worse is better? Ugh. Probably.

Dah00n 4 years ago | | |

Not that I disagree that what we have today is a big mess but this sounds to me almost like the philosophy behind the old PHP version that everyone seems to hate. Personally I'd much rather have everything separated in a better HTML/CSS/JS than HTML+CSS+JS in one big pile. But I'm also not a fan of JavaScript at all, especially not of the hyped "one framework today, another tomorrow" that is JS development today. In my opinion in that area we are moving backwards very quickly.

nwienert 4 years ago | | |

Totally disagree as someone who grew up building websites as “cleanly” as possible, and now has spent many years doing all in one: the all in one is simply better in every way, it logically makes much more sense to group by component than by arbitrary style/structure/logic which just isn’t the right separation for many reasons that are written more fully in many places.

I also made SnackUI to solve the last problems of fully inline styles: namely to make them work 100% between React Native and Web, to make them extract to atomic CSS on web automatically, to optimize even conditionals into CSS, and finally to make media queries and themes work the same between Native/Web. We’re launching a very large app with it here in not long, and I absolutely love how clear it is to work on.

https://github.com/snackui/snackui

mdtusz 4 years ago | | |

I think we're well past the period of a new framework every week - at least in a "real world" sense. Nearly all companies will settle on react or vue these days with a long tail choosing others, but this is no different than any other part of software development - lots of different databases, web frameworks, auth libraries etc all exist as well and are used.

Most of these "new" frameworks are more because someone wanted to scratch an itch or solve a specific problem they had, and frontend code simply lends itself well to being open sourced. If you don't like the new js tools that are made, just ignore them.

q-rews 4 years ago | | |

Ok CSS sucks but what are the alternatives? What I see on other platforms requires some sort of WYSYWYG, which you can sort of do in the browser as well. They all generate XML, which I doubt is any more writable than CSS.

What I’ll forever complain about (as a front end developer) is that there’s no distinction between a document and an app. You can start from a blog post and turn it into a rocket just by throwing more JS at it.

I think only Google can fix it at this point:

- come up with a better alternative for apps

- reward websites that are content-only (or are guaranteed to support Reader view)

Now you could start to have simple documents and a powerful app platform.

Unfortunately this is hard to do as most developers will call bloody murder. So let’s enjoy CSS for the next hundred years, shall we?

ollerac 4 years ago | |

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.

klibertp 4 years ago | | |

> 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 <iframe>!).

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.

cwizou 4 years ago | |

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

sam0x17 4 years ago | | |

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.

cwizou 4 years ago | | |

Yep, the way I see it is, how much abstraction are you willing to accept.

Intuitively you may not want too much, until you find out that maybe you could have needed a bit more because of the repetitiveness. So frameworks that give you the option to gradually increase it when you need are the best. And when the documentation follows those patterns it's really great (I'd put Vue in that category).

Usually the thinking was, while it may not make sense, it will someday when my project grows, so let's adopt it right away. And for years I would have said that was a decent advice. Nowadays I think that with some of the more extreme scales behind some of those trends though, it's not always as clear cut.

dmitriid 4 years ago | |

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 reusable and benefit from separation, because your UI is directly dependent on business logic and vice versa. And because every screen in your app is a unique view into a unique part of your functionality.

dtagames 4 years ago | | |

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.

dmitriid 4 years ago | | |

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.

dtagames 4 years ago | | |

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.

Aeolun 4 years ago | |

I think eventually everyone just realized that so much of the styling is dependent on the element hierarchy that makes up the page that it’s pointless (and indeed painful) to separate your HTML from the component that uses it.

If you are actually using components, that isn’t much of an issue.

In a time when you’d be returning a whole document every single time, it might make sense to say ‘style this one document with this one stylesheet’, and even more so in a time when HTMl was still more or less semantic (e.g. an actual document).

presentation 4 years ago | | |

This! Usually CSS doesn't even make sense outside the context of the page/component it's styling.

There's also some nice stuff with modern tooling, where CSS is global by nature but writing it with your JS allows for the platform to automatically namespace your CSS, making styling behavior much more consistent.

Separately it also often makes sense to style things not just based on the HTML produced but also based on data stored in JS; writing your CSS with your components allows for a greater level of dynamic styles (which, to be fair, if you can achieve with pure static CSS is preferable, but it's not always the case).

jt2190 4 years ago | |

> ... [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 multiple files just makes it harder to know what's doing what.

The new frameworks are built around the idea that when we need to manipulate or style a DOM element then it should be isolated from the rest of the DOM, and so should the CSS and JavaScript that do the manipulating. In other words, what we often call "components".

For convenience, we often group these three things into the same file, or into small files sharing the same directory.

Reasoning about them much simpler, because each one is like a tiny HTML document with just a few DOM elements. No need to review hundreds of CSS selectors or JavaScript event handlers, because everything is together in one small package.

TekMol 4 years ago | | |

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?

dtagames 4 years ago | | |

Lit (which evolved out of Google's Polymer project) has many of the same goals of the Imba project and tries to reduce the spaghetti of something like AngularJS.

It handles CSS by letting you define it in within an individual component (file) but also import a style from another file. That way, your shared styles are in one place and only the overrides or extra styles needed for a special component are in its file.

I think it's wonderful!

Not to denigrate this project in any way, but most or all of its goals are already met by Lit[0]. Instead of a new language, it uses regular TS and regular CSS.

[0] http://lit.dev

dalmo3 4 years ago | | |

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.

k__ 4 years ago | |

A feature usually consists of all three HTML/CSS/JS.

So, if you split by technology, you don't have the code belonging to one feature in one place.

ssijak 4 years ago | | |

This is the most correct answer. It also felt wrong to me when I first started doing serious frontend development (I started it with AngularJS), but than it all made so much sense after a few projects and after I _experienced_ the benefites.

politelemon 4 years ago | | |

But even then, a feature can end up spanning multiple files for reusability.

jshmrsn 4 years ago | |

For web apps, you often want your content/HTML to dynamically render different elements depending on application state. Using a separate template file and having your logic plug into the template is often more complicated than just having your flow logic (if/else chains checking application state) return bits of relevant HTML/content inline.

tenaciousDaniel 4 years ago | |

Hard to describe, but it feels like it makes much, much more sense. I think it's because the divide between html/css/js is supposed to be one of concerns, but in reality the concerns are interwoven in many ways, and leads to issues when using them at scale. None of the scaling issues I've faced in the past re-occurred when I used a framework that combined the languages into single files.

namelosw 4 years ago | |

A bad metaphor I just came up with: You're cutting a birthday cake. If you do the horizontal cuts you could at best have like 4 cuts and it's very hard. If you do the vertical cuts you could easily have like 16 cuts for everyone.

Because the horizontal way separates the concern the wrong way, or more precisely, the non-scalable way.

The idea is the same way that backend architectures are migrating from layered architectures to microservice or DDD alike architectures.

HTML, CSS, JavaScript separation of concern: 3 layers. Layered architectures: presentation, application, domain, infrastructure etc. There's only O(1) number of layers, so it's not scalable enough for modern applications. You can came up with more layers, but it's still O(1) and would be more strechy, despite the business and codespace are growing fast. People will struggle because everytime they change one layer, they have to find the corresponding other layers of code - it starts to defeat the purpose of separation where it should help people not caring other layers when modifying code.

A more critical separation of concern is to have O(n) separation: you can different domains like products, inventory, sellers, account managment, custommer support etc. If your business continue to grow, you could have more of them. And more importantly, it's much easier to separate teams into pizza-sized teams than layered separation.

Don't get me wrong, layered architectures are still useful. In fact, most of the DDD implementations are layered. But there's mental overhead when you introduce separation. Communities like React and Vue decide that it makes sense to merge layers in Front-end for local reasoning over separation, and accoding to my experience it works well (because I find it's very common to modify HTML, JavaScript, and CSS at the same time before I even started to use React).

q-rews 4 years ago | |

The distinction makes sense on documents but it starts to break on apps. Javascript depends on HTML and HTML is generated by JS.

dtagames 4 years ago | | |

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.

q-rews 4 years ago | | |

You read that out of context. We’re talking about apps, web apps, SPAs, and specifically situations that bring you to mix HTML and CSS into a JavaScript module.

That situation most likely requires HTML (DOM) generation in the browser, which can only happen in JavaScript.

So, I reiterate, the HTML is generated by JS in these interactive modules.

You could generate the HTML on the server and then use jQuery to toggle elements… or just create full-JS components that take care of everything, giving some input data, instead of separating the HTML from the JS.

ehnto 4 years ago | |

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.

void_mint 4 years ago | |

> The distinction between HTML, JS and CSS

When all three of these things have to care very directly about eachother, separating them makes less sense.

bjourne 4 years ago | |

It never made a lot of sense in practice. Designers couldn't maintain CSS files because the language was too complicated for most. And these days, most DOMs in dynamic web pages are generated by the JS so the HTML/JS separation doesn't make sense either. Separating content, presentation, and logic is a good idea in theory, in practice not so much.

ourcat 4 years ago | |

This is exactly why I prefer Angular to React.

Our designer wouldn't have been able to deal with HTML markup within the JS files in React. Having the HTML and (S)CSS separated out made life much easier for him in Angular.

(edit: Naturally downvoted due to being slightly critical of React on HN. Which happens every time.)

randomdata 4 years ago | | |

I'm not sure you are being critical of React. There is nothing about React that prevents you from separating the HTML and CSS into separate files.

You are being critical of separation choices. To which I am curious why embedding the CSS and HTML inside a Javascript file makes any difference to the designer? In practice, we often see slightly different syntax to accommodate, but I cannot imagine that is a true barrier. The CSS and HTML (or their slightly modified equivalents) are still logically separated from the rest of the logic in the file.

ourcat 4 years ago | | |

I build all the components and get them working with mostly 'vanilla' styling. Then he brands/styles any he needs to by simply editing the .html and .scss files.

He has no idea about how the TypeScript/JavaScript files work. He doesn't really have to touch them, unless to maybe see what extra data the component model contains if he wanted to dig deeper and display other things.

randomdata 4 years ago | | |

Does he need to know how the Javascript files work, though? The HTML/CSS parts are still logically separated from the rest of the code. I am not sure someone who is capable of working on that type of content would struggle to recognize them. As long as the team is consistent, you can even reasonably predict exactly where such content would be found in the file.

If the designer was handed an HTML page with <style> tags embedded, I cannot imagine he would fall down unable to figure out where the CSS is, and this is not much different.

qorrect 4 years ago | | |

React is garbage I have no idea why it took off. Angular all day e'ry day.

Shorel 4 years ago | |

CSS "separation of concerns" never worked well anyway:

https://adamwathan.me/css-utility-classes-and-separation-of-...

notJim 4 years ago | |

Some of the early React talks from 2013 give great answers to this question IMO https://www.youtube.com/watch?v=x7cQ3mrcKaY

hyldmo 4 years ago | |

Another way too look at it: Do you prefer backend, frontend, and databases to be separate teams, or should each team have ownership over their own backend, frontend, and db?

methyl 4 years ago | |

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.

nsonha 4 years ago | | |

> 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

RussianCow 4 years ago | | |

Who actually does this for a living? And where do I sign up? :D

In all seriousness, I've never worked at a company that did anything like this. What is the use case for creating lots of small apps as opposed to maintaining a larger product?

omniscient_oce 4 years ago | |

Another marketing pet peeve that I have is term "blazing" fast. I think it's so overused now on any new tool's landing page posted online that I instantly just assume that it is, in fact, of relatively average speed. Are there no other synonyms for fast these days?

lhorie 4 years ago | |

That's not really a complaint about languages so much as it a complaint about marketing though, is it?

I don't go learning every language to mastery level, but I try to at least keep track of whereabouts they lie in the spectrum so I can cut through marketing-speak when I see it.

The way I see it, if a thing is being dogfooded in production, it's production grade. People can debate go-vs-rust or whatever till they're blue but the reality is simply that you can ship something with either and there are always going to be proponents and detractors for each side.

While I haven't followed Imba that closely, I've been aware of it for years, and I have to say it's one of few projects that actually has interesting technical takes on several fronts.

Mikeb85 4 years ago | |

Then don't use it. Some of us do like productive (ie. expressive and batteries included) languages. PHP, Python, JavaScript and Ruby still power most websites. There's plenty of choices for enterprise languages and frameworks if you want.

Productive, everything included languages/frameworks such as this are great for freelancers, designers, students, and anyone who wants to get up and running quickly. You can also still create maintainable projects with expressive languages (Google and Python, GitHub and Ruby are a couple examples).

People are doing things that don't break with 'productive' languages.

turtlebits 4 years ago | |

Considering Javascript is the only language supported on the frontend, claiming to be more productive is definitely valid.

Coffeescript was a breath of fresh air compared to writing ES5.

cflewis 4 years ago | | |

I sure am tired of Javascript being the lingua franca of the web. Imagine if we decided C was good enough and now all programming languages from that point on should just be something that cross-compiles to it.

mprovost 4 years ago | | |

Isn't that what WebAssembly is for? It's kind of the web version of C pretending that everything is a PDP-11.

void_mint 4 years ago | | |

Support WASM then?

arcanon 4 years ago | | |

We need a Coffeescript Renaissance!

scotty79 4 years ago | | |

World needs a version of coffeescript that compiles to typescript.

phil294 4 years ago | | |

(being discussed here https://github.com/jashkenas/coffeescript/issues/5307)

phil294 4 years ago | | |

Nothing is holding you back from using it!

nsonha 4 years ago | | |

lack of types and it used to be ignorant of perf in the generated code (creating IIFE unnecessarily)

phil294 4 years ago | | |

Regarding types, you're right, though JSDoc can get you very far

Regarding perf (performance, I guess?) - are you speaking of the single, global one? As CS takes care of variable scoping automatically, I think it makes a lot of sense (and is deactivatable anyway)

laserpistus 4 years ago | |

Fair enough - and so you skip the languages that doesn't fit that bill for you and pick one that you feel bring you those outcomes. No hurt feelings!

k__ 4 years ago | |

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

I see it in less visual clutter.

arcanon 4 years ago | | |

Yes. Which gives you more control over how you make the code look. DSLs.

lowercased 4 years ago | |

You could be doing stuff that works decently, is great for humans, and still be productive (maybe even fast). Or figure out how to do it faster next time.

Someone else may want you to be fast and productive. Or... they'll find someone else who can provide what they want who is faster and more productive than you.

lhorie 4 years ago | |

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

49531 4 years ago | |

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

sidlls 4 years ago | | |

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.

lyaa 4 years ago | | |

The complexity of many applications does not come from the client-facing features but rather from other business requirements.

For example, interaction analytics, A/B testing support, targeted updates, predictive caching, obfuscation and security, etc. For large companies, setting up the code base so new junior employees can start making contributions fast is also important and that adds to the total complexity too.

It's so much simpler to build an app if all you needed to do is get the minimum features done.

sidlls 4 years ago | | |

Yeah, not really. I've worked at some big companies, and currently at one you almost certainly have heard about in the news. The features you describe don't justify the complexity of these apps. Usually these features are implemented without any real consideration for the overall architecture, independently, and within a bubble such that the engineers and PMs on the project locally maximize the feature's complexity. Then it cascades when the feature is integrated into the rest of the app.

lyaa 4 years ago | | |

I think we differ in what we consider "justification." It seems to me that you are using the moral judgement of the sacrifice of perfect-pretty-code while I am considering the business-operations evaluation.

For a company which needs teams to implement features independently, the bubble you judge to be negative could indeed be an acceptable, or even necessary, compromise. The business decision to have independent teams might introduce complexity, sure, but within the context of the company's needs and goals, it might be a good choice and thus the added complexity is justified in my view.

The goal of any company is not to generate the most optimized code base. It only needs code that works for its purposes. It's a necessary balance which carries risks and opportunities.

moron4hire 4 years ago | |

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.

danenania 4 years ago | | |

Modularity or componentization as you call it (I like that! :P) is definitely one of React's main advantages. But I'd say just as important is that it acts as a trojan horse, essentially, to get people using the "good parts" of functional programming without having to understand FP deeply.

Just like React encourages components, it also encourages immutable data, one-way data flow, functional reactivity, and thinking in terms of state machines, even if you aren't necessarily familiar with that terminology.

All this stuff makes building a complex UI far more manageable and helps to avoid common pitfalls.

dragonwriter 4 years ago | | |

> They say the virtual DOM is the most important feature

Who says that now? I mean, in recent years VDOM seems to be more often criticized as the problem (with performance, but also otherwise) with React, even by people who like its basic dev-facing structure. Which is why you see frameworks with JSX and React-like structure (even Hooks, but without the explicit dependency pain point in the case of Solidjs) whose key selling point is no VDOM.

jl2718 4 years ago | | |

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.

sebular 4 years ago | | |

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.

RussianCow 4 years ago | | |

> I do not like testing a DOM tree I didn’t build.

What does this mean?

lowercased 4 years ago | |

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-40x speed difference.

lhorie 4 years ago | | |

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)

somebee 4 years ago | | |

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 frameworks increase by a factor of 5 or more.

And when you benchmark the speed of creating 10000 dom elements in an instant, less than 5% of the time should really be spent inside the framework one is supposed to test.

I stand by my claim in the mentioned article that tiny changes to a larger dom tree is a far better indicator of real world performance than anything else. Here Imba is really orders of magnitudes faster than react.

The last time I tested it, Imba was more than 10x faster than Svelte as well, but I'm not proficient enough in Svelte to claim that as a fact, and I have tremendous respect for Rich Harris and everything he's done with Svelte and other libraries.

codesections 4 years ago | | |

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?

dumindaxsb 4 years ago | | |

This is a cool project somebee. Interested to explore more.

On benchmarking: I went through the same concerns and ended up building a little benchmarking tool for a simple reactive UI library I'm working on. It's not super user-friendly yet but doing a good job of profiling tasks.

You can write custom benchmarks by clearly separating pre-setup work than relying on ready-made benchmarks (a bit of a pain initially, but helps a lot to fine-tune at unit-level going forward).

It uses Chrome DevTools Protocol(CDP) through Puppeteer and allows to analyze execution durations separately (Scripting, Layout, Paint, etc). Plus, it saves raw JSON profiling data, so you could import & examine it visually on DevTools Performance Tab's Timeline.

Think it will be helpful: https://github.com/dumijay/pfreak This is how the results look like: https://caldom.org/benchmark/

lowercased 4 years ago | | |

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 this point, it may still be hard to leave larger ecosystems of react/vue/etc. 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 - the data size and audience and app space just don't really call for it. However... as my needs change, imba will be something I'll revisit. Thank you.

cxr 4 years ago | | |

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

lowercased 4 years ago | | |

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.

codesections 4 years ago | | |

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