23 ms·

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

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.

luminarious 2y ago
Pug templates have been the most readable in my projects. Underappreciated imho, wish Astro also supported it.
- psychoslave 2y ago
  Agree, but isn't the project very low in activity? https://github.com/pugjs/pug/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...
  - antifa 2y ago
    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.
deleted 2y ago
[deleted]
seanwilson 2y ago
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?
- bvrmn 2y ago
  This approach is a classic footgun for beginners in the context of "hook rules". In general it's quite fragile.
  - seanwilson 2y ago
    Can you explain more? You're talking about React (hooks) here? Or this applies to Vue + JSX as well?
    - bvrmn 2y ago
      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.
      - seanwilson 2y ago
        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.
        bvrmn 2y ago
        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.
- gbuk2013 2y ago
  > Can you do something like this in Pug? https://pugjs.org/language/mixins.html https://pugjs.org/language/mixins.html
dmix 2y ago
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…
- stevage 2y ago
  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.
  - dmix 2y ago
    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.
    - stevage 2y ago
      > 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.
Timon3 2y ago
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.

luminarious 2y ago

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

psychoslave 2y ago
Agree, but isn't the project very low in activity? https://github.com/pugjs/pug/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...
- antifa 2y ago
  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.

deleted 2y ago

[deleted]

seanwilson 2y ago

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?

bvrmn 2y ago
This approach is a classic footgun for beginners in the context of "hook rules". In general it's quite fragile.
- seanwilson 2y ago
  Can you explain more? You're talking about React (hooks) here? Or this applies to Vue + JSX as well?
  - bvrmn 2y ago
    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.
    - seanwilson 2y ago
      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.
      - bvrmn 2y ago
        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.
gbuk2013 2y ago
> Can you do something like this in Pug? https://pugjs.org/language/mixins.html https://pugjs.org/language/mixins.html

dmix 2y ago

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…

stevage 2y ago
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.
- dmix 2y ago
  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.
  - stevage 2y ago
    > 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.

Timon3 2y ago

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.