Team Website

[vnmercouris]

?

[Cajunvoodoo]

Unsure what the question mark is about, but we will probably want this to be in its own parent folder. I plan to use Yesod (https://www.yesodweb.com/) and GHC 8.10.7 to create the website. To allow the others to assist as well, reading select chapters from (https://www.yesodweb.com/book) may be of use. The HTML and CSS has a bit of magic syntax related to type safety. Other than that, simple CSS skills will make everything beautiful.

[vnmercouris]

Can we make a separate repository under the Java Like it's Hot organization that all the website code lives in so it is not getting mixed with the robot code.

[Cajunvoodoo]

On it. I'm wondering if we should go with more hard-coded html/css files (like homepage2022, homepage2023, homepage2024, ...) or use a database (like Postgresql or SQLite). Yesod supports it natively, but it will make it more complicated for the team if this is the framework used in 3 or so years when nobody present knows how to manage the postgresql server. the hard coded method also has its drawbacks: after those same 3 years, team members would be required to add lines of haskell and deal with Stack (the build tool) and writing manual Haskell cases to load the correct files. I'll implement it using Postgresql (or some other SQL-based database), but I don't want to call all the shots

Edit: I made it using postgresql but dealing with postgresql itself was an actual nightmare. I'll reimplement using SQLite (which requires changing like 2 lines of code) and see if it's a nicer experience. Postgresql is also a tool with so much power we don't need

[Cajunvoodoo]

@animallover41097 So as it stands there are 2 paths (this will get wordy, but i suggest you read all of this): the first is how it is currently (almost) implemented. it involves normal html, css, and js. This means there is no compile time safety, but it is more "familiar." This will require recompilation (the command is just stack build) to move the static files (the CSS and the JS) from just files on disk to also datatypes in the compilation code (for type safety). this isnt a huge deal breaker, but it definitely is less satisfying; i cant see a way to make it without recompilation. note that requesting the JS and CSS from the HTML (in the <script href="FILE LOCATION"> and in the style tag) sends a GET request, meaning the server must know about the existence of static/{css|js}/homepage2022.{css|js}. This also makes it more difficult to make the layout less rigid; any links (like a homepage with a navigation bar with "meet the team," "implementation," and "contact") would require a new column in the database (for the filepath to the HTML) and either new paths in the haskell code or more janky code. This means adding new links in subsequent years (though they could just be repurposed, being given plentiful generic paths, but this is a website, not a CPU register bank and is janky), which i dont believe anyone would be able to easily do (its very easy, but haskell isnt).

the other solution is to say "screw future us, just make some lucky coder learn basic Yesod and make it properly. give them a link to that online book and a written guide for this purpose." Honestly, this may not be terrible. I know i said i dont want them to even touch the haskell code, but there are some serious advantages. It makes everything infinitely more extensible, it gives access to compile-time safety, faster user response, Widgets (a Yesod Monad which makes HTML, CSS, and JS extremely modular), and can act as programmer mentoring (learning haskell makes you a stronger programmer, even if it means you can see problems in other code (slightly satirical article about python and haskell)). the only bad thing i could see happening is the team lacking a programmer who has taken and completed AP CS and/or a bright programmer who is scared by compile errors (theres a lot! it acts as a to-do list for the programmer after she makes changes, but many dont see them this way and treat the compiler as their enemy). The extensibility bit is also worth noting: we can add so many things to the website this way. The other method will force everything to feel stale year after year; it will be designed to look one way and support that one way with little room for change. A note for consideration though: there is a lot of code in the website repository. i wrote extremely little of it. it comes from the "scaffolding" the library provides to make production ready websites. i ensure you it is not at all complicated and can aid in teaching proper code organization

I want to know your opinion on these two approaches, as i feel both decisions have major drawbacks and upsides.

Edit: After further consideration, there is a third and simpler way. Instead of Yesod, there exists a library called Servant. Servant aims to be a type-level description of a web API. If we just agree that all HTML and CSS content should be normal and served without any glorification, this solves most of the problems. Actually probably all of them. And the code would be relatively small and maybe even a single .hs file! Servant is also type safe. I'll implement this tomorrow after reading up on how to do this (I did check it was possible, along with serving css and js).