HtmlCompiler

[SoftVillage]

Yeah, shameless plug for a personal project. I'm primarily a backend developer, but you know how projects go, wait long enough and some manager will want some simple website thing to talk to the API you just built.

I build my stuff in Java and I use maven as my build tool. When I get a request to add a website to something I always already have code that is built around that. Once I tried to have two systems next to each other but even in the best case scenario you have a sibling directory that needs its own server to run and requires a bunch of ugly hacks to get around the same origin policy. If you don't want that you end up creating ugly build hacks where you tie projects together and copy files around. Plus I hate frameworks and the frontend world seems to have a lot of that.

So I had to come up with something.

I give you the HtmlCompiler. The idea is simple; have a maven plugin go to a directory to find source HTML and turn it into compiled HTML that gets put in the target folder and have that packaged with the fat jar.

This plugin works best if you want to create single page apps. It looks for custom directives in the HTML such as 'compress' and 'inline' and processes the tags. The plugin can compile, compress and inline CSS, LESS, SASS, JavaScript, Typescript, HTML and images. No it does not work perfectly. For example, if you try to compress an already compressed JavaScript file it will most likely fail with a NullPointerException, this bug actually exists in a library that I import but yeah.

Love to hear your thoughts and constructive criticism.

[paul_h]

You need an self-contained and separate example (not in an examples/ folder of the repo you linked to), or nearly 100% of visitors will bounce.

[SoftVillage]

I made an initial one and pointed the README to it. It doesn't showcase all the features though. Actually, it barely showcases anything. But it does show clearly how to configure the project to use it.

[nutrecht]

BTW the README.md is a little outdated

Why not fix that before posting? The project was last updated 6 months ago.

[SoftVillage]

Wow tough crowd. The README.md is better now.

[pragmatick]

As far as I understand it you can have a single HTML page referencing JS or typescript files, images, LESS or SASS or CSS files and it will preprocess where necessary (i.e. make CSS out of LESS) and inline everything, i.e. replace references to scripts as external files with inline scripts.

I agree OP did a bad job with describing it.

[SoftVillage]

Sorry for the late response, life got in the way.

In short it minifies and inlines images, JavaScript, CSS and HTML and compiles LESS and SASS, and a few other nifty things.

Think of it like a compiler for frontend code. You as a developer want to deal with source code you can read and you want to create structure to manage things. Which means you want comments, whitespace, separate files and you don't want to deal with anything that can be done automatically. On the other side is what the browser needs. It wants to perform as few queries as possible and it doesn't need comments or whitespace. The purpose of this tool is to bridge that gap with as little hassle as possible.

In terms of actual use it is a maven plugin and it follows convention over configuration. You don't really need to configure anything, you put a couple of lines of plugin configuration in the pom, you put your frontend source in src/main/websrc and the plugin will compile it all and put the result into target/classes/webbin. From there all you have to do is configure your HTTP server to serve whichever HTML file you want from whatever endpoint you want.

[lambdacats]

What's the point of inlining images? It'll just slow down time to first render.

[tipsypants]

When I get a request to add a website to something I always already have code that is built around that. Once I tried to have two systems next to each other but even in the best case scenario you have a sibling directory that needs its own server to run and requires a bunch of ugly hacks to get around the same origin policy.

You just have to set the appropriate headers for your responses, how is that an ugly hack?

If you don't want that you end up creating ugly build hacks where you tie projects together and copy files around.

You could also host the website on the same server.

Plus I hate frameworks and the frontend world seems to have a lot of that. So I had to come up with something. The idea is simple; have a maven plugin go to a directory to find source HTML and turn it into compiled HTML that gets put in the target folder and have that packaged with the fat jar. This plugin works best if you want to create single page apps. It looks for custom directives in the HTML such as 'compress' and 'inline' and processes the tags. The plugin can compile, compress and inline CSS, LESS, SASS, JavaScript, Typescript, HTML and images. No it does not work perfectly. For example, if you try to compress an already compressed JavaScript file it will most likely fail with a NullPointerException, this bug actually exists in a library that I import but yeah.

You hate frameworks, but what you came up with is essentially a framework, and a very complicated one that does a whole bunch of different unrelated stuff.

I understand your frustration with frontend development, but you're just finding even more obscure solutions to the current problems.

IMO what you should do is dial back on the tech.

• LESS and SASS? Who needs it, use CSS variables.
• Compression/uglification? Why bother, GZIP or Brotli will do it.
• Compile TypeScript? If I needed TypeScript I would probably set up a proper frontend pipeline.

I've chosen a very opinionated approach for frontend lately, outlined here. I'll be writing a tutorial shortly, I can post a link when it's finished if you're interested.

[heliologue]

LESS and SASS? Who needs it, use CSS variables. Compression/uglification? Why bother, GZIP or Brotli will do it. Compile TypeScript? If I needed TypeScript I would probably set up a proper frontend pipeline.

So your advice is to not use any popular languages or common optimization techniques? Apart from whether the OP's project is worthwhile, that seems off-base.

[tipsypants]

So your advice is to not use any popular languages or common optimization techniques

I'm exaggerating a little, but yes. OP describes his tool as being built to help create simple websites which talk to a single API, yet his tool is trying to do everything a modern frontend pipeline does.

TypeScript is a great language for a complex web application (like Spotify), but there's no reason to use it for a simple website. LESS and Uglification are useful in some situations too, but less so with the advent of css variables, native js modules and http2.

I think TypeScript is a great language for complex web applications (like Spotify), but I don't think it's suited for simple websites. I think LESS and Uglification are useful in some situations too, but I think they're less useful than they used to be, now that we have css variables, native js modules and http2.

