What has the world come to if this mess is considered easier than writing some nested html tags? (Perhaps I'm not plugged into the SPA scene well enough to appreciate this project. I hope it is useful to some.) In fact, reading the examples made me check to see if the first commit to this project was today, April Fools...
The link was shared here by someone with the same username as the github repo owner - presumably it was a pre-planned April Fools day joke for Hacker News.
I will as soon as the indentation technology has been worked out, and the API stabilized and a documentation framework has been completed, targeting 4/1/21.
One advantage is security. The text after the equals sign in each string can't be misinterpreted as HTML syntax, so it's safe to build flat HTML using string concatenation.
Replugging bepis, another way to write 'flat' HTML using operators with a slightly different operator set: https://github.com/dosyago/bepis
For me I just wanted to stop writing all the extra syntax (like `< > =` and closing tags) and use symbols my fingers were already reaching for. Just about conciseness, efficiency and enjoyment.
I really like the operator choice in this project!
Bravo, this is exactly what April Fools' jokes should be. Right on the line where you can think "Well, someone really could be crazy enough to propose this seriously!", where it's close enough that many of the replies here I can't even figure out if they are serious or joking.
I think the idea is a little rough around the edges but it has good bones. I think a better name might be something like "procedural HTML" since I think you're envisioning something like
But obviously with much terser syntax. Everyone seems to be on the declarative train these days that it's nice to see some interesting procedural work.
Such a thing composes pretty nicely too since basically any sequence of statements grouped together can be used as a component.
Congratulations on re-inventing Emmet (and a bunch of other tools) very badly, I guess? :)
For anyone interested, the equivalent of the first example in Emmet is:
div>h1{My Post}+ul>li{I am list item $}*3^ul>li{I am a different list item $}*2
It's a lot terser, but since it uses a CSS-like syntax, it's slightly less bizarre than at first glance and not that hard to pick up. Fun tool, more powerful than it looks, and supported by a ton of editors (I believe it's enabled by default in Jetbrains IDEs, for example...).
I don't think this is a joke, but an attempt of innovation. I think it is just rude to assume it is or make fun as it was.
Years ago I made an attempt to reinvent forums, with comments ordered horizontally instead vertically. It was very interesting to think about, but the end result had a lot of issues. I wouldn't appreciate people just making fun of it.
Some attempts to innovate might generate weird results, but there is no gain to society in pointing and laughing at the weird results. Thoughtful comments on why it's bad in anyone's point of view are much more helpful.
Different people have different perceptions of what is cleaner, or easier, or simpler. It is healthy to have this in mind while criticizing different approaches to a problem.
Completely agree with you. I'm at least always interested in alternative ways of representing and manipulating a tree structure, so it was a nice find even though I'm never going to use it.
It's fascinating how these projects are intriguing enough to reach HN front page with positive votes, but then get bashed in by masses. Reading all the comments here leaves me with bad taste in mouth.
What's with everyone's obsession with treating html like assembly: "Only people with long white hair and beards, magic wands and capes know html... Like... Like Gandalf, bruh!"
General question, it's been my main criticism towards all the modern js "frameworks" like react, vue and whatnot. Seriously, what gives?
Beats JSX. Why have a render() method with all that complicated JSX. Just store this stuff in state. This could be the next hooks. You could add callbacks to this structure too.
"data": [
"-h1 =My post",
"^ul li = I am list item 1",
"ul li = I am list item 2",
"ul li = I am list item 3",
"-ul li = I am a different list item 1",
{ xpathish: "ul li = I am a different list item 2", doer: function() {alert();} }
]
This is great – however, there's space for improvement, namely, flattening the JSON. Readability may also benefit from the addition of a few backslashes added by this procedure. A further step of x-www-form-url encoding or base64 encoding (maybe even as a data-URL?) may also add another as pleasing as satisfying step to you tool chain!
Personally, I'd prefer a more explicit declaration, which is also legitimate CSS, as in:
html > body > h1 { content: "Example"; }
html > body > h1 + p { content: "First Paragraph"; }
html > body > h1 + p + p ( content: "Second Paragraph"; }
html > body > h1 + p + p + ul > li:first-child { content: "A List Item"; }
(etc)
Mind how missing content or copy text, like the second paragraph being omitted, may be easily detected!
I don't think I get the point? It's even more convoluted than haml, which is already pretty well established, and the syntax is subtly different enough that I can see myself tripping repeatedly while trying to write this.
Is this an exercise? Is there an actual project somewhere doing it?
