Currently, development on Atheos is going very FrontEnd heavy. I think the more familiar I get with the FrontEnd, the more I want to work on it; as such, the PHP BackEnd is probably going to suffer; luckily the BackEnd was originally developed by (at least as far as I have seen so far) very talented and foreword thinking individuals. The BackEnd has never caused a single issue for as long as I have been using Atheos/Codiad. Honestly, the FrontEnd was incredibly stable, and I'd like to think that I've only made it more stable and more responsive.
Most of my time is split between working on the Infrastructure and the FrontEnd, constantly hopping back and forth between them. While some may see this as ineffiecent, I actually get a lot more work done. It allows me to take breaks and stay fresh while continuing to work on things.
Frontend
The FrontEnd is heavily intertwined with jQuery, which isn't inherently a bad thing, however it has caused two issues:
- The version of jQuery used is incredibly old; version 1.7.2 released around 2011. Not only are there vulnerabilities known in this version, but I won't even entertain the idea that jQuery1.7.2 can run anywhere near as fast/effectively as a new version could, and my understanding is that jquery itself is incredibly non-performant compared to pure Javascript. Now, I understand that in the terms of speeds we're functionally talking about, it's really a non-issue. There is nothing in Atheos that is doing anything that could cause the user any sort of unreasonable lag, however I hold firm that jQuery should be removed from Atheos still, for other reasons I'll get into below.
jQuery is so heavily relied on that the actual codebase is insanely difficult to read, debug, and expand upon. jQuery is designed to make development easier, and again, not a bad thing to do, but it can cause developers to cut corners. All throughout Atheos, jQuery is used for animations and other styling traits that should be handled in CSS. jQuery has multiple areas where it's listening to events from numerous elements when instead listened to a single event from a parent element would be far easier. The context menu in the file manager is a good example of the shortcuts that were used to create it and now it can't be modifed easily to expand it's funcions.
Making the code hard to read by adding css into JS and by taking advandtage of jQuery shortcuts has caused the code to become bloated. In the sidebars module, there were a number of lines of code that didn't do anything at all, a few lines that were attempts at solving problems that were being solved elsewhere.
Now, I know for a fact that a lot of the features that PureJS has no weren't around in 2011 when Codiad was being made, and as such I know that jQuery was probably the best way to go. It is 2020 though, and using PureJS is a breeze and insanely performant; especially considering my penchant towards CSS. Currently, jQuery is used for DOM manipulation, CSS stylings and AJAX requests; all of which can be done easily without jQuery, more cleanly and faster in pureJS.
But what about Onyx.js I hear you say? Yes, I am making my own mini library to help develop on Atheos and remove jQuery. I created Onyx to ease development and standardize implementation of certain things, but with a few key differences. Onyx does not allow for Arrayed actions, eg: applying a class to multiple elements through a single selector. Onyx does NOT have any error handling. It doesn't try to solve your problems and guess at your intent. It sits right above PureJS allowed for shorthand functions for basic DOM manipulation. It allows development to be easier, not lazier. It also enforces Event Delegation, which I am a big fan of.
Honestly, I'm not entirely sure that Onyx is the best way to go, and if you'll look, you'll see that there are some files that I have completed that I didn't use Onyx on. The toast module is a good example. In fact, I might actually remove Onyx in the future, but because it's so close to the DOM, removing Onyx in the future will be a breeze.
Backend
I use console.log() in JS probably too much in regards to debugging, but it's really easy to use and provides exactly what I need to know. PHP doesn't have a console.log() function, I mean it does, error_log, but it's not as easy to use. This is honestly the main hang-up I'm having in getting close to the BackEnd. I recently had cause to play around with Node.jS and it is very tempting (probably impossible in a reasonable time-frame) to try to recreate the entire backend in Node, but let's be real; that's not going to happen. At least not for a long time.
I have made a few forrays into the backend, but I'm always left with a feeling akin to a fool's errand. There's nothing for me to do, nothing calls out to me. What really causes me concern is I can't tell if that's because the code meets standards (Codacy disagrees), or because I'm not familiar enough with PHP. I have made a good number of project in PHP, but I'm self taught on everything I know. I have zero formal education in programming aside from High School. If anyone knows of a good starting place within Atheos, let me know.
Infrastructure
Website: Atheos needed a website. Codiad had one, and I started with that repo to make this one, but honestly, not much of the original code is left. One of the things that truly infuriates me is trying to find out information about a software and I end up on a poorly built landing page without any heart in it, let alone useful information. I'm hoping that nobody ends up on this website, and leaves without the information they wanted.
Documentation: Codiad was poorly documented. I'm sorry if this offends you, but it was, and I'm willing to bet it's one of the reasons that development slowed to a stop. I'm not only referring to the github wiki, but the actual code, as well as the commit message on the repo. I'm not much better on my commit messages, but I'm putting in an honest effort to be better. I know comments in code will always be a problem, which is why I have the comment block at the top of each module. I know this is scandlous to say, but I don't think it's necessary to comment code if it's well written, and I plan on not letting poorly explained code get into the repo.
However, Documentation is where the key to the world really lies. Atheos will soon have a wiki-like documentation site up. One that is easy to navigate, and informative. I'm not going to write only what the code does, but why. Why is the most important thing you should document, what was your intent. That's why reading code can be so difficult; not because you can't figure out what each line does, but what was the developer even trying to do. That's where documentation really shines. Don't try to write up a long explination of the function, simply tell me what it does, how to use it, and more importantly, tell me your story for why it exists, and that's an easy thing to write for anyone.
Plugins: I've tried to maintain backwards compatibility with most of Codiad's plugins, but it isn't going to be viable for much longer. The context menu alone is going to be rebuilt using a totally different system, and a lot of namespaces have been changed. Eventually, I'm going to have to give up on compatibility, but most of the changes I make are easy fixes to bring a plugin up to date. If there is a plugin that you want updated, let me know and I'll push out an Atheos version. Atheos versions of Plugins WILL be maintiained.
Update: Oh boy, here we go. So when I did my first official release of Atheos, I decided to look into how Atheos's update function works. It's very complicated, and it some cases, seems downright bizarre. I'm going to be simplifying this area next into a faster flow, and I'm going to be adding some extras to the installation process as well. Now, I'm a big privacy advocate, but as I've been developing Atheos, I keep asking myself who is this for, and some analytics would be nice. Keyword: Some. I'm not adding Google Analytics. Searching through the update functions, I found out that a few things get passed back to the Atheos.io on update checks and market requests. I'm going to be adding some things to them to get a little more info, all completely non-identifiable, and I'll have a full write up put out before it I push it live, but it will be on the next update.