12 ms·

Marko – A declarative, HTML‑based language

367 points by ulrischa 11mo ago

shevy-java 11mo ago
<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 11mo ago
  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 11mo ago
    You two are complaining about different things. Note how the parent mentioned PHP as the reference.
    - jamal-kumar 11mo ago
      I think the grand takeaway is that people like to complain
  - whatshisface 11mo ago
    LLMs can make use of documentation and example code.
    - cyanydeez 11mo ago
      Yes. I understand second order context pollution.
    - croes 11mo ago
      But because of LLMs there will be less example code
- cco 11mo ago
  How would you prefer to write those examples?
  - ethmarks 11mo ago
    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.
    - huflungdung 11mo ago
      [dead]
    - ghurtado 11mo ago
      Either solution sounds more verbose than the example and require writing code in at least one other source file
      - nine_k 11mo ago
        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_golfing_languages https://en.wikipedia.org/wiki/Code_golf#Dedicated_golfing_la...
        sorrythanks 11mo ago
        Unless the designer removes the id, or the engineer introduces new output that is not styled.
      - ethmarks 11mo ago
- Lerc 11mo ago
  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.
  - fooqux 11mo ago
    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 11mo ago
      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 11mo ago
    No. But you can write dreadful code in any language
- marcelr 11mo ago
  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 11mo ago
    Marko is server side. How is that closer to svelte?
    - swiftcoder 11mo ago
      Svelte can also be used for SSR
- librasteve 11mo ago
  p “Today is {Date.today}”, p “Random number: {(^100).pick}” Thought I would share this example as written in Raku using https://harcstack.org https://harcstack.org
- someothherguyy 11mo ago
  > I already disliked that immensely in PHP. Not going back to that spaghetti mesh-up. That looks like a pretty normal template to me and nothing like plain PHP templates? What do you mean by "spaghetti mesh-up"?
croisillon 11mo ago
previously: January 2023, 125 comments - https://news.ycombinator.com/item?id=34591625 https://news.ycombinator.com/item?id=34591625 August 2017, 150 comments - https://news.ycombinator.com/item?id=15057371 https://news.ycombinator.com/item?id=15057371 February 2015, 10 comments - https://news.ycombinator.com/item?id=9065447 https://news.ycombinator.com/item?id=9065447
- joshdavham 11mo ago
  Oh wow! So I guess Marko has been around for while. Despite that, this is my first time hearing about it.
  - ricardobeat 11mo ago
    The main author also wrote morphdom circa 2015, which is/was used in htmx and sprung up a bunch of other frameworks.
hyperhello 11mo ago
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 11mo ago
  I think I managed to combine three languages in one with Mint (https://mint-lang.com/ 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 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 11mo ago
    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.
    - gdotdesign 11mo ago
      No it's nor supported currently.
  - promiseofbeans 11mo ago
    Your Mint language looks awesome! You’ve done a great job making it very seamless between the 3 languages. I had a couple thoughts regarding your css/styling though: 1. The one feature I prefer in Marko when compared to Mint is Marko’s nice ID and class syntax, rather than your custom selectors, so you can just use regular CSS (which seems to be advancing faster than the JS & HTML specs combined). You could get the scoping using shadow roots for your components (I’m sure this has flow on consequences, but given you own the language it’s probably better case than many others.) 2. Interpolating values directly in CSS blocks is something that a lot of HTML templating systems sort of give up on (see Astro going out of it’s way to make interpolating variables super verbose [0]), so I’m glad to see you do it. Does the value interpolation compile to CSS variables that are set on the component root (or somewhere else I suppose) as in Astro [0], or is it just simple interpolation? Additionally, I can’t help but notice your hash symbol would conflict with ID selectors, so is CSS nesting available? Please don’t take this as criticism! I really like what you’ve done here and am very curious. [0]: https://docs.astro.build/en/guides/styling/#css-variables https://docs.astro.build/en/guides/styling/#css-variables
AbstractH24 11mo ago
There’s some joke here about how that’s in contrast to Marketo…
- celsius1414 11mo ago
  There’s a Marko Pollo joke, too, but I’m too chicken to say it.
promiseofbeans 11mo ago
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 11mo ago
  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 11mo ago
  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
- bitwize 11mo ago
  JS inside HTML! Groundbreaking! It's nothing like Netscape ever conceived in 1995...
nielsbot 11mo ago
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 11mo ago
  Svelte already has a Pug preprocessor :) I used to use it years ago. So much nicer than HTML.
