Lets-chat analysis

Today I’ve seen on hackernews about some guy that built “Let’s Chat, a self-hosted chat app for small teams” and I found it interesting. Because is a medium size app build with node.js and mongodb, which is HackHat’s stack, increased my interest.

687474703a2f2f692e696d6775722e636f6d2f4573324b4d69362e706e67

The little ‘ detail

The first little thing that spawn my interest on their homepage was the red ' character in the word “Let’s”. The source looks like this:

{mode: "htmlmixed"}
Let<span class="lc-love">'</span>s

Is nothing special per se, but it shows how much they love build this chat.

The code

Deployment

A big plus is using the docker way to deploy the app. What is not very interesting is the that the database is not contained into that docker app. The database has to be in a separate place , making a need to use the yml configuration file from the repo. Is not optimal because you change their source files and when you update to a new version that file can be overwritten by the default again. I personally don’t know how that is solved, but for small teams it might be overkill. Would be nice to have an option to integrate the mongodb into the same docker for 1 click setup.

Sem Título

Code organization

Was simple to find the core files, but also confusing because was not easily understandable whenever that code was containing the client side code too. After some dig the client side code has been found under “media/js”. Even the folder name “media” is not intuitive, because is not expected to find any js under media folder. A better name could be “assets” but even so is not good. Client side code is as important as the server side code, therefore they deserve to stay on the same hierarchy level.

Comparing to the HackHat’s organization this one is more confusing. Here is how we do it:

  • src
    • server
      • server side javascript files are here
    • client
      • client side javascript files are here
    • shared
      • shared javascript files are here

Compare this to the Let’s chat repo, which one you find more intuitive?

BrantaLeucopsisMigration

Migrootions

This folder catched my eye right away. Migrootions? what a name, seems like migrations and mongoose and is exactly what it seems: migrations management for mongoose. Maybe this will be added to the HackHat’s stack. Take a look at migroose.

Templates folder

As you might already know, templates have no place in the HackHat’s stack (hard to maintain and debug). First of all they are not even placed in a proper place, why put templates into the root of the application?
In order to make a repository intuitive you should use a known name and organize properly. All the client side files should be under a client folder, not mixing the hierarchy like is done here. In this repo the “templates” folder is at the same level as “media” (which contains the client side javascript files) and “app” (which contains the server side code). Seems to be used both on client and on server, therefore placing this into a “shared” folder would be better.

The templates are pretty simple and have no complex logic, which is good for a html template. In the message.html file things already get messy:

{mode: "htmlmixed"}
{{#unless fragment}}
    <img class="lcb-message-avatar lcb-avatar lcb-room-poke" src="https://www.gravatar.com/avatar/{{owner.avatar}}?s=30" />
{{/unless}}

The transcript file is also a mess because includes css. Why would the parent of a component include the css that is needed by a child? This is against our component based architecture. In the HackHat’s way of doing things the component itself should include it’s required css. In this way a component can just be dropped everywhere is desired without any further work. Now imagine you have the previous message template included in 2 places, you would have 2 times that extra css. I understand that is just a css that is applied to the message when is included in that template but even so the parent should not change the internal parts of a child. This leads to unexpected bugs and results.

Also each “view” is composed of 2 parts: the template and the javascript file. This is separation of technology and not separation of concerns.

module_final_03

Module loader

They seem to forget about module loaders on the client side, which is a big issue. For example the models file polute the whole global namespace.

CSS

Edit:
Thanks Ralph Meijer for pointing out the LESS files.
In the previous version I didn’t noticed the css linked to is a compiled one because was not minified in one string and had some separation comments, which happens in 1 long file css development.

HackHat’s stack doesn’t use LESS or pure CSS because the style is highly coupled with the view. In the future there will be a better post focussed on the CSS part of apps, where you can learn about making real modular styles without needing to care about the global issue with css files.

Old:
The css is a unmaintainable by a long shot, it does not use multiple files and all the css is just in one big file of 4731 lines.

Conclusion

Is a pretty interesting project where you can learn something, mainly about server side. Client side code and css is very poorly organized, the authors should improve in this area.

There is a lot more code to review, such as the interesting npm packages they use, the controllers on the server side…

If they would be starting the project then the suggested way to manage CSS would be to use the React framework in combination with SmartCSS.

Client side javascript code requires a proper module loader as quickly as possible, before growing into a unmanageable mess. I suggest to look into webpack.

Replacing grunt for gulp will speed up the development environment and event the build time.

Here you can play with the chat app.

If you liked this review retweet this to your friends and don’t forget to upvote on hackernews. Comments are currently disabled but you can reply to the tweet if you want to leave your feedback, which is greatly appreciated, as this is my 2nd post on HackHat.