Readit News logoReadit News
nolanl · 4 months 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

I was not surprised for example that Marko came out very well in this performance comparison: https://www.lorenstew.art/blog/10-kanban-boards

CSSer · 4 months 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.
throwingrocks · 4 months ago
SSR isn’t a craze. Web applications have been served that way for literal decades now.
erikpukinskis · 4 months 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?

brain_staple · 4 months 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.
tills13 · 4 months 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 · 4 months 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.
tshaddox · 4 months 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.

fouc · 4 months ago
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", "Selected: " + selected)
            ])
        }
      }

jbreckmckye · 4 months ago
It almost was JavaScript! ES4 was going to have something very similar to JSX tags. Well, an extension to ES4 called E4X
paulddraper · 4 months ago
It is thin syntax sugar.

  <MyComponent prop={value}></MyComponent>
is just

  jsx(MyComponent, { prop: value })
Libraries and apps can use JSX or JS syntax.

erikpukinskis · 4 months ago
I mean, you’re technically correct. But you’re also not understanding the point.

What people mean when they say “React is just JavaScript” is…

1) JSX, more than any other templating system, is just HTML interleaved with JavaScript. It’s HTML, and anything between { and } is evaluated as JavaScript.

2) Inserting a React component’s “HTML tag” in your JSX is _actually_ the same as calling the JavaScript function. The HTML attributes are the function arguments. Yes, inside your function there can be state, and there can be contexts, and there are refs. But you get at all of those things by calling JavaScript functions.

Like,

      <b><MyComponent attr=“yes” /></b>
is literally identical to:

      <b>{MyComponent({ attr: “yes” })}</b>
It’s the tiniest bit of syntactic sugar.

I feel like too many people think “React is Just JavaScript” is some kind of lie people tell to make React sound cool.

It’s not a lie. There’s a _small_ amount of hand waving around the word “just” but the point is, it’s WAY smaller than what you need to explain the ways Svelte or Vue or Angular diverge from plain JavaScript.

Latty · 4 months ago
You can use React with just JS, JSX isn't core to React. htm is a library that uses string templates and is just Javascript but works like JSX and can (but doesn't need to be) compiled down like it, and you can use with with React or other tooling.
tills13 · 4 months 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 }))

ethanpil · 4 months ago
Another interesting approach IMHO is https://github.com/gnat/surreal
notpushkin · 4 months ago
Agreed on the syntax part. We’ve had good syntax for templates before:

  <ul>
    {% for user in users %}
      <li>{{ user.firstName }}</li>
    {% endfor %}
  </ul>
And we have good syntax for templates now:

  <ul>
    {#each users as user}
      <li>{user.firstName}</li>
    {/each}
  </ul>
Why do we have to squish everything into HTML-like-but-not-quite blocks?

But no, JSX isn’t that great either:

  <ul>
    {users.map(user => (
      <li>{user.firstName}</li>
    ))}
  </ul>

cubefox · 4 months ago
Why not use html/XML style syntax rather than mixing two syntax styles? For example, "{/each}" already looks like "</each>".
Already__Taken · 4 months ago
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;

    <ul v-if={users}>
      <li v-for={some in users}>{some.name}
    </ul>

jbreckmckye · 4 months ago
In a past life we did try it... Marko has been around for years.

It started as a project at eBay and then got spun out to an open project around 2015

etothet · 4 months ago
To each their own. This syntax actially resonates with some people, which is why template-based frameworks like Vue and Svelte are also popular. In fact, at first glance this reminds me a lot Vue in some of its approach and syntax.

BTW - with Vue you can use entirely JSX of you dislike HTML component syntax (I don’t know enough about Svelte to know if it allows the same).

prokopton · 4 months ago
Svelte does not allow that.
someguyiguess · 4 months ago
React has not been just JavaScript for a long time. The react DSL just keeps getting more and more bloated as they add more hooks for more and more edge cases (useFormStatus, useActionState, etc…). It’s becoming just another bloated mess now. And I used to love react! This looks promising though. The syntax looks very straightforward. Even though it’s not “just JavaScript” it is very easily understood by most programmers. I’ve glanced at it for all of 2 minutes and it all makes perfect sense. Functions look like functions. Variables look like variables. I think it looks cool!
moritzwarhier · 4 months ago
Really, this point can't be stated often enough.

It was my reason for switching to React when I learned TypeScript after getting more into JS frameworks via Vue.JS.

My starting point was Vue 2.7, and I started out using string templates haha :)

Even wrote some reactive custom code (without Vue, just regular DOM code) in a customer widget that utilized Object.defineProperty et al, inspired by Vue.

And today, while I'm using React at $job, I also think Vue 3 is probably a solid framework as well.

Last time I checked, they improved on DX of their component and templating system. But I'm not even sure whether they still recommend the v-if etc helper tags.

For what it's worth, even Vue 2 always also supported JSX and later TSX

Deleted Comment

iammrpayments · 4 months ago
Do you really believe React is just javascript?
pwdisswordfishy · 4 months ago
React is "just JavaScript" that you have to write in a very particular way, which the language in no way helps you enforce, for otherwise your "web app" will misbehave is bizarre and confusing ways.
DonnyV · 4 months ago
No Vue, is just JavaScript. React is JSX.
promiseofbeans · 4 months 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?

mlrawlings · 4 months 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

sorrythanks · 4 months 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

bitwize · 4 months ago
JS inside HTML! Groundbreaking! It's nothing like Netscape ever conceived in 1995...
mcny · 4 months 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 · 4 months ago
We are working to integrated some of the ideas of htmx directly into the HTML specification:

https://alexanderpetros.com/triptych/

mcny · 4 months ago
Thank you so much for doing this. I love it!
abraxas · 4 months 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 · 4 months 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 · 4 months ago
This.

Also it cannot be understated: apis, language and tooling are miles ahead better they were a decade ago or more.

gf000 · 4 months ago
We also had JSF, which was even cooler - being able to reconstruct the state server-side. It was ridiculously fast to write complex form-driver websites with that! No DTOs/schemas in different languages, no worry about how the client calls the server, what happens if it fails, etc.

The only problem is that it won't necessarily scale to some insane numbers without some care.

(Not sure why the past tense, it does work and developed still)

Jenk · 4 months ago
> It was the correct paradigm all along

Debateable.

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

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

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

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

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

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

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

someguyiguess · 4 months ago
I’d venture to say that the idea of a “correct paradigm” is based on a false premise. Why would there be one paradigm to rule them all? Maybe there is more nuance. Maybe certain paradigms are better for certain applications.
notnullorvoid · 4 months ago
I'd go a bit further and say certain paradigms may be better for certain people.
croisillon · 4 months ago
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

joshdavham · 4 months ago
Oh wow! So I guess Marko has been around for while. Despite that, this is my first time hearing about it.
ricardobeat · 4 months ago
The main author also wrote morphdom circa 2015, which is/was used in htmx and sprung up a bunch of other frameworks.
ccpzza · 4 months ago
For those curious, the Marko team created a HN clone to showcase Marko 6

https://github.com/marko-js/example-hacker-news

lf-non · 4 months 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

skrebbel · 4 months 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 · 4 months 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!
sings · 4 months 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.