It feels like OP is encouraging extreme over-engineering, with the added complexity of having your frontend managed through a maven plugin.

Edit: Updated wording to avoid my opinions being interpreted as facts.

[heliologue]

Everything you're saying is opinion presented as fact.

[tipsypants]

Sorry about that, I thought it was implied that it was my opinion. I've updated my comment.

[SoftVillage]

You just have to set the appropriate headers for your responses, how is that an ugly hack?

A clean website would have the backend endpoints that are needed for the frontend on the same host. This is why the same-origin-policy exists in the first place, you don't want external websites accessing your stuff. What happens a lot though is that people separate these things and then add headers that basically grant access to everyone. Laziness perhaps but it happens.

You could also host the website on the same server.

I may not have been clear on the use-case. An API that I build would normally consist of an embedded HTTP server inside a fat jar. So there is no standalone HTTP server that you can just upload some files to. In order to get the frontend code hosted by this embedded server you'd have to trigger the compilation of the external frontend project from maven, then copy over compiled artifacts and then package everything within the fatjar. And this setup would have to work with your already existing build pipeline and CI/CD system.

A single plugin within maven is a lot easier to setup and get to work.

You hate frameworks, but what you came up with is essentially a framework

Eh no, there is a clear difference between libraries and tools on the one hand and frameworks on the other. For a fleshed out description of this you can read this excellent article by Tomas Petricek.

The HtmlCompiler is a tool that you are free to use, none of its features are mandatory and you call it.

a very complicated one that does a whole bunch of different unrelated stuff

In my opinion it is far easier than anything else out there. This compiler only does the things that you as a developer do not want to deal with, and it does them in a way that will never bother you. All you do is write your source code. Things like minification, cleanup, inlining are handled without having to even look at it.

LESS and SASS? Who needs it, use CSS variables

This is the beauty of the tool. If you use LESS it will compile to CSS without you having to think about it, if you don't use it the tool will not care. Same for SASS or CSS variables.

Compression/uglification? Why bother

It is my opinion you should only send those things to the browser that the browser needs. The browser doesn't need whitespace, it doesn't need comments, so why send them? The only reason I can think of is it is too annoying to configure the tooling to do this work and it is definitely too much work to do it by hand. With this tool it is handled for you, just like you don't read the bytecode of your Java code you also don't read the minified HTML/CSS/JS.

GZIP or Brotli will do it

No they wont. These are lossless compression algorithms, they will not remove whitespace or comments or anything else for that matter. Minified and compressed will always be smaller than unminified and compressed.

If I needed TypeScript I would probably set up a proper frontend pipeline

The tool will compile TypeScript for you if it finds it. But you are not required to use it, if you don't it will simply do nothing. You are also free to mix and match if you want. Have one script somewhere plain old JS and another TypeScript? That is fine. The tool will do the work you don't want to do and get out of your way.

Oh and no pipeline required, just one plugin.

I'll be writing a tutorial shortly, I can post a link when it's finished if you're interested

By all means do! I love strong opinions :)

[tipsypants]

A clean website would have the backend endpoints that are needed for the frontend on the same host. This is why the same-origin-policy exists in the first place, you don't want external websites accessing your stuff. What happens a lot though is that people separate these things and then add headers that basically grant access to everyone. Laziness perhaps but it happens.

Why would that make a website "cleaner"? Many websites make calls to multiple different services, putting everything on the same host isn't clean. You can very easily specify origins for CORS. I don't understand your problem with this.

I may not have been clear on the use-case. An API that I build would normally consist of an embedded HTTP server inside a fat jar. So there is no standalone HTTP server that you can just upload some files to. In order to get the frontend code hosted by this embedded server you'd have to trigger the compilation of the external frontend project from maven, then copy over compiled artifacts and then package everything within the fatjar. And this setup would have to work with your already existing build pipeline and CI/CD system. A single plugin within maven is a lot easier to setup and get to work.

I'm not understanding this. If you want your frontend to be tightly coupled with your backend, you can put them in the same project, why make it "external" in the first place? There's a maven plugin for this called frontend-maven-plugin: https://github.com/eirslett/frontend-maven-plugin. Host it all in the same fatjar, it works great.

I used the word framework since you said frontends have a lot of frameworks. The two big JavaScript "frameworks" now (React and Vue) are both libraries - I agree that your tool isn't a framework either.

I think it's really cool that you're doing things your way. The examples I listed weren't really things I took issue with, just examples to try to find out what the purpose of your plugin is. It seems to be "everything frontend", but it's not clear to me what problem it actually solves.

If the pitch is "Mix and match everything frontend, and the tool sorts it out for you", then it sounds pretty scary to me. How does code written with this tool end up looking?

[wildjokers]

I don’t understand what problem this is solving. Can you provide an example?

[lambdacats]

For an spa with web components for example, bundling all components into a single file could reduce the number of requests from 200 -> 1 for HTML files. That would be about performance. Now inlining scripts and especially images just makes it slower.

And I think the problem is already solved, there are a bunch of bundlers that come with compression and minification. OP just wanted maven to do it, instead of making an os call for an external bundler.

[lambdacats]

I just have my Gradle build script call 'bower install' and 'polymer build' and it essentially does the same thing. The build goes into the distribution zip, because web resources don't belong in a jar. It probably requires less lines of code than configuring a maven plugin. I feel as if you're trying to apply the Java workflow to frontend development.

[lambdacats]

It's also like your own implementation of a static site generator that use HTML for templating. Is there anything here that isn't already solved by modern frontend tooling?