Content refactor

[gidsi]

I think we're far enough with the refactoring that the new content is workable and better then what we currently have.
These is still a lot of room to improve, but i think thats easier with having the site online and get used.

[gidsi]

Also fixes #54

[dbrgn]

Hmm, I can't get the styling to generate properly... Even after deleting the whole repo, cloning it again and regenerating the website (lektor server -f webpack) it looks like this:

I also had to use nvm to ensure that node <=12 is being used. Node 13 (which is installed on my system) breaks node-sass apparently.

PS: Why again do we need Webpack? Is it only for SCSS compilation? Isn't there a solution for Lektor that doesn't pull in a whole jungle of NPM dependencies including – right now – "63 high severity vulnerabilities"? (Yes, I'm aware that these are only build-time dependencies, but still, I think we could probably do without them with just a few tweaks to our JS files. It's not hard anymore nowadays to write JS that runs in most browsers without using Babel. And we don't need to support IE/Edge for our target user group, so assuming a modern browser is fine.)

[gidsi]

Hmm, I can't get the styling to generate properly... Even after deleting the whole repo, cloning it again and regenerating the website (lektor server -f webpack) it looks like this:

I also had to use nvm to ensure that node <=12 is being used. Node 13 (which is installed on my system) breaks node-sass apparently.

PS: Why again do we need Webpack? Is it only for SCSS compilation? Isn't there a solution for Lektor that doesn't pull in a whole jungle of NPM dependencies including – right now – "63 high severity vulnerabilities"? (Yes, I'm aware that these are only build-time dependencies, but still, I think we could probably do without them with just a few tweaks to our JS files. It's not hard anymore nowadays to write JS that runs in most browsers without using Babel. And we don't need to support IE/Edge for our target user group, so assuming a modern browser is fine.)

I've already removed SCSS from webpack in that branch, i forgot to fix the README /package json so it broke on your system :)

[gidsi]

PS: Why again do we need Webpack? Is it only for SCSS compilation? Isn't there a solution for Lektor that doesn't pull in a whole jungle of NPM dependencies including – right now – "63 high severity vulnerabilities"? (Yes, I'm aware that these are only build-time dependencies, but still, I think we could probably do without them with just a few tweaks to our JS files. It's not hard anymore nowadays to write JS that runs in most browsers without using Babel. And we don't need to support IE/Edge for our target user group, so assuming a modern browser is fine.)

In general i would like to keep Webpack, i know it feels icky sometimes but for me that's an okay-ish trade off to be able to write ES 6/Type Script instead of ES5 (constants, let variables, arrow functions, default values, promises etc etc, here is a complete overview http://es6-features.org).

I would be fine removing Webpack again if where removing the self written js from it too, maybe give the validator a GUI or something instead that we can link.

[dbrgn]

constants, let variables, arrow functions, default values, promises etc etc, here is a complete overview http://es6-features.org

You can use all those features right now and they'll work on any browser that's not terribly outdated. Main thing that doesn't work without webpack is ES modules, but right now we don't use those anyways (and most projects can still be imported using script tags).

Maybe we could extract the validator GUI to a separate JS project and make that embeddable (e.g. by providing a DOM element reference to the constructor where the validator GUI can insert itself). For those ~5 lines of JS code we wouldn't need Webpack anymore. I think it would be nice if it's embedded on the website, and not a separate project.

[dbrgn]

I've already removed SCSS from webpack in that branch, i forgot to fix the README /package json so it broke on your system :)

Maybe we should include a Makefile with a "run" target 🙂

[gidsi]

constants, let variables, arrow functions, default values, promises etc etc, here is a complete overview http://es6-features.org

You can use all those features right now and they'll work on any browser that's not terribly outdated. Main thing that doesn't work without webpack is ES modules, but right now we don't use those anyways (and most projects can still be imported using script tags).

Oh... we're already at 96% support in all browsers, you're right, might have been some time when i last checked. Then of course we can rip it out.

Maybe we could extract the validator GUI to a separate JS project and make that embeddable (e.g. by providing a DOM element reference to the constructor where the validator GUI can insert itself). For those ~5 lines of JS code we wouldn't need Webpack anymore. I think it would be nice if it's embedded on the website, and not a separate project.

Yeah, something like this, we could even move it to the validator itself and make i available there. Would feel more right to me anyways.

[gidsi]

I will open a new issue for it since it's not connected to this pull request in my mind :)

[gidsi]

I've already removed SCSS from webpack in that branch, i forgot to fix the README /package json so it broke on your system :)

Maybe we should include a Makefile with a "run" target slightly_smiling_face

I don't know, i've used makefiles usually in a way that is now completely replaced with Dockerfiles (beside a few special cases), is there any advantage in this kinda project for makefiles?

I will open an issue for that too.

[dbrgn]

is there any advantage in this kinda project for makefiles?

Yes. I was used to typing lektor server to start the server. Then we introduced the webpack plugin and updated the README, but if I don't read the README then I'll still try to start the server with lektor server, which breaks the output.

If I instead only have to remember to run make server to start the server, then a PR can update the server command in the Makefile and my workflow will continue to work as before.

We could also add a target called docker_server that would automatically invoke docker to start the server container in the background.

(In a JS project I'd use a npm script in package.json instead, but Python doesn't have a default task runner.)

But that can be discussed in a separate issue (e.g. #68).

[dbrgn]

As a note already, when merging this PR, please make sure to squash all the commits, so we don't end up with dozens of single-line update commits.

[dbrgn]

Let's ship this! 🚀 (But again, please don't merge 60 commits consisting mostly of one-line typo fixes without squashing them first 😄 Squashing everything into one commit would be fine though if you don't have the motivation to rebase.)

[gidsi]

Let's ship this! rocket (But again, please don't merge 60 commits consisting mostly of one-line typo fixes without squashing them first smile Squashing everything into one commit would be fine though if you don't have the motivation to rebase.)

Yeah, i wanted to squash everything, i don't see a lot of value in the commit messages since its basically a full rewrite.