[HN Gopher] Marko - A declarative, HTML-based language
___________________________________________________________________
Marko - A declarative, HTML-based language
Author : ulrischa
Score : 147 points
Date : 2025-11-08 18:43 UTC (4 hours ago)
(HTM) web link (markojs.com)
(TXT) w3m dump (markojs.com)
| shevy-java wrote:
| <p>Today is ${new Date().toDateString()}</p> <p>Random
| number: ${Math.floor(Math.random() * 100)}</p>
|
| Sorry, I don't like it. I already disliked that immensely in PHP.
| Not going back to that spaghetti mesh-up.
|
| The intro is also incorrect in my opinion. It writes a "HTML-
| based language", but this is more a hybrid of HTML and
| JavaScript. Why is JavaScript not mentioned in the intro?
| cyanydeez wrote:
| Don't blame Marko for this type of abomination. This is
| basically fancy react JSX.
|
| ITS just bizzare people want to parse JavaScript at the same
| instance they're parsing html.
|
| Also, LLMs are going to destroy any new framework. Someone's
| gonna need to figure out how to integrate these things into new
| tools. LLMs suck but it'll be much worse if they freeze
| innovations cause they're too expensive to chase the new
| hotness.
| Kiro wrote:
| You two are complaining about different things. Note how the
| parent mentioned PHP as the reference.
| jamal-kumar wrote:
| I think the grand takeaway is that people like to complain
| whatshisface wrote:
| LLMs can make use of documentation and example code.
| cyanydeez wrote:
| Yes. I understand second order context pollution.
| croes wrote:
| But because of LLMs there will be less example code
| cco wrote:
| How would you prefer to write those examples?
| ethmarks wrote:
| Personally, I'd either just put the content in an ID-ed span
| and have a script to replace the content. Another, perhaps
| better, way is to use Alpine.JS which excels at this kind of
| stuff.
| ghurtado wrote:
| Either solution sounds more verbose than the example and
| require writing code in at least one other source file
| nine_k wrote:
| But that separation is sometimes the point. A designer
| tweaking the looks has no chance to break the computation
| logic, and an engineer tweaking the computation part
| won't disrupt the design by mistake.
|
| Terseness is good for code golf [1]. I disliked
| CoffeeScript after writing it for some time: nearly any
| typo can result in another syntactically correct program
| which, of course, does not what you wanted the original
| program to do, or fails the compilation in an unrelated
| place. A practical language has safety margins, aka some
| redundancy.
|
| [1]: https://en.wikipedia.org/wiki/Code_golf#Dedicated_go
| lfing_la...
| sorrythanks wrote:
| Unless the designer removes the id, or the engineer
| introduces new output that is not styled.
| ethmarks wrote:
| But they're both framework-agnostic.
|
| This snippet works with any framework and any build step.
| <script
| src="https://unpkg.com/alpinejs@3.x.x/dist/cdn.min.js"
| defer></script> <div x-data="{ today: new
| Date().toDateString(), randomNum:
| Math.floor(Math.random() \* 100) }">
| <p>Today is <span x-text="today"></span></p>
| <p>Random number: <span x-text="randomNum"></span></p>
| </div>
|
| I'll concede that Alpine.js is harder to understand and
| more verbose than Marko's syntax, but in order to use
| Marko you have to commit to the Marko framework. If
| you're willing to choose a framework solely for its JS-
| in-HTML capabilities, there are much better choices (like
| SvelteKit that handles JS-in-HTML wonderfully).
| ffsm8 wrote:
| Fwiw, Marko predates svelte quiet significantly.
|
| It was originally created by eBay iirc, back in 2014 or
| so.
|
| It's syntax was even stranger back then, like writing
| "h1.myClass my header" to create a <h1 classes=myClass>my
| header</h1> and similar
| ggregoire wrote:
| > I'd either just put the content in an ID-ed span and have
| a script to replace the content
|
| And so your script is broken when someone else in your team
| (or maybe even yourself) renames or removes the ID and
| forgets to search in the whole project if some piece of
| code depends on this ID. JSX fixed all that mess 10+ years
| ago.
| cluckindan wrote:
| Yet you still need IDs for ARIA attributes, so now the
| JSX also needs a pile of shared variables
| didibus wrote:
| Separate templating from computing I'd assume.
| Lerc wrote:
| Is there any significant difference between that and
| element.innerHTML=` <p>Today is ${new
| Date().toDateString()}</p> <p>Random number:
| ${Math.floor(Math.random() * 100)}</p> `
|
| (ideally .setHTML() when it's available)
|
| At that point I think I'd have a skeleton html file that
| fetches a JS that does it all. I'd take JS with embedded HTML
| over HTML with embedded JS.
| TheCraiggers wrote:
| Isn't it wonderful that we live in a world where both ways
| can exist together, along with a myriad of other ideas for
| how to do the exact same thing?
| Kiro wrote:
| The point is that both ways contain the same "spaghetti"
| that the OP is complaining about and that it's unclear what
| alternative they actually prefer.
| worik wrote:
| No.
|
| But you can write dreadful code in any language
| marcelr wrote:
| this comment really proves that people do not consider the
| information presented to them
|
| marko is not comparable to php
|
| it is much closer to svelte
|
| i used to sympathize with people complaining about js-fatigue,
| but at some point its a skill issue
| jdmoreira wrote:
| Marko is server side. How is that closer to svelte?
| swiftcoder wrote:
| Svelte can also be used for SSR
| librasteve wrote:
| p "Today is {Date.today}", p "Random number:
| {(^100).pick}"
|
| Thought I would share this example as written in Raku using
| https://harcstack.org
| croisillon wrote:
| previously:
|
| January 2023, 125 comments -
| https://news.ycombinator.com/item?id=34591625
|
| August 2017, 150 comments -
| https://news.ycombinator.com/item?id=15057371
|
| February 2015, 10 comments -
| https://news.ycombinator.com/item?id=9065447
| hyperhello wrote:
| The problem when taking several languages and mixing them
| together this way is that the result is supposed to have brevity,
| but it's actually unreadable. You need slash to mean something
| grammatical, colon has to say something, you can speak "open
| brace" in a way that anticipates; @ means "at". This code looks
| more like a compression scheme.
| gdotdesign wrote:
| I think I managed to combine three languages in one with Mint
| (https://mint-lang.com/):
|
| 1. There is HTML (tags) with, but without interpolation {...}
| you can put string literals, variables and everything that type
| checks as HTML children.
|
| 2. There is CSS but only in style blocks where you can
| interpolate any expression you need and put in if and case
| expressions too.
|
| 3. There is the normal Mint code you write the logic in (this
| would be the JavaScript in other languages).
|
| Here is an example which have all three: https://mint-
| lang.com/examples/7guis/flight-booker
|
| The challenge was to make it seamless enough that so it doesn't
| look like that we tried to mash languages up, but to make them
| form a different language that is consistent and simple at the
| same time.
| moron4hire wrote:
| It's there a way to define routes in a nested, hierarchial
| fashion, preferably across multiple modules?
|
| For example, with react-router, my root route object array I
| define by spreading out other route object arrays that I've
| imported from other modules in my project. And each of those
| do the same thing, recurring as necessary until I get to the
| full depth of my route tree.
| sorrythanks wrote:
| almost all code looks like nonsense when you're unfamiliar with
| it
| zupa-hu wrote:
| Isn't syntax pretty much just compression? We could write down
| the AST itself in some generic notation but that would be
| orders of magnitudes larger, so invent clever tricks to
| compress it, which we call syntax.
|
| Edit: typo
| AbstractH24 wrote:
| There's some joke here about how that's in contrast to Marketo...
| celsius1414 wrote:
| There's a Marko Pollo joke, too, but I'm too chicken to say it.
| nielsbot wrote:
| Maybe off topic, but I'd kill for a HAML for TSX or Svelte!
|
| Working with HAML really did make building web app fun IMO. I
| can't be the only one!
| braebo wrote:
| Svelte already has a Pug preprocessor :)
|
| I used to use it years ago. So much nicer than HTML.
| promiseofbeans wrote:
| This is actually quite cool - JS inside HTML, rather than the
| more React-y HTML inside JS.
|
| As I understand it, Ryan Carniato was a major part of this
| project, and later went on to lead SolidJS, which goes back to
| the React style HTML in JS. Has he spoken at all about why he
| went back to that templating style?
| sorrythanks wrote:
| Yes. Mostly because:
|
| * JSX is well understood by a lot of developers * support is
| already built in to text editors * it is understood by
| typescript
| mlrawlings wrote:
| Ryan was working on Solid before he joined eBay/Marko. Both
| projects have benefited from the shared knowledge and
| approaching a similar solution space from different angles.
|
| He eventually got the opportunity to work on Solid in a more
| full-time capacity and decided to take it, but still talks with
| the Marko team from time to time
| senfiaj wrote:
| 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 better to stick to a big old
| player, such as Angular.
| nilslindemann wrote:
| 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, Angular, Asto, SolidJS,
| NextJS, Nuxt, Qwik... The list is so overwhelming. Almost each
| one claims that it fixes a problem in other framework, a year
| later the other framework fixes an issue... I think it's better
| to stick to a big old player, such as Svelte.
| nilslindemann wrote:
| No, just kidding. I believe in progressive enhancement, and
| none of these does this very well.
| mlrawlings wrote:
| 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
| afavour wrote:
| Maybe just me but I actually think building web apps is already
| fun. I've got a hot reloading instant dev environment, I can
| publish to users in an instant... it's great!
|
| Looking at the Marko examples I feel the same way I do whenever
| similar stuff gets showcased: it's trying to focus too hard on
| brevity and/or cutesiness and doesn't seem like it would scale
| well to a full, complex web app. But maybe it's not supposed to
| and maybe that's fine.
|
| React and Svelte and the rest can read clunkily at times but they
| have a clear separation of concerns and I'm glad for that.
| nchmy wrote:
| FWIW, marko comes from Ebay. So, it scales - and being
| primarily SSR, its a better UX than your preferred frameworks
| afavour wrote:
| 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).
| wauwboer wrote:
| Hi!
| ethmarks wrote:
| hello!
| nolanl wrote:
| 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
| pier25 wrote:
| This sort of stuff is just a big nope:
| <let/count=0>
|
| Why make a special language? Just use HTML and TypeScript that
| will be compatible with editors, tooling, etc. This is the same
| mistake Imba made.
|
| It's a shame because the core of Marko looks phenomenal:
| streaming, fine-grained bundling, rendering performance, etc.
|
| Also not sure about the file-based routing of Marko Run. That was
| a big reason why I abandoned SvelteKit.
| Etheryte wrote:
| File-based routing is fundamentally flawed and it cannot be
| fixed. A number of libraries opt for it since it's easier for
| newcomers to pick up, but eventually you run into all of the
| cases where you do need something else. This in turn leads you
| to a hybrid system of multiple things where there's no single
| source of truth and everything is spaghetti.
| ifh-hn wrote:
| I wonder how this compares to htmx, seems similar though
| obviously different in terms of approach. I'm getting a little
| jQuery feels too.
| brianzelip wrote:
| Here's an informing recent DevTools podcast episode featuring
| someone from the Marko team, https://www.devtools.fm/episode/
| quest88 wrote:
| 404
| yilugurlu wrote:
| It reminded me of ColdFusion, which could be something better if
| it hadn't ended up in Adobe's hands.
| tills13 wrote:
| 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 `<let/variable=...>` and `<for ...>` syntax is awful.
| afavour wrote:
| 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.
| tills13 wrote:
| That's true, sure. My response to that is in React you have
| JavaScript & JSX and there are clear boundaries. It's not
| mixed. I don't write
|
| <for ...>
|
| In JSX I write JavaScript that returns JSX:
|
| {data.map(node => <Element {...node} />)}
|
| ^ ----- JS ----^ ^ ------ JSX -------^
|
| or
|
| const elements = data.map(node => <Element {...node} />) ...
| <div>{elements}</div>
|
| Really the most obscure syntax there is the splatting but it
| makes sense to you when you realize that JSX is just
| syntactic sugar for JS:
|
| data.map(node => React.createElement(Element, { ...node }))
| abraxas wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-08 23:00 UTC)