undefined | Better HN

0 pointsdmix1y ago0 comments

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…

0 comments

4 comments · 1 top-level

stevage1y ago· 3 in thread

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.

dmixOP1y 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.

stevage1y 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

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.

KronisLV1y 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)

j / k navigate · click thread line to collapse

0 comments

4 comments · 1 top-level

stevage1y ago· 3 in thread

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.

dmixOP1y ago

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.

stevage1y ago

> 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

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.

KronisLV1y 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)

j / k navigate · click thread line to collapse