Good day

In this issue I want to make a case for changing the awesomewm website. I've been working on and off on a redesign for the past couple of months and now it's at a stage where it's demo-able.

Check it out here:

https://jovial-lovelace-8eb5a0.netlify.app/

NOTE: You need to disable content blocking if you have it enabled. The site makes requests to reddit, which apparently is identified as a tracker, even though it only does it to get posts. Also, if it takes a long time to load posts, don't worry. That's normal for this demo. It's kinda buggy currently, but it's only a demo.

Why did I do this?

The main reason I did this is because I wanted to practice my web development skills, especially pertaining to the front end. At the same time though, I wanted to solve a few issues the awesomewm community has been dealing with for a couple of years.

How would the awesomewm project and community benefit?

First of all, what are the issues that I found the awesomewm community was struggling with?

Displaying community posts in an organized way

Wanted: Awesome screenshots In 2017 it seemed like a good idea to have a place to display community works and eventually get them on the website, but 3 years later people still post their work on that github issue, and posts haven't been added on to the website. Also, it's not like the issue does a great job of displaying them. The first few posts and the last few are shown, and the massive amount of posts in the middle just get hidden. Of course you can click the button to expand that section and see all of them, but I'm skeptical a lot of people actually do that.

Also, Elv said in the reddit post

"To everyone else, go there and vote."

I think it's a great idea, but it would be really nice to be able to do things like order posts by votes, etc.

Selling the capabilities of awesomewm

I found out about awesomewm when I saw this post. And that's pretty much all I needed to be sold.

I wanted to get into ricing, but I couldn't find something really extensible and with great drawing capabilities. But awesomewm seemed to be designed to make those things easy. And I only found that out when I saw that post and read Elena's description. I wouldn't have known awesomewm was as cool if I had only visited the website.

That's why I designed the website to

have the most voted community works on the front page, and
have a expo section dedicated to displaying community works in an organized way

uhh

These are mostly the reasons why I think replacing the website with a version that addresses the problems mentioned would be a good idea.

Ultimately, the reason I'm posting this unfinished demo here is because I would like to get feedback: Should I finish this? Should I change it in any way? Would having a website like this be a good idea? If not, I would like reasoning as to why, etc.

Also let me know If you have any suggestions, thoughts, you think I forgot something, etc.

Notable bugs

It takes a long time to load images (currently)

Yeah, that's because the images we load are exactly the images that the user uploaded. So we could get a 1MB png and wait a bunch of time. Multiply that for a couple posts when you scroll and that's a gg right there. The reason Reddit is much faster with this is because they're using some sort of separate image server designed exactly to solve this. Example link:"https://preview.redd.it/glzrkk83f4621.png?width=640&crop=smart&auto=webp&s=bbce2fb2f490d9f505f3ca26a98ae7506d0ff01d" We can't use this ourselves however because:

it seems to vanish at some point. The images are not just stored forever there, they seem to be generated on the fly. So we could have a link, try to fetch an image today, it works, then 1 week later we go again and poof no image.
This link doesn't come up in the json data we get from reddit. Reddit doesn't seem to want us to use this server ourselves...

Potential solution: Write our own server where we store optimized versions of these images and make the frontend request images from here, instead of from reddit.

This would also alleviate us making a bagillion requests for json data we don't need to reddit. A bunch of the json data we normally get is not awesomewm-related, or is not actually a post with a screenshot. Storing this on our own server and having it make requests to reddit every 2-3 seconds (or some interval of time) and update the json data on our server would pretty much solve this.

I think this is the best solutions to this problem.

It looks like garbage on mobile

I'm working on it.

The `/docs` page doesn't work

It's in the works. The /docs page is something I haven't yet tried to address. I know it works through some sort of automatic lua docs build system and the docs are generated from the source code, but I haven't gotten to that part yet.

Sometimes the same post gets loaded twice (or more)

I know. I'm working on it.

Considerations

The reason I chose to have the website fetch them from reddit is because

The r/unixporn subreddit seems to be a great way for people to share their work. I think we'd see similar success if we adopted something similar on to the awesomewm subreddit and website.
It seems to be the most sensible solution in this case. It's been mentioned that "we already lost many works to vanishing hosts". So that's not a good option. Also, if we store them on our own server then what? Can anybody post pictures? Well, hopefully not. So we'd need accounts. And we have to manage them. But who's gonna make accounts just to post a picture once in a while on a window manager website? It'd be a huge chore for everyone involved. Also: did you post on reddit? oh yeah cool, but now post on our website as well, and on unixporn, and on your github dotfiles repo, etc. and the more you think about it the messier it becomes. In this way, the user just has to post their work on reddit and that's it; the site fetches it automatically.