- ALLTaken 11mo ago
  Someone posted here, thanks for that!! It immediately reminded me of HAML: https://harcstack.org/ https://harcstack.org/ I like HAML a lot, it was the most pleasant to develop with. And it shares a lot in common with Stylus. They both shared things in common. NO NEED FOR: Curly braces, parentheses and semicolons. The cool thing, it was all optional and I wasn't forced to make use of all shortcuts! I developed my own CSS Framework in 2003, shared with some UX guy at Yahoo, who incorporated it into YUI mostly as is, after I waived all rights. Most of that became internet standard. Later I had my own PHP based CSS scaffolding framework in 2005 that could also generate grids (before flex-box). SCASS/LESS was really similar to my framework, when it came out. But I disliked it, it just looked like PHP mixed with CSS. I thought why accept the ugly syntax, despite a compiler being available? The best ever existed is: HAML + Stylus + (HARC?) See the beauty of it: https://stylus-lang.com/docs/selectors.html https://stylus-lang.com/docs/selectors.html Now compare with HAML https://haml.info/ https://haml.info/ I think https://harcstack.org/ https://harcstack.org/ makes a good successor.
- rk06 11mo ago
  vue allows other languages in .vue files for both css & html similar to js
senfiaj 11mo ago
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 11mo ago
  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 11mo ago
    No, just kidding. I believe in progressive enhancement, and none of these does this very well.
  - senfiaj 11mo ago
    Svelte / SvelteKit is very lightweight but probably not a good choice if your app quickly grows in complexity. Angular has a larger community, long term support from Google, more people are familiar with, has rich functionality (including forms, localizations) and is well structured for huge projects. Once NextJS, SolidJS and others were interesting because of SSR, but Angular added this too (and continues to improve) in the recent versions.
- mlrawlings 11mo ago
  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 11mo ago
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 11mo ago
  FWIW, marko comes from Ebay. So, it scales - and being primarily SSR, its a better UX than your preferred frameworks
  - afavour 11mo ago
    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).
    - nchmy 11mo ago
      Marko did ssr by default, a decade before the other frameworks decided to bolt-on ssr...
    - eyelidlessness 11mo ago
      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 all other frameworks.
      - 11mo ago
wauwboer 11mo ago
[flagged]
- ethmarks 11mo ago
  hello!
nolanl 11mo ago
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 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 https://www.lorenstew.art/blog/10-kanban-boards
- brain_staple 11mo ago
  That’s interesting. I’ve always held SvelteKit in high regard for greenfield projects because it balances capability, developer experience, and performance, but I’ll have to give Marko a look. I’d love to see a similar deep dive into Electron style desktop frameworks since that space still feels underexplored compared to mobile. I honestly wouldn’t know where to start for a video game interface, and that bothers me.
- CSSer 11mo ago
  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 itself to Next.js and embracing the server, it's betrayed the platform. Meanwhile, the platform itself has matured. React practically built my career, and I just don't have a reason to choose it anymore.
  - erikpukinskis 11mo ago
    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?
  - 11mo ago
pier25 11mo ago
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 11mo ago
  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.
  - epolanski 11mo ago
    Care to make quite a simple example where file based routing would struggle?
    - Etheryte 11mo ago
      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. If your routing is in code, you can define everything in one place with strict type checks, tests, and so on.
      - array_key_first 11mo ago
        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.
ifh-hn 11mo ago
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 11mo ago
Here’s an informing recent DevTools podcast episode featuring someone from the Marko team, https://www.devtools.fm/episode/ https://www.devtools.fm/episode/
- quest88 11mo ago
  404
  - brianzelip 11mo ago
    Oops! https://www.devtools.fm/episode/146 https://www.devtools.fm/episode/146
