I starting to realize I don't like Pug | Poal: Say what you want.

168

•

It's not that I don't like the templating format. In fact I really like the format.

But I'm obsessed with performance and changes in how nodejs is done (thanks to ES6) has made me start to think more critically about how I code in terms of how I measure performance.

The measure I use for performance is different than other people. My criteria for a properly built applications are...

Uses the bare minimum ram except for things cached that actually improve performance.
Instant upstart, usualying involving what I call lazy starting.
Product delivered to the client is correct.
Is always asynchronous

So I had coded my own wrapper to pug a long time ago, back when it was called jade, and I'm glad I did for reasons I will get into later. But what it does is returns a function that takes (httprequest, httpresult, options) and compiles the file when it is first needed.

This means that the server is ready to run right away in spite of the fact that there is a lot of pug on it that won't get used that often but still might get used.

Well this has become a problem with ES6 because I do have a little bit of inline javascript (conditional javascript that either exists or doesn't based on an option fed to the template).

Well I like ES6 features but I noticed that it was breaking some devices. So I needed to put babel into the mix. It's pretty easy.

In terms of pug it's just converting:

doctype html
html
 head
  script.
   $(()=>{
    //do something
   });

doctype html
html
 head
  script
   :babel
    $(()=>{
     //do something
    });

You only have to configure your babel rc to do the correct conversion. This would also allow you to embed react. Also with some more babel you can actually embed pug into react so you could embed pugish react into your pug.

But this is a problem for my lazy compilation. Now the first user to access a particular page on a server after a restart has to wait about 10 seconds which makes it seem like the host just isn't working. Unacceptable.

So long to the short I started digging through the code to try to code a solution around this. I wanted to create something I would call a .pugs file that is pug but could be simplified down into something the server could load lazy very fast. Ideally I would like it to output an es5 version of the pug but I don't need that and I've realized that can't be done. All I really care is that it can be loaded into a functioning template.

So then the goal was to look at what the internal representation of the template is after it is compiled. You can't read that without looking at the code because the returned function is a clousure.

So what do I find when I read the code? fs.readFileSync. It's been violating my performance standards this whole time and it's creating a mess for maintaining them with es6.

So what I'm tempted to do is rewrite pug to my standards, including asynronous file reads, automatic lazy file compilation and watching, the ability to cache internal representation to disk for quick restart, and I'll even throw lazy requires in there while I'm at it...

Or I could just pick up a new template engine that does 90% of what I need without doing that.

It's not that I don't like the templating format. In fact I really like the format. But I'm obsessed with performance and changes in how nodejs is done (thanks to ES6) has made me start to think more critically about how I code in terms of how I measure performance. The measure I use for performance is different than other people. My criteria for a properly built applications are... + Uses the bare minimum ram except for things cached that actually improve performance. + Instant upstart, usualying involving what I call lazy starting. + Product delivered to the client is correct. + Is always asynchronous So I had coded my own wrapper to pug a long time ago, back when it was called jade, and I'm glad I did for reasons I will get into later. But what it does is returns a function that takes (httprequest, httpresult, options) and compiles the file when it is first needed. This means that the server is ready to run right away in spite of the fact that there is a lot of pug on it that won't get used that often but still might get used. Well this has become a problem with ES6 because I do have a little bit of inline javascript (conditional javascript that either exists or doesn't based on an option fed to the template). Well I like ES6 features but I noticed that it was breaking some devices. So I needed to put babel into the mix. It's pretty easy. In terms of pug it's just converting: doctype html html head script. $(()=>{ //do something }); to doctype html html head script :babel $(()=>{ //do something }); You only have to configure your babel rc to do the correct conversion. This would also allow you to embed react. Also with some more babel you can actually embed pug into react so you could embed pugish react into your pug. But this is a problem for my lazy compilation. Now the first user to access a particular page on a server after a restart has to wait about 10 seconds which makes it seem like the host just isn't working. Unacceptable. So long to the short I started digging through the code to try to code a solution around this. I wanted to create something I would call a .pugs file that is pug but could be simplified down into something the server could load lazy very fast. Ideally I would like it to output an es5 version of the pug but I don't need that and I've realized that can't be done. All I really care is that it can be loaded into a functioning template. So then the goal was to look at what the internal representation of the template is after it is compiled. You can't read that without looking at the code because the returned function is a clousure. So what do I find when I read the code? fs.readFileSync. It's been violating my performance standards this whole time and it's creating a mess for maintaining them with es6. So what I'm tempted to do is rewrite pug to my standards, including asynronous file reads, automatic lazy file compilation and watching, the ability to cache internal representation to disk for quick restart, and I'll even throw lazy requires in there while I'm at it... Or I could just pick up a new template engine that does 90% of what I need without doing that.

[–] • 0 pt

Want to comment, but too tired to comprehend.

ELI5?

(edited )

I have very obsessive standards for performance. It turns out my template engine has been violating them the entire time. Plus I need it to do things it can't do to both use the latest coding style and do it with my standards. All of this is making me think I need to get off that template engine entirely but I've grown completely dependent on it, plus I don't know that any of the alternatives won't have the same issues.

AKA sometimes programming is made needlessly hard because of the need to follow trends, and or it leads to us compromising our standards.

The sad thing is that es6 will be a universal standard across browsers any time now, so it's almost worth not doing es6 till then because then you can forget all this bullshit and have all the nice features with no hassle if you wait about a year. It's like 92% coverage. When it hits that 95-96% sweet spot that's around the point that the only browsers it isn't working in are ones that it wouldn't work in anyway because of other things missing.

Well it sounds like you need to start researching thats what I always do in that situation.

Or what if I just realize that ES6 isn't worth it's hassle and is creating a performance/correctness/complexity trade off that multiplies that amount of effort that goes into each thing made.

But if I typed out 10% more characters I wouldn't develop those ES6 skillz and I'll never get a job because no interviewer will ever except "learning a new skill brought unworthwile complexity to my projects" as an answer. So I guess I'm going to make completely retarded trade offs. My code will be 10% more simple and the project structure will be 5x more complicated. Any company that accepts that as a trade off is retarded. But it's not my job to avoid being retarded. It's my job to be employable.

(post is archived)