I prefer Pug with Vue3. Your example would be:

``` li.card.card-body.fw-bold.small(v-if="items.length > 2" v-for="{ id, text } in items" :key="id") | {{ text }} ```

Personally I find this really readable. The HTML element is the most visible thing, then we get classes, then all the logic in parentheses. Then, standing by itself, the content. And we don't need any closing tag.

Those smaller template languages make it really hard to switch to another system in the future. The further you stray from HTML the more technical overhead you’re creating for yourself and others in the future, just to save a small amount of time on template code which IDEs heavily automates now (closing tags, refactoring, etc).

It also makes debugging harder because there’s a heavier translation of stuff you see in dev tools vs your codebase. It also makes gripping and automated project code replacement harder.

You also can’t easily copy paste HTML code examples from other places. Other developers have to learn and might resist it so you have a mix of template systems.

I could keep going…

First, the point of pug is not saving time typing. It's creating a more readable format.

I have never needed to move pug code to non pug. If I switched from Vue to Svelte I'd keep using Pug.

I have sometimes needed to do the opposite. There are tools to automate it, but even manually it's much less effort than say converting Vue to React.

Lastly, the promise of your comment, that technical debt is always an important consideration in all projects, is not correct.

How big is your team? How many people touch it? Are you leaving it for the next developer to deal with after you leave? Have you dealt with hiring? Does your platform 100% stay in JS/pug or do you mix it with backend views?

There's a million considerations.

Ruby on Rails went through this over a decade with HAML with wide scale adoption and it was largely a mistake, projects always end up moving back to HTML. Or into JSX or whatever HTMLy syntax.

I've worked on at least 3 or 4 projects that switched JS frameworks and stuff like pug would always be burden on moving over.

Ive been down that rabbithole enough times and it's simply not worth the mostly overstated DX benefit. Nerds trying to be hyper efficient in the wrong ways.

Simpler and closer to standards is always always better.

> How big is your team? How many people touch it? Are you leaving it for the next developer to deal with after you leave? Have you dealt with hiring? Does your platform 100% stay in JS/pug or do you mix it with backend views?

> There's a million considerations.

Exactly. I'm speaking from my experience in my situations.

> dmix 22 hours ago | parent | context | flag | on: Svelte5: A Less Favorable Vue3

How big is your team? How many people touch it? Are you leaving it for the next developer to deal with after you leave? Have you dealt with hiring? Does your platform 100% stay in JS/pug or do you mix it with backend views?

There's a million considerations.

> Ruby on Rails went through this over a decade with HAML with wide scale adoption and it was largely a mistake, projects always end up moving back to HTML.

No they don't. Perhaps the most visible projects do. Perhaps there is an overall trend. Even if projects change from one tech to another, it doesn't mean the original choice was a mistake.

>Ive been down that rabbithole enough times and it's simply not worth the mostly overstated DX benefit.

[to you]

I have not seen any statements about Pug's "DX benefit" to know, but I do find I greatly prefer it, to the point where I'm willing to put in the work to enable Pug in any project I'm allowed to.

> Nerds trying to be hyper efficient in the wrong ways.

Just throwing a needless insult out there?

>Simpler and closer to standards is always always better.

"Always always" is never never right.

> Nerds trying to be hyper efficient in the wrong ways.

> Simpler and closer to standards is always always better.

I don’t entirely disagree, but if it’s fewer migrations between stuff and less churn that you’re after, at that point you might either:

A) go in the direction of something like HTMX for suitable problems (or tbh most SSR approaches without the complexity of neither SPAs nor hydration)

B) alternatively find the most milquetoast yet batteries included option out there, like Angular (and hope that something like AngularJS doesn’t happen)

