Live data from Hacker News

Marko – A declarative, HTML‑based language

markojs.com

151–160 of 189 posts

Re: Marko – A declarative, HTML‑based language

#151

Earlier quoted context omitted.

Agreed on the syntax part. We’ve had good syntax for templates before: {% for user in users %} {{ user.firstName }} {% endfor %} And we have good syntax for templates now: {#each users as user} {user.firstName} {/each} Why do we have to squish everything into HTML-like-but-not-quite blocks? But no, JSX isn’t that great either: {users.map(user => ( {user.firstName} ))}

Why not use html/XML style syntax rather than mixing two syntax styles? For example, "{/each}" already looks like " ".

The question is why developers even want to contaminate markup with programming constructs when they have already everything they could ask for, including an object literal syntax ("JSON") for arbitrary graphs that also can encode a DOM.

SGML (XML, HTML) is for content (text) authors not developers, but webdevs just don't get it and look at it as a solution to developer problems.

Re: Marko – A declarative, HTML‑based language

#152
post #112

Earlier quoted context omitted.

Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach: var ListComponent = () => { let count = 0, selected = null return { view: ({attrs: {items}}) => m("div", [ m("p", "Clicked: " + count + " times"), m("ul", items.map(item => m("li", { onclick: () => { count++; selected = item }, style: {cursor: "pointer", color: item === selected ? "blue" : "black"} }, item) )), selected && m("p"…

> Speaking of writing javascript instead of JSX, I'm a big fan of the hyperscript approach Speaking of writing JS instead of JSX or your example, I like the vanjs.org approach: const Hello = () => div( p("Hello"), ul( li("World"), li(a({href: "https://vanjs.org/"}, "VanJS")), ), ) van.add(document.body, Hello())

Since we're sharing HTML in JS syntaxes. Don't forget JS tagged template literals like https://jsr.io/@mastrojs/mastro/doc/~/html

Re: Marko – A declarative, HTML‑based language

#153

Earlier quoted context omitted.

I don't think the syntactic sugar works how you describe. JSX components actually desugar to something like: {jsx(MyComponent, { attr: "yes" }) (Previously this function was called "React.createElement", but these days they have special functions that only the JSX compiler is allowed to use.) The extra layer of indirection is needed to do things like support hooks being called inside of MyComponent's function body, k…

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.

Re: Marko – A declarative, HTML‑based language

#154
I personally do not want to write HTML and I especially do not want to encode logic into it. This wave of HTMX-likes has some interesting ideas but encoding it all into HTML just feels so wrong to me. JSX is likewise awful. We need real programming languages here.

Re: Marko – A declarative, HTML‑based language

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

You can use React with just JS, JSX isn't core to React. htm is a library that uses string templates and is just Javascript but works like JSX and can (but doesn't need to be) compiled down like it, and you can use with with React or other tooling.

Re: Marko – A declarative, HTML‑based language

#156
post #115
post #114

Dear front end devs Please chill w making new languages and frameworks that re-solve solved problems. The internet is working fine as it is. Warmest regards, Matt

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 are having the same argument we're having. At least the bloat is consistent.

Re: Marko – A declarative, HTML‑based language

#157
post #59

After two decades of this churn we are back to the equivalent of JSP. It was the correct paradigm all along but millennials wouldn't be caught dead working with such a "lame" technology so they bestowed SPA on us and now they are slowly walking it back.

> It was the correct paradigm all along but millennials wouldn't be caught dead working with such a "lame" technology so they bestowed SPA on us and now they are slowly walking it back.

Oh man, I wish people would stop attributing picking SPA's to not wanting to use "lame" technology. It makes them sound myopic and naive. Really naive.

You may not have been around at the time, but I certainly was. And the idea that SPAs don't (or didn't) have their place is just plain absurd.

Like "Tell me you're a backend dev who is made they have to learn new stuff to stay current" without telling me.

In fact, I'm not even sure what your argument actually is. Is it MSP vs SPA? Is it JSP vs any of the other backend languages you can still use with React? Is it templates vs JSX? What are you actually trying to argue?

Are your rose-colored glasses ignoring what a pain a decent UX was to build in those technologies? That mobile apps pushed backends to an api-only version and SPAs took over for the frontend? Are you saying people should pick old technologies wtih old tooling just because you didn't get on board with it the first time?

It's not swinging back to JSP, it's finding a middle-ground between the 2. THAT'S what progress is.

Re: Marko – A declarative, HTML‑based language

#158

Earlier quoted context omitted.

Why not use html/XML style syntax rather than mixing two syntax styles? For example, "{/each}" already looks like " ".

The question is why developers even want to contaminate markup with programming constructs when they have already everything they could ask for, including an object literal syntax ("JSON") for arbitrary graphs that also can encode a DOM. SGML (XML, HTML) is for content (text) authors not developers, but webdevs just don't get it and look at it as a solution to developer problems.

Because you need quasiquoting to construct trees decently, and JavaScript doesn’t have any worth a damn.

Re: Marko – A declarative, HTML‑based language

#159
I think it's worth noting Marko's proven nature.

In years of using eBay, have never had an issue with it. Sad that that's a high praise these days, but it is. eBay is fast, it works damn well, and always has.

As a counter point, React's poster children, in messenger, Facebook and Instagram. Have all been plagued with UI bugs for the entire time I've used them.

Obviously those aren't wholly comparable, but I do think it's worth taking note of the actual outcomes we have when tools are used at real scale.

Re: Marko – A declarative, HTML‑based language

#160
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 was looking at Marko a few years ago because of the concise syntax. I have always thought highly of Pug and would have loved a framework that integrated that sort of elegant, minimal syntax. Unfortunately, Marko doesn’t even get the syntax highlighting right in its own docs for this style.

The example on that page with leading commas to separate tag attributes, and a number of other choices across the framework are also a turn off for me personally.

I’ve mostly been using Svelte for the past half-decade instead but still hope for something more elegant to come along.

Post reply on HN