Official project status update

[ghost]

I'd like to say thanks for all the time and effort you've put in over the years. I've used jade/pug across many projects and companies and have a lot of love for it. With that being said, it doesn't seem like pug is maintained at this point. It's completely understandable if you're busy or have simply moved on to greener pastures. Whatever the reason may be, is it possible to get an official status update on pug @ForbesLindesay?

On a side note, would donations to pug's Open Collective page make any difference, or is pug considered pretty much done/inactive at this point? I'm assuming there is no v4 in the works but was hoping to get some kind of confirmation in terms of pug's future or perhaps a notice added to the readme / npm package.

Thanks (and much ❤️ for 🐶)!

[carlosvigil]

Have you found an alternative or replacement? @mmarti

[david-szabo97]

@ForbesLindesay Would you happen to have any updates for us?

[TokugawaTakeshi]

Have you found an alternative or replacement?

Looks like there is no similar pre-processor yet.
Even it will be, it could be easily abandoned because unfortunately the pre-processors are the packages kind which being
frequently abandoned.

The Pug is the best HTML-preprocessor because is have maximal functionality with minimal syntax.
There are just few things which I wish to be added, but it is already near the ideal.
It will be really hopeless if the Pug will be completely addended because stopping of the using the Pug will be HUGE performance and maintainability impact.

[matheusmoreira]

I'd also like to know. Pug is a vast improvement over writing HTML by hand. I just started using it for my site.

[TokugawaTakeshi]

Being the active Pug user, I am really worrying about Pug future.
Pug has perfect balance of syntax simplicity and functionality, and it has the potential for upgrades.
It will be really terrible if someday for some reason such as incompatibility with newest Node.js we have to return to plain HTML.
Pug is not just the method of type HTML more quickly - it is really powerful template engine.

Because there is no reaction from the Pug developers for the year, I think it's time to consider the forking of the project or rewriting of it by the community. Looks like the "@pug" scope already has been used in npm, so we need the another one. Or, we can ever assign the new name to this template engine.

Please feel free to share your opinion about this suggestion.

[Bessonov]

Ping @svallory because of #3410 .

[matheusmoreira]

Since this repository is apparently unmaintained, I forked and adapted pug for my static site generation needs. Although similar, it is not pug anymore. So I called it something else:

Pugneum

Feel free to use it if you find it useful. I plan to maintain it over time since I'm using it for my own site. It is my intention to keep it as small a system as possible for ease of maintenance and understanding, so I deleted a lot of dependencies and dynamic features, making it a fully static HTML template language.

[TokugawaTakeshi]

@matheusmoreira

Thank you for the leading of the development of the new generation of the Pug pre-processor.

We need to think how to motivate the sponsors to invest to your project which will keep your motivation high too.
I suppose, first of all we need to decide which features will be in Pug 4.

Personally I will be glad if:

• The slots similar to Vue slots will be supported
• Better support of ideographic languages will be
• The inline TypeScript will be instead of inline JavaScript (sounds crazy until you will start to develop the UI kit using Pug language)

Please consider the roadmap in README.md.

Well, I suppose we can't continue these discussions here.
Thank you for the providing of the discussions in the Pugneum repository.

[matheusmoreira]

We need to think how to motivate the sponsors to invest to your project which will keep your motivation high too.

I would greatly appreciate that. I'm currently working on it on my free time which is limited and split across other personal projects.

I'd also appreciate contributions, issue reports, even new test cases for the test suite which does need a lot of work.

I suppose, first of all we need to decide which features will be in Pug 4.

Respectfully, I plan to take the project in a somewhat different direction relative to the original pug. So I'm not sure it is appropriate to think of it as its successor. I have already significantly altered the language.

Personally I will be glad if:

• The slots similar to Vue slots will be supported

These slots are apparently equivalent to mixins which are supported by both the original Pug and Pugneum.

mixin example
  article
    section
      block

+example
  p This content
  p will replace
  p the block keyword.

Please correct me if I'm wrong.

• Better support of ideographic languages will be

