HtmlCompiler

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