- jt2190 11mo ago
  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.
yilugurlu 11mo ago
It reminded me of ColdFusion, which could be something better if it hadn't ended up in Adobe's hands.
tills13 11mo ago
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 11mo ago
  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 11mo ago
    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 }))
    - c-hendricks 11mo ago
      There are of course libraries that use JSX and have '<For>' components
    - phatskat 11mo ago
      I’ve never been a fan of JSX. I tried years ago and wasn’t super into it, and then Vue after that and found the syntax a lot easier on the mental model.
  - tshaddox 11mo ago
    There are a lot of things people might mean by claiming that something "is just JavaScript," but one possible meaning is that the source code you write can run in the browser without any build whatsoever. For React, that's true with the exception of JSX, which is a very simple and optional syntax transform. (Of course in practice you'll probably want to do module bundling too, but browsers could technically load your ES modules directly from static file storage. For Marko, that doesn't seem to be the case, but it also doesn't really make sense given the problems that Marko is trying to solve. Another thing people might mean by "it's just JavaScript" is a much more subjective notion about how similar the overal syntax, control flow, etc. feels to whatever previous JavaScript experience the person has. This meaning is a lot harder to pin down, and in most cases reasonable people could disagree on what is and isn't "just JavaScript" according to this meaning. That said, I would tend to agree that React's templating uses normal JavaScript control flow and composition primitives more so than Marko.
abraxas 11mo ago
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.
- woleium 11mo ago
  Yes, we go in circles, but there are subtle (and sometimes not so subtle) improvements every iteration. Of course sometimes there are also dead ends. It is exciting to see what the ingenuity of the next group brings, even though some existing things are lost, but hopefully not forgotten.
  - epolanski 11mo ago
    This. Also it cannot be understated: apis, language and tooling are miles ahead better they were a decade ago or more.
    - ricardobeat 11mo ago
      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 analogy would be the brief electric car era of the early 1900s, and React as the Model T.
      - christophilus 11mo ago
        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.
      - array_key_first 11mo ago
andix 11mo ago
I didn't look deep into Marko yet, but in my opinion JSX is by far the best HTML template language there is. And it's not restricted to React. Most other template languages hits serious limitations really fast. I tried and hated (for non trivial things): Angular, Handlebars, Razor (dotnet) and Vue (which does support JSX optionally).
- joshdavham 11mo ago
  Could you please try to be a bit more substantive with your comments? E.g., Why do you think JSX is the best? What limitations did you hit with those other template languages?
  - andix 11mo ago
    Most template languages can't do something like that: // data const numbered = true // or false const strings = ["a", "b", "c"] // render const items = strings.map(i => <li key={i}>Item {i}</li>) if (numbered) return (<ol>{items}</ol>) else return (<ul>{items}</ul>)
    - gigatree 11mo ago
      RippleJS is doing the same sort of thing, but better IMO
    - piercey4 11mo ago
      Marko can! It's "define" tag lets you create reusable templates in your reusable templates. https://markojs.com/docs/reference/core-tag#define https://markojs.com/docs/reference/core-tag#define
- deleted 11mo ago
  [deleted]
- Rendello 11mo ago
  I've been liking the model of the Python library Dominate [1]. You write your HTML as regular Python code, and you render() once at the end, having full control over the formatting. Well, at least in theory; in practice the formatting is brittle and the library otherwise makes some choices I don't like. I wrote a Rust library with a more restricted/verbose API, and I've been enjoying using that. Unfortunately, I find it really hard to make it as fast as I want. It's really the perfect use case for arena allocation, but doing that and keeping the API as function calls mirroring HTML is not trivial, and probably requires macros to rewrite the tree as a series of stack pushes. 1. https://pypi.org/project/dominate/ https://pypi.org/project/dominate/
jm4 11mo ago
It looks like they reinvented ColdFusion for modern web apps.
lf-non 11mo ago
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 https://markojs.com/docs/reference/concise-syntax
- sings 11mo ago
  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.
- skrebbel 11mo ago
  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.
  - piercey4 11mo ago
    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!
    - skrebbel 11mo ago
      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.
