Marko: An HTML-Based Language

Is there anything that would out of the box: 1) do fully static server-side rendering that outputs zero JS by default, 2) still be capable of rendering client-side interactive components where appropriate (for user agents with JS), 3) have both of the above as equal first-class citizens without contrived workarounds needed to achieve either interactivity or SSR, 4) handle all required bundling/fetching at build stage and load fast at runtime, 5) be isomorphic and leverage TypeScript typings to validate the correctness of the whole thing at build time as much as possible, and ideally 6) allow easy reuse of preexisting React components?

"my use case doesn't need a JS framework so we don't need JS frameworks"

But I think the general principle applies, and you can even go further: try building simpler things. This is why I use static websites + a little JS and some API calls until I absolutely need my own server/SPA/etc.

Also, this trope that "JavaScript can only render websites that require JavaScript to read" is a common misconception. Next.js, for example, is perfectly capable of rendering websites that work for clients with JavaScript disabled. In fact, that was kind of the original point of SSR: to make websites that search crawlers could read by processing the HTML sent from the server. The server renders the initial page, and then the client (optionally, if following best practices) "hydrates" the DOM to render any further content that requires client-side interaction (indeed, it's bad practice to require hydration, and a mismatch between server rendered DOM and hydrated DOM will generate warnings in development).

slim-lang + htmx or stimulusjs and a single dev can replace a team.

They provide some opinionated/convenient ways to author code but deliver fully server-side rendered HTML. They use fancy means to detect where interactivity is needed, and only ship JavaScript to the browser for those components.

In fact, they make what you describe easier to achieve. When you do it on your own, it’s up to you to ensure one piece JavaScript doesn’t mess another piece up, it’s up to you to sync back-end with front-end—but with a good framework you get encapsulation, bundling, and typing with compile-time checks (if you removed an attribute from some object server-side but forgot to update the client side, your build will fail with a useful error message before you can deploy it).

I run Marko on cloudflare pages for some of my clients and couldn’t be happier, it’s the perfect framework for people who like writing plain html, but still want the advantages of a UI library like react.

I’d expect Qwik to be faster than any of the above, but it seems not quite production-ready enough.

[0] https://dev.to/this-is-learning/marko-for-sites-solid-for-ap...

[1] In the Reddit the author mentions that, despite focusing on Solid+Astro in the article, Marko is actually still more performant than those: https://www.reddit.com/r/javascript/comments/ubs6i9/marko_fo...

Same with HTML streaming. Marko has had it since 2014 and IIRC SvelteKit doesn't have it yet.

I absolutely love Svelte but if you need those features then Marko would be a better choice.

It looks like Marko v6 is going to perform incredibly fast, up there with vanilla javascript and solidjs, ahead of Vue, React, and Angular. https://dev.to/ryansolid/marko-compiling-fine-grained-reacti...

What's interesting is Marko and Solid are opposite in some ways: the first is HTML first, with sprinkles of interactivity; and the second is JavaScript first, in that it uses JavaScript and JSX primarily. Despite these opposite approaches, they are both iterating towards having very little runtime overhead.

Solid has definitely gained more traction recently and the syntax is close to react, but Marko is really closer to Solid + SolidStart, and the upcoming major version will bring resumability which only Qwik offers at the moment.

By definition, controllers must be imperative.

Would've been that better if you had some `increment(state)` that updated a ref anyway?

"Trust me, this thing -- which is very new -- will be around forever".

    <h1>My favorite colors</h1>
      <ul>
        <cfloop item="color" list="red,green,blue">
          <cfoutput>
            <li style="color:#color#">
                #ucase(color)#
            </li>
          </cfoutput>
        </cfloop>
      </ul>
    <cf_SharedFooter/><!--- ColdFusion custom tag --->

I wrote ColdFusion professionally for 7 years in the mid-'00s and I quite liked it back then. The issue, of course, was code organization and sprawl because you couldn't easily detach the logic from the view.

Still, <cfquery> blocks and <cfloop>s around the results were one of the fastest ways to get something up on a page and working, in the days before very mature frameworks existed yet.

It also forced everyone to know everything, so you could point to any dev on the team and they mostly understood the HTML, the CSS, the JS on the page, and the backend.

I think the industry trend toward specialization is useful in some cases, but it has made organizations and products almost intolerably complex in many cases where it isn't strictly necessary for the product itself.

In frontend engineering where there is a separation of logic and presentation you end up with flimsy, broken code. We used to write websites in html and then add some js that targeted specific elements and that was impossible to maintain.

Component based frameworks do away with all that because it doesn’t work. In react you’re mixing logic with your html too through jsx and this framework (and others like vue/svelte) go a step further and put everything related to a fragment of html in a single file.

This works really well, it means your styles don’t leak unless you want them to, your js usually only affects the html in the same file it’s written and you can build robust apps.