3 ms·

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 Vu

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.
- KronisLV 2y ago
  > 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)

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.
KronisLV 2y ago
> 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)