Live data from Hacker News

Marko – A declarative, HTML‑based language

markojs.com

171–180 of 189 posts

Re: Marko – A declarative, HTML‑based language

#171

Earlier quoted context omitted.

I don't think that's true, you can write uncompiled createElement calls and everything still works fine.

createElement still exists, but the JSX compiler doesn't use it anymore; see https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n... Regardless of whether you use JSX or createElement, you can't just call MyComponent({ attr: “yes” }) directly, is the main point.

You certainly can in Preact.

Re: Marko – A declarative, HTML‑based language

#172

Earlier quoted context omitted.

I mean, you’re technically correct. But you’re also not understanding the point. What people mean when they say “React is just JavaScript” is… 1) JSX, more than any other templating system, is just HTML interleaved with JavaScript. It’s HTML, and anything between { and } is evaluated as JavaScript. 2) Inserting a React component’s “HTML tag” in your JSX is _actually_ the same as calling the JavaScript function. The H…

> JSX, more than any other templating system, is just HTML interleaved with JavaScript. It’s HTML, and anything between { and } is evaluated as JavaScript. That’s not true though and IMO is one of the weaknesses of JSX: it looks like something it is not. Having to use className instead of class is one of the most obvious tells. But in theory if it was just HTML with {}s I should be able to do: {stringContainingHTML}…

You can just use “class”, fyi, at least in Preact, and iirc, it works in React, but isn’t officially supported there.

Re: Marko – A declarative, HTML‑based language

#173

Earlier quoted context omitted.

This. Also it cannot be understated: apis, language and tooling are miles ahead better they were a decade ago or more.

I’m not completely sure of that. The simplicity of a backbone app, plain javascript with no build, less/sass, early days node.js or old RoR apps is becoming increasingly elusive. Not a lot of modern apps you couldn’t build with those stacks, and most of the underlying technology is the same (http/html/css/js/sql/libuv/etc). Saying this feels like advocating for a return to horse carriages though, when the right analo…

Ooof. No thanks. SASS can die a fiery death, and give me React over Backbone 10 times out of 10. I guess these things are somewhat subjective, but I don’t miss the pre-React days at all.

Re: Marko – A declarative, HTML‑based language

#174

Earlier quoted context omitted.

I think there isn't too large a gap between "wrap this stuff in a box and add a line break afterwards" and "repeat this stuff for each item".

Generally for templating, you want a visual distinction between the control language and the target/rendered language, because they are two different things. Where they aren't two different things, you have some kind of component configuration language, like WPF on .NET. There is no control language, the instantiated components have behaviours and are responsible for any control logic, like rendering a list of items.…

> Generally for templating, you want a visual distinction between the control language and the target/rendered language, because they are two different things.

But as I just said, in the end their function actually doesn't seem overly different (to me at least) so a visual distinction with curly brackets rather than angle brackets is perhaps not necessary.

Re: Marko – A declarative, HTML‑based language

#175
post #57
post #56

It looks interesting and in a past life I probably would have tried it out but do you know why I like React? Because it's just JavaScript. This ` ` and ` ` syntax is awful.

I mostly agree with you but React isn’t just JavaScript. JSX is not JavaScript. It’s just that we’re so used to it we don’t consider it notable any more. Worth keeping in mind when you’re looking at a brand new framework.

Another interesting approach IMHO is https://github.com/gnat/surreal

Re: Marko – A declarative, HTML‑based language

#176

Earlier quoted context omitted.

Generally for templating, you want a visual distinction between the control language and the target/rendered language, because they are two different things. Where they aren't two different things, you have some kind of component configuration language, like WPF on .NET. There is no control language, the instantiated components have behaviours and are responsible for any control logic, like rendering a list of items.…

> Generally for templating, you want a visual distinction between the control language and the target/rendered language, because they are two different things. But as I just said, in the end their function actually doesn't seem overly different (to me at least) so a visual distinction with curly brackets rather than angle brackets is perhaps not necessary.

Languages are intended to be read more than written. You'll often be manually reading both the original source and the generated source and comparing them to ensure the original source is being correctly interpreted. Having those visual markers is very useful for debugging this process.

Re: Marko – A declarative, HTML‑based language

#177
post #78

This looks interesting and seems like a vast improvement over jsx. I especially love the pug style concise syntax which for some reason they have buried deep into the docs rather than showcasing front and center. https://markojs.com/docs/reference/concise-syntax

I dunno, to me that seems like all YAML's mistakes all over again. I quite like the conciseness, and significant whitespace seems like a good match here, but the double hyphen thing really seems odd to me. And the syntax is so hard to parse, apparently, that their own example is syntax highlighted incorrect, coloring content as if it's tags.

FYI in an actual editor the syntax highlighting works. In the (new) website it's using a different highlighter which has issues. Will be fixed soon!

Re: Marko – A declarative, HTML‑based language

#178
post #156
post #115

Earlier quoted context omitted.

Matt, Marko was created over a decade ago at Ebay. One of its core dependencies is morphdom, which has been used successfully by a slew of frontend view libraries like Marko, including Phoenix LiveView. Please chill. In general. Use cases are not all equivalent. Ignorance is boring.

Nope. They are pretty much all equivalent. Browsers render HTML. This is a quite-solved-problem. Is there a scenario that can't be handled by the tools we've had for years? The web just doesnt require another paradigm. There is way, way too much tooling for a not-that-complicated problem. Also... if Marko 10 years old, where's the news part here? https://news.ycombinator.com/item?id=34591625 Same post, in fact they a…

> Nope. They are pretty much all equivalent.

Good luck, man.

Re: Marko – A declarative, HTML‑based language

#179

Earlier quoted context omitted.

I don't think that's true, you can write uncompiled createElement calls and everything still works fine.

createElement still exists, but the JSX compiler doesn't use it anymore; see https://legacy.reactjs.org/blog/2020/09/22/introducing-the-n... Regardless of whether you use JSX or createElement, you can't just call MyComponent({ attr: “yes” }) directly, is the main point.

Yeah I don't think you ever could just call MyComponent(props) directly if the component used hooks. If it was hookless (what a concept...) it wouldn't matter.

Re: Marko – A declarative, HTML‑based language

#180
post #147

What I'm hoping to see in the future are: 1. native support for all http verbs such as put and delete in html itself without relying on JavaScript 2. sensible controls for drop down, select, multi select, date, time, datetime and so on without relying on any JavaScript 3. Submitting a form and submitting actions without reloading the whole page again without requiring any JavaScript 4. A whole lot of stuff yes withou…

We are working to integrated some of the ideas of htmx directly into the HTML specification: https://alexanderpetros.com/triptych/

Thank you so much for doing this. I love it!
Post reply on HN