Yeah, regular HTML is overly verbose. Being able to compose JSX generating functions and using regular JavaScript logic for loops, conditions etc. wins out for me though because realistic HTML gets big and messy otherwise. Can you do something like this in Pug? (where the actual HTML would be more complex, so you'd want to split it up like this)

    const elToolbar = generateToolbar(toolbarItems) // returns JSX
    const elUserCards = users.map(user => <div class="card card-body fw-bold">{{ user.name }}</div>)

    return <div>
        {elToolbar}
        {elUserCards}
    </div>

I find doing something similar with Vue HTML templates has far too much boilerplate, and I have to learn/recall all this Vue specific boilerplate instead of using regular functions so I end up not breaking up my HTML as much. Unless there's a way to do something similar within in a single file?

> Can you do something like this in Pug?

https://pugjs.org/language/mixins.html

Any particular part? I'm maybe not following the specifics, but this is similar to the `elUserCards` example I gave? JSX is regular JavaScript, so you can use regular functions, maps, variables, default arguments etc. to generate repetitive HTML, just like you would to generate repetitive strings or JSON, without having to learn a new language.

This approach is a classic footgun for beginners in the context of "hook rules". In general it's quite fragile.

Can you explain more? You're talking about React (hooks) here? Or this applies to Vue + JSX as well?

It's React thing. In maintenance context it's always better to not extract component instantiation. They could start to use hooks or they could be wrapped in conditions in a parent component and it would lead to severe quite hard to find issues.

This is a bonus of using Vue then if this kind of code doesn't pose a problem there?

Makes me wonder why this is all so difficult. Vue has a lot less problems for me than previous iterations and frameworks, but it's still frustrating how many footguns still exist. Like gotchas where you lose reactivity where linters/compilers won't catch the problem for you, and you forget the gotchas if you're not immersed in that framework for a while.

I'm not getting why we can't have robust static checking for this stuff vs trusting every developer to be careful.

Yep. I prefer Vue myself — no need to stay on toe tips full time. It's really a question of available ecosystem and quite phenomenal React's backward compatibility which ties very agile in other circumstances FE devs to the framework.

Pug templates have been the most readable in my projects. Underappreciated imho, wish Astro also supported it.

Agree, but isn't the project very low in activity?

https://github.com/pugjs/pug/activity

That is not necessarily a bad thing, sometime stability is what matters the most. But here the last commit was removal of a security and bugs branch...

Pug has been pretty complete for quite a while, there just isn't that big of a potential for insecurity for something that becomes vue's html/jsx at build time and 99% of run time threats is basically that the dev sent unsanitized use input to v-html instead of v-text.

The main problem with pug is that, AFAIK, vue is the only modern webframework with stable support for it.

I loved using Pug with Vue, but after coming across issues with tooling integration (e.g. eslint) too many times, I've returned to the default templates.

The one thing that bugs me tremendously with Vue template syntax is slots. They are so annoying to use and hardly visible in code completion. Passing template/HTML fragments as props is so much nicer in JSX. This is the only reason, why I even consider using JSX instead of Vue's template syntax. Thus, I'm very much interested in your experiences with Vue+JSX. Especially in regards of (third-party) tooling support. While JSX is officially supported by Vue, it does not seem to be encouraged and may have subpar support in the ecosystem. But that is only something I'm afraid of, I do not have any experience with it, yet.

> Passing template/HTML fragments as props is so much nicer in JSX.

Ha, I do this in places but I'm not sure if this approach is encouraged? Compared to slots, I like this too, it's a lot less verbose and the syntax is simple and easy to remember.

> While JSX is officially supported by Vue, it does not seem to be encouraged and may have subpar support in the ecosystem. But that is only something I'm afraid of, I do not have any experience with it, yet.

Worst case, you can switch to Vue HTML templates in some files and use JSX in others. I've not found issues mixing them together like this.

Does this also allow you to write multiple components in one file? I guess there wouldn’t be a problem with it if you use the primitive inside of a normal JS file.

I’ve seen the third party package for the compiler that has popped up to try and handle this, but I don’t like the limitations.

I’m hoping with Vue 4 they will find a way to support multiple components in one SFC file (which kinda violates the naming but hey…)

> Does this also allow you to write multiple components in one file? I guess there wouldn’t be a problem with it if you use the primitive inside of a normal JS file.

Yes, as in a component would be a regular JavaScript function that takes some parameters and gives you back some JSX to render. It's really concise and there's no need to muck around with plugins or anything special, it's just regular JavaScript.

When I'm working on projects that use Vue HTML templates, I've often got pages that have some small HTML snippet that appears two or three times, and just don't want to go through the effort of having to break the snippet out into its own component file because its so verbose. JSX makes this really low friction so you do it more often.

I have only tried your approach on small side projects. I quite liked it, for the reasons you mention.

And for one more reason: the only tooling needed is esbuild, which can handle TSX. No finding a Vue SFC plugin, just a single dependency and you're off.

(Of course you'll probably also want to install typescript itself as IDE type checking isn't adequate for a real project.)

Yeah, I like that JSX is built into TypeScript like this so it's more standardised with less tooling required. JSX is probably less likely to change given its relatively wide usage compared to each framework having it's own template language and JSX is well supported by linters and formatters too.

Personally i prefer to put v-for/v-if/else in a separate <template> tag. It makes it easier to identify and makes order explicit

Awesome! How do you use Vue with tsx/jsx?

This documentation is pretty good for this, it's a supported option rather than something you have to hack in but I rarely hear it mentioned:

https://vuejs.org/guide/extras/render-function.html#jsx-tsx

Edit: Yes, oops, wrong link.

I think that link should be: https://vuejs.org/guide/extras/render-function.html#jsx-tsx

Oh right, sorry I thought that was docs for the original vue-templates. Should have checked.

Do you happen to know if I can I use my own bundler set up with this? (esbuild, rspack, etc?)

When you set up a project it asks you if you want to use jsx afaik