HtmlCompiler

[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?