ccpzza 11mo ago
For those curious, the Marko team created a HN clone to showcase Marko 6 https://github.com/marko-js/example-hacker-news https://github.com/marko-js/example-hacker-news
deleted 11mo ago
[deleted]
bdcravens 11mo ago
So .... ColdFusion?
jordanscales 11mo ago
Looks absurd. Can't wait to try it.
fuman 11mo ago
[flagged]
debuggerpk 11mo ago
abomination
mattw1 11mo ago
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
- rvzx 11mo ago
  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.
  - mattw1 11mo ago
    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 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.
    - rvzx 11mo ago
      > Nope. They are pretty much all equivalent. Good luck, man.
didip 11mo ago
Honestly, why not just put Scheme on the browser. Scheme is capable to represent HTML JS and CSS all in 1 language.
hansvm 11mo ago
I don't normally comment on formatting, but for a language I assume they're dog-fooding for the demo it's amusing that none of the gradient-backgrounded text renders visibly ("HTML-based", "building web apps", etc).
mobeigi 11mo ago
I love the landing page for this project. It's very engaging.
Antwan 11mo ago
The new jquery? Eurk.
- austin-cheney 11mo ago
  I thought React was the new jquery.
cubefox 11mo ago
It's misleading to call this "A declarative, HTML‑based language" when it in fact relies heavily on writing explicit JavaScript (which is very different from HTML and not declarative at all). Something like htmx does come a lot closer to being a HTML‑based language in my opinion. So much so that you could add it to the actual HTML spec. (That's not to say that Marko is bad, just that it's more a way to mix HTML and JavaScript in a more intuitive way rather than a declarative, HTML‑based language.)
mcny 11mo ago
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 without requiring any JavaScript When I first heard the term htmx, I thought that was what htmx was but sadly it is just intercooler. What I am asking for requires broad support from browser vendors.
- recursivedoubts 11mo ago
  We are working to integrated some of the ideas of htmx directly into the HTML specification: https://alexanderpetros.com/triptych/ https://alexanderpetros.com/triptych/
  - mcny 11mo ago
    Thank you so much for doing this. I love it!
rapish62 11mo ago
[dead]
davexunit 11mo ago
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.
faldor20 11mo ago
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.

367 points by ulrischa 11mo ago

<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 11mo ago
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 11mo ago
  You two are complaining about different things. Note how the parent mentioned PHP as the reference.
  - jamal-kumar 11mo ago
    I think the grand takeaway is that people like to complain
- whatshisface 11mo ago
  LLMs can make use of documentation and example code.
  - cyanydeez 11mo ago
    Yes. I understand second order context pollution.
  - croes 11mo ago
    But because of LLMs there will be less example code
cco 11mo ago
How would you prefer to write those examples?
- ethmarks 11mo ago
  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.
  - huflungdung 11mo ago
    [dead]
  - ghurtado 11mo ago
    Either solution sounds more verbose than the example and require writing code in at least one other source file
    - nine_k 11mo ago
      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_golfing_languages https://en.wikipedia.org/wiki/Code_golf#Dedicated_golfing_la...
      - sorrythanks 11mo ago
        Unless the designer removes the id, or the engineer introduces new output that is not styled.
    - ethmarks 11mo ago
Lerc 11mo ago
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.
- fooqux 11mo ago
  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 11mo ago
    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 11mo ago
  No. But you can write dreadful code in any language
marcelr 11mo ago
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 11mo ago
  Marko is server side. How is that closer to svelte?
  - swiftcoder 11mo ago
    Svelte can also be used for SSR
librasteve 11mo ago
p “Today is {Date.today}”, p “Random number: {(^100).pick}” Thought I would share this example as written in Raku using https://harcstack.org https://harcstack.org
someothherguyy 11mo ago
> I already disliked that immensely in PHP. Not going back to that spaghetti mesh-up. That looks like a pretty normal template to me and nothing like plain PHP templates? What do you mean by "spaghetti mesh-up"?

croisillon 11mo ago