Currently the site fetches posts from r/unixporn, but I think simply fetching them from the r/awesomewm subreddit would be better. I only did it like this for this demo.

I also wasn't sure what exactly to do with the styling. I thought about just going crazy with it and treating it like I did my rice a year ago, but I wasn't sure that was the best thing to do in this current situation. The current styling on the site is not final, so if you have any suggestions for me in that regard, please let me know: is the way it is now ok? is it too bland? Should I just do whatever I want with it and treat it like I would another awesomewm setup? etc.

sorry, but i'm not much excited, the main reasons are: 1) it totally not displayed with NoScript enabled; 2) chosen logo basically a parody of dwm ones: 3) just some general markup weirdneses, but that i suppose not hard to fix, but it looks a bit weird so much of blank space (or i misunderstood and that space there reserved for some sort of slideshow or other media)

2020-04-23--1587674506_1578x1047_scrot

as a general resume from my side -- i think it might be nicer if you'll apply similar fresher design approach like on this demo but by improving CSS/minor markup changes of the current website

while as expo page, that would be a brilliant replacement for this page https://awesomewm.org/screenshots/ but i don't think it's reasonable to put on SPA the whole website, not just the "expo viewer" (and even in that viewer without JS should be displayed a top menu, and a message what expo can't be loaded without enabling JS first)

and totally separate sidenote -- the current website is static and hosted on github pages, while for go backend that would require doing some considerations on hosting that golang app

It looks nice. I really don't think we will change the logo for the DWM logo. A static website using the current framework and no mandatory Javascript are also pretty much hard requirements. We had a website infrastructure at some point (media wiki, flyspray, apache). It did not end well. I don't want to go back there.

Ok cool, thanks for the feedback. Those are totally valid concerns and I'll try to address them here:

It doesn't render at all with javascript disabled

Yeah, that's true. Normally, with most users, they wouldn't go nearly as far as to completely disable javascript, but I totally understand how people interested in awesomewm would also be users that would have reasons to just disable it.

Potential fix: The app is written in elm, and it all ultimately compiles to just javascript. All the text, styling, code, etc. However we can have the page render, even when this javascript code is disabled. All we'd have to do is just add the text and styling we want to have render in the index page. This way, there's no downside: if javascript is enabled, javascript renders the page properly. If not, we have the text content of the page as a fallback.

PS: I just pushed a fix, and now if you disable javascript, some text gets rendered.

The logo is plagiarized from dwm

That wasn't my intention. I knew the suckless community was using logos like these for their software and I thought "hmmm it'd be cool if it was inspired by that, but still be different enough that you wouldn't be able to tell it came from there". I finished the logo and didn't bother to check and see if it was really that similar to the dwm logo, but now that you posted a picture of it, I totally agree with you. Anybody would just look at that and think it's a ripoff. I agree changing the current logo with this one wouldn't be a good idea.

Styling looks weird

I know, but that's not hard to address. I only left it like this to demo it here.

There's a lot of blank space on the main page

The reason is because I thought it'd be cool to have some sort of media there, to go with the text. I'm still not sure about that myself though.

What if you just applied some CSS to the current website to make it look better?

That's just something I'm not willing to do. The reason I actually even went with elm as a language for the frontend is to run away from the mess that is html, css and javascript and all its "ecosystem". Also, in elm there's a very nice library that allows you to build a page's ui in a very declarative manner with rows and columns, just like in awesomewm.

But again, just having text render on the page if javascript isn't enabled is something I think would be a good idea.

I don't think it's reasonable to have the whole site just be an SPA (single page application)

The reason I did it like this is because when I started the project I didn't really know what to do. Elm allows you to make an SPA and lets you control a bunch of stuff, and I wanted to learn about that so I just went with it.

I didn't think it'd be a problem, especially given that we can share data between pages. If you notice, when the main page loads up with the pictures of the "expo" section, if you then click on "Expo" to go to the expo page, there's no delay. The images on the /expo page instantly load. That is because the data between the main page and the expo page is shared.