I agree. I'm not satisfied with the whitespace control and have plans to improve it. I'm currently revamping the lexer and parser so they will be easier to work with. Then I'm gonna come up with better ways of controlling whitespace which will hopefully resolve your issue.

• The inline TypeScript will be instead of inline JavaScript (sounds crazy until you will start to develop the UI kit using Pug language)

I will not support either language in my fork. The support for inline Javascript was one of the features I deleted.

My goal is to develop a better way to write pure HTML. I will understand if this is a deal breaker for most.

[svallory]

@Bessonov thanks for the ping. I'm very interested in the future of Pug. I created a DSL using Pug mixins but started running into lots of issues, so I thought I would fix them. Since it would take a long time to understand the project anyways, I thought converting it to Typescript would be a great way for me to learn and make entrance easier since TS brings better type checking and code navigation via LSP.

Since then though I've learned about @marko-js's Marko and it's concise syntax which is not the same, but very similar to Pug and I'll probably re-implement my language using it

@carlosvigil and @TokugawaTakeshi you may wanna take a look at Marko. At least for me, the syntax is close enough. They also expose a compiler API which is probably be enough if someone wants to make it more pug-like.

@matheusmoreira I think what you are doing may pair very well with htmx

[matheusmoreira]

@svallory

I did evaluate a lot of existing software including htmx but they were all based on regular verbose HTML which is exactly what I set out to avoid in the first place. I even asked people in several communities if they knew of an alternative but they did not. Ended up forking and customizing pug.

I was not aware of marko though which is VERY interesting! Despite all that research into prior art, I didn't find it. I really like its concise mode! Especially its text node syntax. I'll certainly be studying it for inspiration. I really hate pug's pipe syntax and would like to replace it with something better. The marko syntax looks really good and also seems easy enough to adapt for better whitespace control which will fulfill @TokugawaTakeshi's requirements.

It does have a lot of programming features that I have decided are out of scope for my project such as inline code evaluation, parsing of values as Javascript expressions rather than simple strings. From a cursory look, it also apparently lacks templating features which I do consider vital for reducing repetition in pages such as extend and mixin, the latter being just a form of function call really. Do correct me if I'm wrong.

Anyway, I spent quite a lot of time reading and understanding the pug lexer and parser code in order to customize them and safely delete the features I didn't want. If you change your mind about pug, perhaps we could collaborate.

[svallory]

Hey @matheusmoreira, sorry for the delay :/

I did evaluate a lot of existing software including htmx but they were all based on regular verbose HTML

I guess you got what I said the other way around. What I was suggesting is that your project could replace the HTM of HTMX to give birth to PugneumX ;) (you may want to rething that name though)

lacks templating features which I do consider vital for reducing repetition in pages such as extend and mixin

They are there, but the mental model is a little different:

Mixins

Can be implemented in two ways depending on the complexity:

Using Macros

Or variables

Templates

These should become components (which do not require any javascript)

components/layout.marko

Then you simply use the component and the named body feature

And the "templating" functions of marko go way beyond extend/block. You have

Repeatable attribute tags

Which can be nested, take attributes, and be defined dynamically

And here's how simple the fancy-table component is to implement

components/fancy-table/index.marko

<table class="fancy">
    <tr>
        <for|column| of=input.column>
            <th>
                <${column.heading.renderBody}/>
            </th>
        </for>
    </tr>
    <for|row| of=input.data>
        <tr>
            <for|column| of=input.column>
                <td>
                    <${column.cell.renderBody} ...row/>
                </td>
            </for>
        </tr>
    </for>
</table>

FULL DISCLOSURE: I do NOT work on the Marko team (or eBay) and I'm not about to sell you a MarkoJS course hahaha

I just really like it and wanna see it become a well spread framework. I do prefer how Pug handles inline content and text. Especially the filters feature that was really useful and it shouldn't be too hard to implement usin compiler hooks and the @marko/babel-utils package

[Rush]

Since this repository is apparently unmaintained, I forked and adapted pug for my static site generation needs. Although similar, it is not pug anymore. So I called it something else:

Pugneum