previously: January 2023, 125 comments - https://news.ycombinator.com/item?id=34591625 https://news.ycombinator.com/item?id=34591625 August 2017, 150 comments - https://news.ycombinator.com/item?id=15057371 https://news.ycombinator.com/item?id=15057371 February 2015, 10 comments - https://news.ycombinator.com/item?id=9065447 https://news.ycombinator.com/item?id=9065447

joshdavham 11mo ago
Oh wow! So I guess Marko has been around for while. Despite that, this is my first time hearing about it.
- ricardobeat 11mo ago
  The main author also wrote morphdom circa 2015, which is/was used in htmx and sprung up a bunch of other frameworks.

hyperhello 11mo ago

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 11mo ago
I think I managed to combine three languages in one with Mint (https://mint-lang.com/ 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 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 11mo ago
  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.
  - gdotdesign 11mo ago
    No it's nor supported currently.
- promiseofbeans 11mo ago
  Your Mint language looks awesome! You’ve done a great job making it very seamless between the 3 languages. I had a couple thoughts regarding your css/styling though: 1. The one feature I prefer in Marko when compared to Mint is Marko’s nice ID and class syntax, rather than your custom selectors, so you can just use regular CSS (which seems to be advancing faster than the JS & HTML specs combined). You could get the scoping using shadow roots for your components (I’m sure this has flow on consequences, but given you own the language it’s probably better case than many others.) 2. Interpolating values directly in CSS blocks is something that a lot of HTML templating systems sort of give up on (see Astro going out of it’s way to make interpolating variables super verbose [0]), so I’m glad to see you do it. Does the value interpolation compile to CSS variables that are set on the component root (or somewhere else I suppose) as in Astro [0], or is it just simple interpolation? Additionally, I can’t help but notice your hash symbol would conflict with ID selectors, so is CSS nesting available? Please don’t take this as criticism! I really like what you’ve done here and am very curious. [0]: https://docs.astro.build/en/guides/styling/#css-variables https://docs.astro.build/en/guides/styling/#css-variables

AbstractH24 11mo ago

There’s some joke here about how that’s in contrast to Marketo…

celsius1414 11mo ago
There’s a Marko Pollo joke, too, but I’m too chicken to say it.

promiseofbeans 11mo ago

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 11mo ago
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 11mo ago
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
bitwize 11mo ago
JS inside HTML! Groundbreaking! It's nothing like Netscape ever conceived in 1995...

nielsbot 11mo ago

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 11mo ago
Svelte already has a Pug preprocessor :) I used to use it years ago. So much nicer than HTML.
ALLTaken 11mo ago
Someone posted here, thanks for that!! It immediately reminded me of HAML: https://harcstack.org/ https://harcstack.org/ I like HAML a lot, it was the most pleasant to develop with. And it shares a lot in common with Stylus. They both shared things in common. NO NEED FOR: Curly braces, parentheses and semicolons. The cool thing, it was all optional and I wasn't forced to make use of all shortcuts! I developed my own CSS Framework in 2003, shared with some UX guy at Yahoo, who incorporated it into YUI mostly as is, after I waived all rights. Most of that became internet standard. Later I had my own PHP based CSS scaffolding framework in 2005 that could also generate grids (before flex-box). SCASS/LESS was really similar to my framework, when it came out. But I disliked it, it just looked like PHP mixed with CSS. I thought why accept the ugly syntax, despite a compiler being available? The best ever existed is: HAML + Stylus + (HARC?) See the beauty of it: https://stylus-lang.com/docs/selectors.html https://stylus-lang.com/docs/selectors.html Now compare with HAML https://haml.info/ https://haml.info/ I think https://harcstack.org/ https://harcstack.org/ makes a good successor.
rk06 11mo ago
vue allows other languages in .vue files for both css & html similar to js

senfiaj 11mo ago

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 11mo ago
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 11mo ago
  No, just kidding. I believe in progressive enhancement, and none of these does this very well.
- senfiaj 11mo ago
  Svelte / SvelteKit is very lightweight but probably not a good choice if your app quickly grows in complexity. Angular has a larger community, long term support from Google, more people are familiar with, has rich functionality (including forms, localizations) and is well structured for huge projects. Once NextJS, SolidJS and others were interesting because of SSR, but Angular added this too (and continues to improve) in the recent versions.