But I do understand why you'd want to have them be separate, and that wouldn't be a big problem. I could just separate this app in to separate pages. (But of course we wouldn't get the benefit of sharing data between the main page expo section, and the /expo page.)

The site is currently hosted on github pages. Having a golang backend would complicate things.

The current golang backend is about 50 lines of code and the demo I sent doesn't even use that at all. It's just hosted by netlify (which is basically the exact same technology as github pages; it just serves a site from a git repo). It really doesn't do anything but serve the elm app. All the fetching and displaying of posts happens purely on the client side and it works well right now. But as I mentioned in the issue, the reason I suggested having our own server in between the client and reddit is because of efficiency. Currently the images that the client requests are the full images that the user uploaded from reddit. That's why the images on the expo page take so long to load. If, however, we had our own server that gets these images from reddit, optimizes them, and then we'd have the clients make requests to our server, then that'd solve the problem of loading images slowly. Then, to make this (more or less) real time, our server just gets the necessary data from reddit every few seconds.

But again, let's say we decide to not have a backend. That'd work as well, and all of what I showed you could just be hosted on github pages. It's just that posts would load slowly.

And let's say that one day we have a backend that does this and it breaks, and nobody wants to fix it. That's not a big deal, we could just change a couple of lines to the frontend to again, make requests from reddit, instead of our server.

"We had a website infrastructure at some point. It did not end well."

I'm really curious what happened with that.

I think those were pretty much all the concerns. If you have any others, let me know.

what exactly the problem to implement expo logic using some light vendored dependency, like jquery, without all that elm/npm/bower -ttry?

and regarding style in general and CSS in particular -- if you don't know CSS yourself, you could prepare just mockups of "refreshing" the current static website, and me or some other volunteer could "convert" your mockup into an actual CSS code

as i am agree what the current website might look a bit outdated visually, but i feel like it's technical stack is right on point and don't require any major changes

"without all that elm/npm/bower"

...or gulp or grunt or react or vue or webpack, babel, etc etc etc etc?

Ahh I see, so another concern would be the fact that you wouldn't want to bring the npm disease over in the awesomewm project.

I totally empathise with you on that, I agree with you, and I'll try to show you now that we're actually on the same page in that regard.

Why I chose elm

Honestly, at first it was because I was trying to find a sane way of styling a page. Also, it was because it seemed to somehow distance itself (or at least try) from the js ecosystem, which I also desperately wanted to do.

Now that I've worked with it for a while, I realize it's actually much more than just some "framework" or hacky amalgamation of javascript, css and html "solution". It literally has one thing you need: the elm compiler, and with it, all you need to do is have the code you've written so far, you do a elm make ./src/Main.elm and it compiles all the code into a file named "index.html".

Literally all dependencies it has are from the elm ecosystem (which has nothing to do with the js ecosystem), and the elm package manager follows enforced semantic versioning. Which means that if someone changes a library, they can't publish it without incrementing the version number. Ultimately, this means that the library version "1.0.2" you used at the time you wrote the code will be exactly the same one fetched when you try to compile your project again in the future.

Also, did you ever see {name} is not a function? It will never happen with elm. Because of its type system, runtime errors can not happen. If it compiles, it is guaranteed to have no runtime errors. (Except for like 2-3 very particular cases.)

I know I'm really trying to sell this, but it's mostly because I'm trying to show you I didn't have to deal with ANY of the js (~~plague~~)ecosystem using elm.

"Ok, but we need something where users don't need the latest version of firefox or chrome to run it. We need something more lightweight."

I'm pretty sure the elm compiler actually uses IE8 or IE9 javascript features only, so unless you're doing something like WebGL, it will run on almost any (reasonably recent) browser.

"what would be the problem with implementing expo logic using some light vendored dependency, like jquery?"

It wouldn't be a problem, but

you wouldn't get the benefits of elm: enforced semantic versioning, type safety, no runtime errors
it'd have to be written from scratch, whereas what I wrote already works

There's no "huge dependencies" we're pulling in. All we'd need would be the elm compiler to compile code to javascript.

Also, the elm code that makes the requests for posts, filters them, and fetches more if there aren't enough is about 200-300 lines of code. Most elm code deals with styling of the page.

You could prepare mockups, and a volunteer could write the css necessary

That's totally fine, and I think it's be what we should do: Write the text content of the site, and a litte bit of css to make the site work and look ok, even with js disabled, let the user know it'd look better if they enabled javascript, and also that the expo page can't work without javascript.

In this way the website can only look better and have cooler features:

If the user has javascript enabled, the website I wrote is the one that gets displayed.
If the user has javascript disabled, we could literally default to the old website, and let the user know the website would work and look better with javascript enabled.

"Ok, what if at some point it breaks, and you're not there to fix it? We're contributing to awesomewm because we want to work on a window manager, not its website"

Once it's done, I'm fine with fixing errors here and there and mantaining it if it breaks. I really don't expect it to require a huge amount of effort or time.

But if at some point I just decide to not want to mantain it anymore, you guys can just ditch the whole thing, and switch back to the old website. I don't think it'd be that big of a deal.

Look, I appreciate the effort, I really do. Our website needs love and I am glad someone is interested. But please understand that all these shiny compiler and JS framework doesn't fit the project image, doesn't fit in the current tech stack, which is not going to change, and isn't something we want to have added to our dependencies. If you want to use JS for some image gallery, that's borderline fine, but I will make the call here, this is as far as it will go. CSS and HTML with the current static stack should be the target.

Well that's exactly my point I tried to prove: It perfectly fits the current stack. There's no dependency needed. I can split up this SPA into separate pages, I compile them, and they can, in just the same way, be served with github pages. Ultimately, the expo page and the main page make requests to reddit. It meets both requirements:

[x] There's no backend. The images get fetched from reddit. [x] The current css and html website would be the one served, along with the js code I give you (which would be the site I wrote).

In the end, we have this for each page:

index.html (The css and html version of an awesomewm page)
app.js (The page I wrote)

They both get served when the user requests a page (let's say the main page). Then, the current (css and html only) main page gets displayed. If the user has js disabled, nothing happens, the current (css and html only) main page is already displayed. BUT if they have js enabled, the js executes, and the page I wrote is the one displayed.

It fits the tech stack, and I see literally nothing to lose by taking this approach: Either the user has js, in which case my version of the site is displayed, or they don't, in which case the css and html only page is displayed. We just send 2 files (app.js and index.html) instead of 1 (index.html).

I understand if you guys would still like to keep the site as it is, but if you change your mind, just let me know in this issue.

The types of people who like AwesomeWM correlate strongly with the type of people who like terminals and don't like heavy JS websites. Having an heavy JS app is sending the wrong message when they visit the website.

True enough, I actually do agree with you here. Some people who would otherwise be interested would be turned off by a js based website.

But as it currently stands, the website would solve two problems:

Showing community works in an organized way, as opposed to using the github issue
Displaying capabilities of awesomewm

And especially pertaining to the second point, I do all my work in terminals, I do dislike heavy js apps, but I wouldn't have gotten into awesomewm if I wouldn't have seen what you could do with it. So in that sense I would argue it'd be a more important issue to solve.

I'm not saying we should use what I wrote to solve these (although it would be a solution), but how do you propose to solve them? Do you think they're a priority? Are there any plans for solving them?

i was thinking, mb contents for Screenshots website section could be scraped from reddit and Screenshots github issue during static website generation? thumbnails also could be generated during static site build, as the images would be already known

possible downside what that could drastically slow down the website generation time, so mb it could be done as a separate build task

awesomeWM / awesome

AwesomeWM website redesign #3078

Good day

Check it out here:

Why did I do this?

How would the awesomewm project and community benefit?

Displaying community posts in an organized way

Selling the capabilities of awesomewm

uhh

Notable bugs

It takes a long time to load images (currently)

It looks like garbage on mobile

The `/docs` page doesn't work

Sometimes the same post gets loaded twice (or more)

Considerations

It doesn't render at all with javascript disabled

The logo is plagiarized from dwm

Styling looks weird

There's a lot of blank space on the main page

What if you just applied some CSS to the current website to make it look better?

I don't think it's reasonable to have the whole site just be an SPA (single page application)

The site is currently hosted on github pages. Having a golang backend would complicate things.

"We had a website infrastructure at some point. It did not end well."

Why I chose elm

"Ok, but we need something where users don't need the latest version of firefox or chrome to run it. We need something more lightweight."

"what would be the problem with implementing expo logic using some light vendored dependency, like jquery?"

You could prepare mockups, and a volunteer could write the css necessary

"Ok, what if at some point it breaks, and you're not there to fix it? We're contributing to awesomewm because we want to work on a window manager, not its website"

awesomeWM / awesome

AwesomeWM website redesign #3078

Good day

Check it out here:

Why did I do this?

How would the awesomewm project and community benefit?

Displaying community posts in an organized way

Selling the capabilities of awesomewm

uhh

Notable bugs

It takes a long time to load images (currently)

It looks like garbage on mobile

The /docs page doesn't work

Sometimes the same post gets loaded twice (or more)

Considerations

It doesn't render at all with javascript disabled

The logo is plagiarized from dwm

Styling looks weird

There's a lot of blank space on the main page

What if you just applied some CSS to the current website to make it look better?

I don't think it's reasonable to have the whole site just be an SPA (single page application)

The site is currently hosted on github pages. Having a golang backend would complicate things.

"We had a website infrastructure at some point. It did not end well."

Why I chose elm

"Ok, but we need something where users don't need the latest version of firefox or chrome to run it. We need something more lightweight."

"what would be the problem with implementing expo logic using some light vendored dependency, like jquery?"

You could prepare mockups, and a volunteer could write the css necessary

"Ok, what if at some point it breaks, and you're not there to fix it? We're contributing to awesomewm because we want to work on a window manager, not its website"

The `/docs` page doesn't work