Rewrite client in JS/TS and take advantage of client-side templating

[artasparks]

I propose rewriting the client to rely on client-side templating rather than server-side templating. I have significant experience with AngularJS/AngularMaterial so that would be my preference. I could also see using TypeScript + Angular2.

One downside is it means the build is more complicated. However, moving the view-logic fully client-side makes for a far richer UI.

[duckpunch]

I'm not opposed to this generally, but I'm curious about what feature you're looking to get out of it.

[artasparks]

I think there are several wins:

• It's easier to build in cool features like pop-ups or loading parts of the page.
• I think Angular Material is pretty cool and makes pretty UIs
• Protractor integration tests are awesome and tie really well into Angular.

So, arguments (2) and (3) really come from my experience using Angular. I previously spent lots of time migrating off of Soy (Closure Templates) onto AngularJS and the developer experience was much nicer.

[duckpunch]

Agreed on the cool features front. Not sure how that plays with timing.

Is there a deadline for OR?

[artasparks]

This isn't tied to a release and I don't see it as blocking for v1. I'll get to it if I have time. I've been thinking it's good to file issues for ideas to track them somewhere. As a side note, we should probably start creating milestones and tagging blocking issues to the relevant milestones.

[duckpunch]

Got it. In that case, sounds good!

On the topic of the ticket, how do you feel about doing this in a separate repo?

[artasparks]

On the topic of the ticket, how do you feel about doing this in a separate repo?

It might make sense long-term, but for now it's probably good to keep it in the same repo while we iterate on api. Also, I don't know how you'd do Protractor/webdriver style tests on Javascript in a separate repo, which could be a significant blocker.

[duckpunch]

Seems like iterating on the API and iterating on view code are two separate things.

In dev, it seems you could just have both up and running to do your testing. In CI, I think something akin to full stack testing is less important at this juncture.

I subscribe to the notion of the testing ice cream cone as an anti-pattern. Martin Fowler calls it a Test Pyramid.

[duckpunch]

The advantages you get are that you can rev, build, and package independently. Also, your integration points become pretty deliberate and explicit.

Anyway, not a point to get stuck on. I could see it working in the same repo for now.

[artasparks]

Those are good points and I especially take your point about being able to version and package independently. While OR still serves the JS/CSS resources, I'd make the case that these the JS should be included next to the job, but if they were served from a CDN or somewhere then it I agree that a separate repo would clearly be the way to go. Definitely a good idea to keep around.