mlrawlings 11mo ago
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 11mo ago

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 11mo ago
FWIW, marko comes from Ebay. So, it scales - and being primarily SSR, its a better UX than your preferred frameworks
- afavour 11mo ago
  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).
  - nchmy 11mo ago
    Marko did ssr by default, a decade before the other frameworks decided to bolt-on ssr...
  - eyelidlessness 11mo ago
    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 all other frameworks.
    - 11mo ago

wauwboer 11mo ago

[flagged]

ethmarks 11mo ago
hello!

nolanl 11mo ago

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 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 https://www.lorenstew.art/blog/10-kanban-boards

brain_staple 11mo ago
That’s interesting. I’ve always held SvelteKit in high regard for greenfield projects because it balances capability, developer experience, and performance, but I’ll have to give Marko a look. I’d love to see a similar deep dive into Electron style desktop frameworks since that space still feels underexplored compared to mobile. I honestly wouldn’t know where to start for a video game interface, and that bothers me.
CSSer 11mo ago
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 itself to Next.js and embracing the server, it's betrayed the platform. Meanwhile, the platform itself has matured. React practically built my career, and I just don't have a reason to choose it anymore.
- erikpukinskis 11mo ago
  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?
- 11mo ago

pier25 11mo ago

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 11mo ago
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.
- epolanski 11mo ago
  Care to make quite a simple example where file based routing would struggle?
  - Etheryte 11mo ago
    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. If your routing is in code, you can define everything in one place with strict type checks, tests, and so on.
    - array_key_first 11mo ago
      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.

ifh-hn 11mo ago

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 11mo ago

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

quest88 11mo ago
404
- brianzelip 11mo ago
  Oops! https://www.devtools.fm/episode/146 https://www.devtools.fm/episode/146
jt2190 11mo ago
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.

yilugurlu 11mo ago

It reminded me of ColdFusion, which could be something better if it hadn't ended up in Adobe's hands.

tills13 11mo ago

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 11mo ago
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 11mo ago
  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 }))
  - c-hendricks 11mo ago
    There are of course libraries that use JSX and have '<For>' components
  - phatskat 11mo ago
    I’ve never been a fan of JSX. I tried years ago and wasn’t super into it, and then Vue after that and found the syntax a lot easier on the mental model.
- tshaddox 11mo ago
  There are a lot of things people might mean by claiming that something "is just JavaScript," but one possible meaning is that the source code you write can run in the browser without any build whatsoever. For React, that's true with the exception of JSX, which is a very simple and optional syntax transform. (Of course in practice you'll probably want to do module bundling too, but browsers could technically load your ES modules directly from static file storage. For Marko, that doesn't seem to be the case, but it also doesn't really make sense given the problems that Marko is trying to solve. Another thing people might mean by "it's just JavaScript" is a much more subjective notion about how similar the overal syntax, control flow, etc. feels to whatever previous JavaScript experience the person has. This meaning is a lot harder to pin down, and in most cases reasonable people could disagree on what is and isn't "just JavaScript" according to this meaning. That said, I would tend to agree that React's templating uses normal JavaScript control flow and composition primitives more so than Marko.

abraxas 11mo ago

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.

woleium 11mo ago
Yes, we go in circles, but there are subtle (and sometimes not so subtle) improvements every iteration. Of course sometimes there are also dead ends. It is exciting to see what the ingenuity of the next group brings, even though some existing things are lost, but hopefully not forgotten.
- epolanski 11mo ago
  This. Also it cannot be understated: apis, language and tooling are miles ahead better they were a decade ago or more.
  - ricardobeat 11mo ago
    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 analogy would be the brief electric car era of the early 1900s, and React as the Model T.
    - christophilus 11mo ago
      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.
    - array_key_first 11mo ago

andix 11mo ago

I didn't look deep into Marko yet, but in my opinion JSX is by far the best HTML template language there is. And it's not restricted to React. Most other template languages hits serious limitations really fast. I tried and hated (for non trivial things): Angular, Handlebars, Razor (dotnet) and Vue (which does support JSX optionally).

