Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Marko – A declarative, HTML‑based language

markojs.com

Post reply on HN
Print view View original

161–170 of 189 posts

Re: Marko – A declarative, HTML‑based language

#161

Post by skrebbel »

lf-non wrote: 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.

Re: Marko – A declarative, HTML‑based language

#162

Post by kevlened »

fouc wrote: post #112
afavour wrote: post #57

Earlier quoted context omitted.

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.

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"…

Your example template and the others here are almost jsx after it's compiled (handwritten below). This jsx discussion seems more about removing the compile step, which you can do with https://github.com/developit/htm

    import { createElement as m } from "your-jsx-compatible-library";
    
    var ListComponent = () => {
      let count = 0, selected = null;
      return {
        view: ({ attrs: { items }}) =>
          m("div", null,
            m("p", null, "Clicked: " + count + " times"),
            m("ul", null, items.map((item) =>
              m("li", {
                onclick: () => { count++; selected = item; },
                style: { cursor: "pointer", color: item === selected ? "blue" : "black" },
              }, item)
            )),
            selected && m("p", null, "Selected: " + selected)
          )
      };
    };

Re: Marko – A declarative, HTML‑based language

#163

Post by recursivedoubts »

mcny wrote: 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/

Re: Marko – A declarative, HTML‑based language

#164

Post by agos »

mlrawlings wrote: post #45
senfiaj wrote: post #36

Honestly I don't know... I'm somewhat skeptical about these "next big thing that will fix all your pains in web development". There is so much fragmentation in JS libraries / frameworks. Angular, React, Vue, Svelte, Asto, SolidJS, NextJS, Nuxt, Qwik... The list is so overwhelming. Almost each one claims that it fixes a problem in other framework, and a year later the other framework fixes that issue... I think it's b…

Marko has been around for over a decade at this point and powers most of eBay. It's not the oldest or the largest, but it's got a pretty solid track record

is there a second app interesting app written with it? what is the sentiment about Marko from the people who use it everyday?

Re: Marko – A declarative, HTML‑based language

#165

Post by cubefox »

benrutter wrote: post #148
cubefox wrote: post #140

Earlier quoted context omitted.

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

I guess the argument against would be that designates an HTML "thing", i.e. some content for rendering. is about control flow, so it's a conceptually different thing. I can't tell how convincing that argument is to be honest, and how much I'm just rationalising familiarity.

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

Re: Marko – A declarative, HTML‑based language

#166

Post by jt2190 »

brianzelip wrote: post #50

Here’s an informing recent DevTools podcast episode featuring someone from the Marko team, https://www.devtools.fm/episode/

Some interesting context from the podcast:

> A lot of people are coming to eBay from a link that someone shared or from a search engine... This whole "amortized cost savings" you get from a Single-Page App (SPA) you don't necessarily get with eBay. Or people might go to eBay and open up ten [browser] tabs... If that's ten SPAs you're opening you're not really saving that much.

> At the same time in 2012 people are coming out with React, Angular... the question was "can we just use these tools?" and the answer was "kinda no"... Initially React was considered but the things we needed right out of the gate was streaming [sending as much HTML as... available without waiting for services responding with loaded data for the specific page]... With streaming you can send out stuff to the browser and have the browser [start] showing content to user without having to wait for your slowest service. At eBay there are a lot of services... Essentially if we were to adopt React or Angular the fact that there wasn't streaming would essentially mean that we're throwing away two seconds or so... which is not acceptable.

Re: Marko – A declarative, HTML‑based language

#167

Post by erikpukinskis »

CSSer wrote: post #80
nolanl wrote: post #42

As someone who has actually worked on JavaScript frameworks, I think Marko is criminally underrated. The compile-time optimizations are extremely impressive: https://markojs.com/docs/explanation/fine-grained-bundling I was not surprised for example that Marko came out very well in this performance comparison: https://www.lorenstew.art/blog/10-kanban-boards

I remain convinced that RSC and the SSR craze was a result of someone (or multiple) people needing a raise and their friends wanting to start a company selling abstract compute. Statically hydrated, minimal React was pretty great when served over good CDN infrastructure. Then I watched the bundle sizes and lock-in balloon. That second article is a dragon slayer. It really lays out the problem with React. In marrying…

I agree, if there is a death of React it will be killed by Next/Vercel.

I probably shouldn’t care. I’m just not looking forward to the chaos of another full “turn” in JavaScript, akin to query->backbone or backbone->react.

Maybe I shouldn’t fear it. I’ve just yet to see an idea that feels valuable enough to move an entire ecosystem. Svelte, HTMX, etc… where is the “disruptive” idea that could compel everyone to leave React?

Re: Marko – A declarative, HTML‑based language

#168

Post by naasking »

cubefox wrote: post #165
benrutter wrote: post #148

Earlier quoted context omitted.

I guess the argument against would be that designates an HTML "thing", i.e. some content for rendering. is about control flow, so it's a conceptually different thing. I can't tell how convincing that argument is to be honest, and how much I'm just rationalising familiarity.

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. This isn't a template language though.

HTML now has web components and so you can think of it in the latter way. I'm not sure if anyone has take this approach though.

Re: Marko – A declarative, HTML‑based language

#169

Post by Already__Taken »

notpushkin wrote: post #131
tills13 wrote: 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.

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

These aren't good because for 0-lists you have an empty parent containers so often you have a wrapping if outside all of that. More generally, template logic indent doubles up inside the indent levels of the template markup and I just find it ugly.

I like vue a lot more;

    
      {some.name}

Re: Marko – A declarative, HTML‑based language

#170

Post by throwingrocks »

CSSer wrote: post #80
nolanl wrote: post #42

As someone who has actually worked on JavaScript frameworks, I think Marko is criminally underrated. The compile-time optimizations are extremely impressive: https://markojs.com/docs/explanation/fine-grained-bundling I was not surprised for example that Marko came out very well in this performance comparison: https://www.lorenstew.art/blog/10-kanban-boards

I remain convinced that RSC and the SSR craze was a result of someone (or multiple) people needing a raise and their friends wanting to start a company selling abstract compute. Statically hydrated, minimal React was pretty great when served over good CDN infrastructure. Then I watched the bundle sizes and lock-in balloon. That second article is a dragon slayer. It really lays out the problem with React. In marrying…

SSR isn’t a craze. Web applications have been served that way for literal decades now.
Post reply on HN