Feel free to use it if you find it useful. I plan to maintain it over time since I'm using it for my own site. It is my intention to keep it as small a system as possible for ease of maintenance and understanding, so I deleted a lot of dependencies and dynamic features, making it a fully static HTML template language.

Unfortunately it looks like it's not a true fork then if you removed some core features. Unfortunate.

[pecopeco]

Hey @matheusmoreira, sorry for the delay :/

I did evaluate a lot of existing software including htmx but they were all based on regular verbose HTML

I guess you got what I said the other way around. What I was suggesting is that your project could replace the HTM of HTMX to give birth to PugneumX ;) (you may want to rething that name though)

lacks templating features which I do consider vital for reducing repetition in pages such as extend and mixin

They are there, but the mental model is a little different:

Mixins

Can be implemented in two ways depending on the complexity:

Using Macros

Or variables

Templates

These should become components (which do not require any javascript)

components/layout.marko

Then you simply use the component and the named body feature

And the "templating" functions of marko go way beyond extend/block. You have

Repeatable attribute tags

Which can be nested, take attributes, and be defined dynamically

And here's how simple the fancy-table component is to implement

components/fancy-table/index.marko

<table class="fancy">
    <tr>
        <for|column| of=input.column>
            <th>
                <${column.heading.renderBody}/>
            </th>
        </for>
    </tr>
    <for|row| of=input.data>
        <tr>
            <for|column| of=input.column>
                <td>
                    <${column.cell.renderBody} ...row/>
                </td>
            </for>
        </tr>
    </for>
</table>

FULL DISCLOSURE: I do NOT work on the Marko team (or eBay) and I'm not about to sell you a MarkoJS course hahaha

I just really like it and wanna see it become a well spread framework. I do prefer how Pug handles inline content and text. Especially the filters feature that was really useful and it shouldn't be too hard to implement usin compiler hooks and the @marko/babel-utils package

marko is not a pure template engine, its purpose seems to be to replace react or vue

[svallory]

marko is not a pure template engine, its purpose seems to be to replace react or vue

It has that power, but you can also use it as a pure template engine

https://markojs.com/docs/rendering/

[Rush]

For what it's worth, pug works quite well to this day. The only issue is lack of new tooling being available.

[TokugawaTakeshi]

@Rush

For what it's worth, pug works quite well to this day. The only issue is lack of new tooling being available.

You right, but the vulnerabilities could be detected anytime. AFAIK currently no maintainer to fix them.

Well, the fork is possible for the Pug repository. What is left? Assemble a team, create the community on Open Collective and invest some money?

[Rush]

It'd need quite a bit of bravery and spare time to tackle this. Ten years ago, I might have jumped at the chance, but these days, both life and work keep me busy enough without adding more projects to my plate.

If there's a fork project to support, I'd happily support it. Pug is still the best template engine that exists and it deserves life-support or a next-gen continuation.

[matheusmoreira]

It'd need quite a bit of bravery and spare time to tackle this.

Yeah no doubt. I forked it and started maintaining my own incompatible version. I made it a point to delete the features I didn't need. It's still a surprisingly complex piece of software. My fork currently builds my own website but there are many things that I couldn't quite figure out how to change. At least not quickly and without breaking the test suite. It's an adhoc hand written parser. At some point I started to wonder if it would be easier to reimplement it with Nearley.

Truth is it successfully builds my website so I have kinda moved on because life's too short and I want to work on my other projects too. I did manage to get rid of all the known vulnerabilities tho.

Pug is still the best template engine that exists and it deserves life-support or a next-gen continuation.

No doubt. Cleanest way to write HTML.

[svallory]

For what it's worth, pug works quite well to this day. The only issue is lack of new tooling being available.

That isn't true if you start building complex mixins. I ran into a lot of issues!

At some point I started to wonder if it would be easier to reimplement it with Nearley.

I've wondered about the same thing. And I think the answer is yes. The tools available today for creating languages are much more advanced. I don't know of Nearly, but I can recommend @eclipse-langium

No doubt. Cleanest way to write HTML.

yep!