joshdavham 11mo ago
Could you please try to be a bit more substantive with your comments? E.g., Why do you think JSX is the best? What limitations did you hit with those other template languages?
- andix 11mo ago
  Most template languages can't do something like that: // data const numbered = true // or false const strings = ["a", "b", "c"] // render const items = strings.map(i => <li key={i}>Item {i}</li>) if (numbered) return (<ol>{items}</ol>) else return (<ul>{items}</ul>)
  - gigatree 11mo ago
    RippleJS is doing the same sort of thing, but better IMO
  - piercey4 11mo ago
    Marko can! It's "define" tag lets you create reusable templates in your reusable templates. https://markojs.com/docs/reference/core-tag#define https://markojs.com/docs/reference/core-tag#define
deleted 11mo ago
[deleted]
Rendello 11mo ago
I've been liking the model of the Python library Dominate [1]. You write your HTML as regular Python code, and you render() once at the end, having full control over the formatting. Well, at least in theory; in practice the formatting is brittle and the library otherwise makes some choices I don't like. I wrote a Rust library with a more restricted/verbose API, and I've been enjoying using that. Unfortunately, I find it really hard to make it as fast as I want. It's really the perfect use case for arena allocation, but doing that and keeping the API as function calls mirroring HTML is not trivial, and probably requires macros to rewrite the tree as a series of stack pushes. 1. https://pypi.org/project/dominate/ https://pypi.org/project/dominate/

jm4 11mo ago

It looks like they reinvented ColdFusion for modern web apps.

lf-non 11mo ago

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 https://markojs.com/docs/reference/concise-syntax

sings 11mo ago
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.
skrebbel 11mo ago
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.
- piercey4 11mo ago
  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!
  - skrebbel 11mo ago
    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.

ccpzza 11mo ago

For those curious, the Marko team created a HN clone to showcase Marko 6 https://github.com/marko-js/example-hacker-news https://github.com/marko-js/example-hacker-news

deleted 11mo ago

[deleted]

bdcravens 11mo ago

So .... ColdFusion?

jordanscales 11mo ago

Looks absurd. Can't wait to try it.

fuman 11mo ago

[flagged]

debuggerpk 11mo ago

abomination

mattw1 11mo ago

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

rvzx 11mo ago
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.
- mattw1 11mo ago
  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 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.
  - rvzx 11mo ago
    > Nope. They are pretty much all equivalent. Good luck, man.

didip 11mo ago

Honestly, why not just put Scheme on the browser. Scheme is capable to represent HTML JS and CSS all in 1 language.

hansvm 11mo ago

I don't normally comment on formatting, but for a language I assume they're dog-fooding for the demo it's amusing that none of the gradient-backgrounded text renders visibly ("HTML-based", "building web apps", etc).

mobeigi 11mo ago

I love the landing page for this project. It's very engaging.

Antwan 11mo ago

The new jquery? Eurk.

austin-cheney 11mo ago
I thought React was the new jquery.

cubefox 11mo ago

It's misleading to call this "A declarative, HTML‑based language" when it in fact relies heavily on writing explicit JavaScript (which is very different from HTML and not declarative at all). Something like htmx does come a lot closer to being a HTML‑based language in my opinion. So much so that you could add it to the actual HTML spec. (That's not to say that Marko is bad, just that it's more a way to mix HTML and JavaScript in a more intuitive way rather than a declarative, HTML‑based language.)

mcny 11mo ago

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 without requiring any JavaScript When I first heard the term htmx, I thought that was what htmx was but sadly it is just intercooler. What I am asking for requires broad support from browser vendors.

recursivedoubts 11mo ago
We are working to integrated some of the ideas of htmx directly into the HTML specification: https://alexanderpetros.com/triptych/ https://alexanderpetros.com/triptych/
- mcny 11mo ago
  Thank you so much for doing this. I love it!

rapish62 11mo ago

[dead]

davexunit 11mo ago

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.

faldor20 11mo ago

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.