Live data from Hacker News

Marko – A declarative, HTML‑based language

markojs.com

181–189 of 189 posts

Re: Marko – A declarative, HTML‑based language

#181

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

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}

Agree with sibling comments on control flow vs elements separation. For your specific case though, I think a middle ground can be found here:

  
    {#each users as user}
      {user.name}
    {/each}
  

Re: Marko – A declarative, HTML‑based language

#182

Earlier quoted context omitted.

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!

Cool!

If I may ask, what made you settle on the double dash to disambiguate content from tags? Like is it some sort of nod to SGML from way back when? It seems like an odd choice to me at first glance, but I bet it was thought about long and hard so I’d love to hear some background about what alternatives you considered.

Re: Marko – A declarative, HTML‑based language

#183
post #80

Earlier quoted context omitted.

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.

Read it in context. There's nothing wrong with SSR.

Re: Marko – A declarative, HTML‑based language

#184
post #51

Earlier quoted context omitted.

Pretty much every JS framework has SSR, the question is really how quickly does it hydrate. React typically rates poorly there but Svelte does great, at least partially because it has a compiler to optimize (like Marko does, it appears).

Marko’s compiler is designed for partial hydration (by default, without any special developer effort), which performs quite well. IIRC they were also looking at implementing “resumability” (term coined by Qwik, for an approach that sidesteps hydration as a concept entirely). I’m not sure where they’re at on that now, but I think it’s generally safe to say that Marko prioritizes load time performance more than nearly…

marko5 which is the stable version does partial hydration by default (like Astro, but with automatic boundaries)

marko6 which is currently in public beta is resumable by default, and does some similar things to the also public beta qwik2

Re: Marko – A declarative, HTML‑based language

#185
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…

Why are you copy pasting the same comment, under different usernames everywhere?

Re: Marko – A declarative, HTML‑based language

#186

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…

I think what changed is that people sort of realized compilers and build systems aren't just those things, they are also tools. They can be leveraged for making your code work better, automatically, and they can help you.

The dream of scripting languages you can just throw somewhere is great, but in an IDE, they really struggle. They're editor languages - you can understand them without extra context and tools, but your level of understanding is baseline more wishy-washy.

TS embodies this. It directly trades off that scriptability and ease for... really nothing. The compilation isn't a side effect, it's the entire draw. People WANT a compiler, or, at least, something similar.

Re: Marko – A declarative, HTML‑based language

#187

Earlier quoted context omitted.

Care to make quite a simple example where file based routing would struggle?

Role based access control is one of the simplest examples, your routes need to be conditional and all come with related metadata for permissions and such. With file-based routing you'll then end up with your routes defined in one place and the configuration for them either in a separate different place or split up across the codebase. Whenever you need to change something you need to remember to do it everywhere else…

File-based routing makes sense for some systems, particularly CMS, where the content is files and that drives the navigation. But this is a more website thing, not an app thing, and many things want to be apps, not websites.

Re: Marko – A declarative, HTML‑based language

#188
post #152

Earlier quoted context omitted.

> 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

Mastro looks like what I do for my offline-first, rendered from Service Workers. I just compose html template string literals and stream them back to the front end. The lib I use for HTML is a bit more powerful though. It is a very elegant way to program.

https://github.com/jon49/Soccer

Re: Marko – A declarative, HTML‑based language

#189
post #152

Earlier quoted context omitted.

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

Mastro looks like what I do for my offline-first, rendered from Service Workers. I just compose html template string literals and stream them back to the front end. The lib I use for HTML is a bit more powerful though. It is a very elegant way to program. https://github.com/jon49/Soccer

Thanks, this one? https://github.com/jon49/html-template-tag-async Looks very similar indeed! What makes it "more powerful" than Mastro's html template?
Post reply on HN