yes! I just don't understand that as well. Up until some time ago claud code's preferred install was a npm i, wasn't it? Please serious answers for why anyone would use a web language for a terminal app

Because it's what the person writing it's preferred language.

So it can share code with the web app.

Because writing it in javascript is easier than writing it in raw brute forced assembly.

3 source files, nice code, no vibe-coding slob, nice little project... That's rare these days

Bat is nice. Oh dang now i have to try this plugin. I remember trying a couple of similar ones that got me so frustrated that i abandoned the idea of markdown viewers in nvim... Here we go again XD

render-markdown.nvim is very nice and works with GitHub Flavoured Markdown, even down to some of the newer features like INFO, IMPORTANT, etc. quotes.

Just as the modern Javascript applications. What if - and hear me out on this one - Javascript just is a poor choice for huge complex codebases?

What else should you use for huge complex web apps?

Keep the huge, complex business logic on the server whenever possible.

That doesn't work for webapps that are effectively entirely based on client side reactivity like Figma, though the list of projects that need to work like that is extremely low. Even for those style of apps I do wonder how far something like Phoenix LiveView might go towards the end goal.

maybe, just maybe, the browser is not always the best tool for the job

I think that there are more apps that are better off as web apps (cross platform and sandboxed) than not.

<3 if I don't see 15 new node modules and 3 CVEs by EOB today I'll replace you with a css architect and vibe-coding nft monkey by next week!

Why they call pipes filter? And if... endif? Not for me

This is a Rust port of the Ruby implementation which was popularized by Jekyll, so it just does whatever was done in the Ruby implementation.

For an overview of liquid itself, see https://shopify.github.io/liquid/

Mass of learning material doesn't equal quality though. The amount of poor react code out there is not to underestimate. I feel like llm generated gleam code was way cleaner (after some agentic loops due to syntactic misunderstanding) than ts/react where it's so biased to produce overly verbose slob.

Grepping "extends" over a new codebase is a quick way to see how fucked you are when joining a new project/team.

I literally couldn't care less. You can call it '1th of April' for all that i care if the actual functionality you offer is clean and fast I'll gladly accept!

I get where the author is coming from, but having grown up in the 80's, I always thought "1 item(s)" looked slightly _more_ professional since it followed the way printed documents were usually produced.

> You can choose to use it (macros) or not.

Yet both examples use macros.

I might still got ptsd from a job where literally all of the rust codebase was written as macros. Since then I avoid them at all costs.

I find the route, that gleam took, way more elegant with squirrel (sqlx-ish) and lustre (elm-like) being examples of what we could have instead. Avoiding language mixing is so important for proper/clean lsp-support - yet macros are a different language as i see it.

As for the rest of this: i also don't see how it's any different from iced, egui etc. but maybe I didn't take the time to check the details...

Uh, what? The second DSL example is just pure Rust.

> btn.finish().with_child(pipe!($read(cnt).to_string()))

That second macro isn’t for constructing UI, which is the point of the two examples.