Cyberchef: Discussion: Code structuring and frameworks

[l50741]

Summary

It is a well-known fact that anytime a new developer looks at some existing code, their first reaction is to say something along the lines of: "This would be so much better if it was written in !". We all have our favourite approaches for tackling certain problems, but it is never a good idea to re-write a project just so that is is in a language that makes more sense to you.

This is not an attempt to do any of that, however, it is worth discussing these sort of things occasionally. As a project progresses and new features outside the original scope are requested, some of the technology choices made at the beginning might be worth a second look.

[l50741]

I have only been looking at CyberChef for a couple of days, so it is very likely I don't have the full picture. Also, I know almost nothing about the vast majority of the actual operations, so I will be avoiding them entirely.

My first thought while looking in the "web" folder was that the structure was very flat. There is a single HTML file, a few files which control the application, and a lot of files which are dealing with event handling.

One of the first steps when it comes to code structuring is generally to keep things small and distinct. Whether this is avoiding monolithic functions by breaking them into smaller ones which each serve a distinct purpose, or breaking down a user interface into components so that each component can control its own behaviour.

For CyberChef we might break the UI down into:

• List of operations
• Recipe chain
• Input
• Output
• Controls

[l50741]

To be clear, there are many benefits for not using a complex framework in a project such as this, as an example:

• Little to no change of dependencies breaking
• Using native functions are often run quicker
• Compiled project is often smaller

However, there are some benefits you miss out on:

• Frameworks promote common structure to code, making it easier for new developers to pick up, as well as improving general maintainability.
• Reduces the "boilerplate" code that surrounds a lot of native functions.
• Better interaction between the HTML and the JS (callbacks, two-day data-binding, event handling)
• Frameworks add a lot of features that would be infeasible to implement by hand (examples of this depend on the framework)

[l50741]

For my own sake, I spent a few hours over the last couple of days having a look at a possible way to structure CyberChef using Angular2. I find it difficult to evaluate these sorts of projects without putting together some code to test things out.

I chose Angular2 in this case because of my previous experience with it, as well as the fact that with the newest updates to CyberChef (Webpack, ES6, NPM etc.) It's not actually that far away from projects that are generated by the Angular-CLI generator.

Github: https://github.com/l50741/ng2-cyberchef
Demo: https://l50741.github.io/ng2-cyberchef/

Please bare in mind this is just a thrown together mess at the moment...

Points of interest:

• Moved to typescript (which exports as ES5/6 when built). Requires you to be much stricter with variables and parameters, but radically easier to hunt down bugs relating to passing objects.
• Converted the different areas of the page into components with separate controllers.
• Robust test framework (each service/controller has a spec file for specific tests). As well as the possibility of adding e2e protractor tests
• Using material design (sort of). Not using many of the components but allows theme editing
• Not added many of the operations, but very simple to convert them from their current format
• By no means has all features, but current dist folder is only about 1MB

[n1474335]

This is really interesting. I don't think we should underestimate the amount of time it would take to convert the entire app to Angular 2 though. I think a discussion should be held regarding the pros and cons of different frameworks, how long they are likely to be supported before we have to refactor to the latest and greatest all over again, and how much benefit we would ultimately gain from them.

As you can probably tell from my tone, I'm not overly sold on investing so much time into it. Demos like the one you've created are definitely valuable, but actually porting the entire app over with all the features and ops would take a substantial amount of time. My personal opinion at the moment is that this time would result in more obvious benefit if we invest it in other areas (new ops, features, platforms etc.).

What do other people think? I recognise my opinion may not be shared by everyone.

[mattnotmitt]

I'm in agreement with @n1474335 - It's pretty well agreed in the community that Angular can be pretty quick to learn at first, but when you actually start getting in more depth that it slows quickly. For those who have not worked with Angular before (myself included) just looking at it, I think that it's more effort than it's worth. Additionally, if we adopted a framework that works in vanilla JavaScript, eg. React, Vue (I'm not advocating using these either) we wouldn't have to convert all our files to TypeScript. From what I've read in the past though, Vue would probably work best for our purposes, due to its speed & its simplicity.

[tlwr]

I think we should attempt to avoid anything that is not "progressive" ("incrementally adoptable" - VueJS website).

Although I have not used TypeScript I have read that it is also incrementally adoptable, in that you can have JS and TS side-by-side and convert one file at a time if necessary. The same I have not heard about React or Angular.

That being said, the few and brief times I have had to touch the src/web folder, it has been quite straightforward to figure out what is going on. Additionally I did not need to read any library/framework docs to get the job done. Therefore I am not convinced the question "Do we need to rewrite the HTML App at all?" has been conclusively answered. Perhaps some more discussion about UI features rather than software tools is required?

Summary

:+1: Vue / TypeScript / "progressive"
:man_shrugging: React / Angular / rewrite

[l50741]

These responses were sort of what I was predicting, my knee-jerk reaction to most projects of this sort is to try and heavily engineer them. In this case a full MVC and build package with a full suite of test tools. While this is all very nice to have it is often a large chunk of work to get the same output as a more ad-hoc approach would achieve in far less time. The benefit of the (possibly over-) engineered approach is that it often saves time in produces a more robust product in the long run (mostly).

However, in this case, in which the product is already in use, and developed by only a handful of people using a few hours of free time, it is hard to figure out if it is worth the hassle.

Honestly, I don't really have an answer for that. I do have some time I could dedicate to this. With the time I have available, it shouldn't be too much of a stretch to say that it would take about a month to properly rebuild CyberChef using some sort of framework. I know almost nothing about the actual operations within CyberChef, so I wouldn't really be much use there anyway.

But that is not the only hurdle, the main problem I see is that the @n1474335 is going to need to be able to continue working on the project they started and if I rewrite it into a framework they would have to learn, does that actually help anyone?

It is very clear CyberChef is a great project, quick and easy to use. However, it does have some problems, which a more engineered solution might help solve. Really, it depends on the direction the project is looking to take.