Frontend rewrite

[zy4]

I know that this might sound a little too ambitious but I think it is not. We should think about rewriting the complete frontend because of multiple reasons:

1. the code is a mess (IMHO)
2. we should discourage the usage of jQuery
3. we need to upgrade mithril at some point anyway which would be a bigger thing as well
4. since we split up the codebase in modules, it would be a shame not to have the frontend code rewritten in scalajs

comments, ideas?

[zy4]

first mandatory or preliminary steps:

1. remove embedded javascript from the templates
2. replace javascript helper functions with mithril components
3. migrate to mithril 1.x
4. do it in scalajs

[vikramalva]

Essentially I think this is a good idea and we could refactor one tool at a time. This could be quiet some work through for tools such as HHpred, PSI-BLAST, and HMMER.

[zy4]

The point is that, if we go from our mithril version to something else, there is no incremental migration but this would be a bigger task. Opening this issue is triggered by two aspirations:

• code quality
• keeping libraries up 2 date

[anjestephens]

I agree that we need to refactor the frontend, but I'm not sure where we should even start. We do have a good outline with the current code, but it was patched over multiple times. We might not be able to find every detail - so, if we are going to do this - we should get an overview of that before even starting on coding the new version.

ScalaJS seems to be ok and I'd like to try it, but I'll have to get up to speed with it first - I would like to avoid my previous mistakes while migrating to other javascript languages - which were mainly due to not knowing how to use that language yet.

At the moment however, I rarely have time to do anything but homework, so it might be a bit hard to achieve.

[zy4]

At the moment I think we can start with:

• finish tslint issue #149 in order to track down the bugs in typescript
• migrate to mithril 1.x
• remove the embedded javascript
• rewrite the helper scripts and try to avoid jQuery where we can

After these steps we can think about

• rewriting mithril 1.x components in scalajs
• use some other framework than mithril, maybe one which natively is made for scalajs, such as: https://github.com/suzaku-io/suzaku https://github.com/UdashFramework/udash-core https://github.com/ThoughtWorksInc/Binding.scala

[felixgabler]

I've decided to start removing some embedded javascript inside the results views. I am using the "mithrilresults" branch.

[felixgabler]

I'm having a few problems with my plans at the moment, because I am not familiar enough with many of typescript's best practices. e.g. I feel like the resultviews and their components should be modularized better, but I cannot decide on a good strategy. Blast-visualization, for example, could probably be combined with the new typescript code extracted from the psiblast hitlist view. All of that would then need to be connected to the new mithril components.

If any of you feel like they have a good understanding of the typescript part in our code and want to give me a hand, I would be very thankful. It could just be proposing a strategy.

If you want to check out the branch, it's called "mithrilresults".

[zy4]

One additional problem is that we use twirl templates which we serialize in order to put them as strings (!) into the mithril components via m.trust() or m.request() - this causes strange effects when we try to use m.mount because the dom elements are neither "real" ones nor mithril vnodes. I think that we should get rid of the twirl templates at all and build a pure SPA.

This would also resolve #117 in some way because this serialization of twirl templates to json strings is a really bad hack.

[zy4]

@felixgabler it will take me a while to figure out what the best (given the fact that I really want to use more scalajs) might be

meanwhile - if you are interested - you can take a look at the tslint branch. the task is kind of straight forward if you know typescript.

[zy4]

At the moment I am in strong favor of suzaku. If anyone is interested to get an overview, please watch this video: https://www.youtube.com/watch?v=nfCGdbfiJGU

[zy4]

Just having a look at https://github.com/OutWatch/outwatch

[felixgabler]

Some of my thoughts on the subject:

• suzaku's github page states: Suzaku is currently in experimental stage, going through a lot of changes and improvements. It's not quite ready for building applications but contributors are most welcome! So I definitely think we should stay away from using it.
• OutWatch seems too small for us. We should use something where long term support is certain. This is not a place to play around with small frameworks to test them. Will just be more work in the future.
• Stability > Speed
• I don't think we need something very complicated for our use case. Small and Simple is the way to go here.
• It should be in a language which not all of us have to learn from scratch -> better code quality from the beginning, faster development

[zy4]

I agree on the framework level. Can we pick a transpiler language first? I think it would be highly favorable to use ScalaJS because of our codebase. If it wasn't for having Scala, I would pick something else, most likely elm or bucklescript but ScalaJS seems to be the way to go.

So if we stick to ScalaJS, there are (if not using a native framework) only binding options whereas I assume to use either one of these:

1. stick with mithril since we know it quite well and it is a JS framework for people with an affinity to jquery-based libraries. Very little boilerplate but maybe too much freedom.
2. react - best supported sclajas bindings library with good long term prospects.
3. something else, e.g. vuejs

[zy4]

I want to dive a little deeper into the ScalaJS-or-not-topic. Basically it all depends (given the list of contributors we have) on you, @felixgabler , because @anjestephens already agreed to use ScalaJS. So you would need to make up your mind whether you want to pick up Scala and all connected design-patterns in the process or not. Otherwise we would most likely stick with TypeScript and rewrite it in TS.

[felixgabler]

I'm fine with using scalaJS.

Seung-Zin Nam notifications@github.com schrieb am Sa., 23. Dez. 2017, 14:06:

I want to dive a little deeper into the ScalaJS-or-not-topic. Basically it all depends (given the list of contributors we have) on you, @felixgabler https://github.com/felixgabler , because @anjestephens https://github.com/anjestephens already agreed to use ScalaJS. So you would need to make up your mind whether you want to pick up Scala and all connected design-patterns in the process or not. Otherwise we would most likely stick with TypeScript and rewrite it in TS.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zy4/Toolkit/issues/150#issuecomment-353725287, or mute the thread https://github.com/notifications/unsubscribe-auth/AaEXSAe9cuNEkE4MdybPzSF5ZEM8bW_Aks5tDPrNgaJpZM4QXIB2 .

[felixgabler]

Maybe we could already also have a list with things to keep in mind while outlining and developing aspects of the new frontend. This could also help choose the framework. I cannot come up with much off the top of my head but I'm even thinking of things like a debug mode so we can silence console outputs. This might reduce future issues if some guidelines of our own are developed already.

[zy4]

The biggest concern for me is the size of the task itself. There is only one way to have something like "incremental migration" which seems to be the only reasonable approach:

migrate from ts to scalajs by using mithril in it's current version

So should we go this easy path?

[felixgabler]

I just feel like I don't have enough of an overview of the project's size. I believe, however, that should try to use the new version of mithril if we decide to go with that. I propose the following approach:

• Make a list of issues and goals we want to address/achieve with the rewrite.
• Choose the right framework considering this list
• Plan each part of the site (user management, result views, joblist, etc) and their functionalities.
• Divide the workload for all of us interested
• Maybe also have some kind of code reviewing process, so the mess is minimal

What do you think?

[zy4]

code inspection by codacy would by a nice 2 have. it unfortunately expired since it was only on trial for the private repo.

New mithril is okay but a task itself which is big. Can we first migrate to mithril 1.x in typescript then? This would be preliminary and none of the points above has to be discussed besides who does what.

This task is better be done by one single person alone. Who volunteers? :face_with_thermometer:

[vikramalva]

We have multiple validation processes running which decide on whether the button is disabled or not. We should have a FSM for buttons and validation responses in general written in client-side logic, maybe in scalajs.

[vikramalva]

Let us not forget to think of SEO when refactoring the frontend.

[zy4]

Interesting article about one ouf our main issues: https://vsavkin.com/managing-state-in-angular-2-applications-caf78d123d02

[zy4]

closing in favor of #443