Live data from Hacker News

Ijk – Transforms arrays into virtual DOM trees

github.com

31–40 of 49 posts

Re: Ijk – Transforms arrays into virtual DOM trees

#31

Looks awesome. Makes me wish I still used LiveScript because of the \string syntax and other features that would go great with ijk. You refer to h but what is it? I searched around but obviously something called h is hard to find.

https://github.com/ohanhi/hyperscript-helpers

Re: Ijk – Transforms arrays into virtual DOM trees

#35
post #18

Earlier quoted context omitted.

To be fair, you could say the same thing about Markdown. And yet here we are.

What is the link between the two? Markdown does not really look or works "like" HTML, it just happens to compile to it.

Again just being pedantic here. This thing doesn’t look or work like HTML, but it does happen to compile to it too. I find Markdown way easier to read than HTML, and I read both all day long. Maybe having two decades of experience reading HTML Zoe whatever isn’t enough to offset the superiority of this format? (No idea. I dislike JSX, and I don’t think this is actually more readable beyond cute little examples, but I might be wrong.)

Re: Ijk – Transforms arrays into virtual DOM trees

#36
post #27

nevow.stan did that back in 2004 :) https://github.com/twisted/nevow/blob/master/nevow/stan.py

nevow.stan uses objects to represent its ast. This isn't the same because it misses the point: objects aren't data in python (or most places, since objects are rarely printable/readable).

Practical Common Lisp demonstrates a spiritual predecessor that works on data from 2003[0]. I'm sure there are much older implementations floating around for CL and Scheme but I don't care to look for them. This is a common idiom in lisps.

[0] http://www.gigamonkeys.com/book/practical-an-html-generation...

Re: Ijk – Transforms arrays into virtual DOM trees

#37

Reminiscent of Breve. https://github.com/cwells/breve I don't see a huge advantage over hyperscript (hyperapp and mithril both use it), but that is a ridiculously small codebase. The JS hate is kind of funny around here, because when you dig into stuff like this, you realize that JS is very lispy in ways (it's easy to build up trees of HTML dynamically). In the mid aughts on r/programming people would rant and rave a…

I like JS even though I'm a strong-types-type. I appreciate its flexibility and the way you can do clever things with it (like this project eg). It has been let down though by what was initially a v poor module system.

This then led to the myriad toolchains/PMs/bundlers/language processors that added a huge amount of grit to what should have been a blindly simple development process. Some shoddy implementations have been allowed to mature far longer than they should have, and we're still trying to recover.

But the base language is fine IMHO.

Re: Ijk – Transforms arrays into virtual DOM trees

#38

What makes Hiccup so nice in the Clojure world is that Paredit can be used here which is the tool you're already using to manipulate data structures. For example, with Paredit, you can create an element and then move it prev/next/up/down a tree with muscle memory you're already using for the rest of your code. When I re-entered the Javascript world, I tried arrays-for-html but realized it's unbearable without manipul…

evil-lisp-state (used by default in Spacemacs) is a paredit-like thing that seems to work with parens, braces, and brackets in any language I happen to be using. I've used it with Python and Javascript without really thinking about it.

I've never used paredit in emacs, but I suspect that it might be amiable to working on Javascript as well.

More annoying to me would be all of the extra quotes and commas I need compared to Hiccup implementations in Clojure.

Re: Ijk – Transforms arrays into virtual DOM trees

#39

Improve it a little bit more by by removing the single quote by turning the html tags into functions that accepts 2 arrays: the attributes and the child elements, by this time you will come across with elm in which expressing the html document tree fits perfectly in the language syntax and semantics.

We already have something similar to this at hyperapp.. it is https://github.com/hyperapp/html . But yes, as mentioned by @masklinn, the drawback is you then have to define every element and then import all those definitions. With ijk you can write dependency free views (no import of h or h1, h2, etc.)

> you can write dependency free views

Well, explicit-dependency-free, but there's still an implicit dependency on the tag names. Granted, those are just standard HTML, but something is lost by not checking them at compile time. OTOH, you could write a linter for that...

Re: Ijk – Transforms arrays into virtual DOM trees

#40
post #7

I like the syntax, but I have to say that I prefer JSX. The real advantage of JSX is that it's very similar to HTML and developers have been reading, mentally modeling and reasoning about HTML -> DOM translation for decades.

The real problem with JSX is that it's almost HTML, but not quite, so you constantly have to fight against your assumptions about how it should work.

At least JS is really just JS, and developers have been reading, mentally modeling and reasoning about JS -> execution translation for decades.

Post reply on HN