Web UI Frameworks

[allymparker]

Okay, fun time!

Current "adopt" stack for Web UI:

• React
• Redux/react-redux (If needed)
• fetch
• Honeycomb Web Tool Kit
• moment JS
• HighCharts +
• lodash
• SASS
• SignalR

Build:

• Webpack
• Babel

Old UI frameworks

• KnockoutJS - Endure
• RX.js - Retire
• jQuery - Retire

Question: There's definitely a time and a place to use server side rendering ie Razor/MVC, especially when experimenting or if we don't need client side interactions. What ring would that go in?

[tugberkugurlu]

@andrew-farries do you see anything we should be having here?

[nyctef]

Do we need to put all the libraries we use on here?

We've got roughly the same setup for Figleaf, but

• we heavily adopt redux (with a preference for putting logic in redux when possible)
• we use postcss-loader / autoprefixer alongside honeycomb WTK
• we don't use lodash (afaik typescript/ESwhatever have provided everything we need in that area, might be missing something though)
• we don't use signalR / highcharts (no need yet)
• we use typescript instead of Babel
• we use a few more libraries around react/redux (react-modal, react-motion, react-select, react-virtualized, redux-logger, redux-thunk, reselect) which are of varying usefulness
• we use prettier for opinionated formatting (heavily recommend)
• we use jest and enzyme for unit testing (although we have very few enzyme-specific tests since we haven't found react component testing to be that useful)
• we use electron/spectron for installed product tests

[deneboulton]

Out of curiosity why is RxJs labelled as 'old'?

Its usage is on the up more so than ever before - it is intrinsic to latest Angular, it sees use across the community, it has reference implementation in a ever growing list of programming languages so experience with it is transferable from one to another.

[deneboulton]

I can highly recommend Jest for testing Typescript/Javascript and Enzyme has worked well for us. Depending on what/how you want to test then Cypress is worth exploring.

[andrew-farries]

Things we (the @red-gate/spiders) team are using that haven't been mentioned yet:

• create-react-app. We'd definitely recommend this, though at some point you are going to need to know what your build tools are doing.
• draftJS We are building a search/filter bar using this. I believe Figleaf also uses this.
• react-router. This is absolutely central to building the SPA for the Data Catalog.
• tslint - Linters are essential when you are writing JS but they are also worthwhile for TS.

I'm not sure what level of granularity the tech radar for web technology needs to be. Is it enough to say 'adopt react/redux'?. What about redux-thunk for handling async actions? Is that important enough to go on the radar? Does every npm package we install need to be evaluated in terms of its position on or absence from the tech radar? The latter would be pretty restrictive given how small and focused a lot of the libraries in JS-land are. For example we are using classnames to make building CSS classnames a bit more readable, but it feels like it doesn't belong on a tech radar.

[andrew-farries]

Something we should consider for Explore:

• GraphQL - an alternative to REST APIs that is gaining a lot of popularity.

[nyctef]

Whoops, yeah, that Figleaf list is still missing a few things.

• draftJS We are building a search/filter bar using this. I believe Figleaf also uses this.

I'd say we should recommend draftjs, but with a huge caveat to only use it if it's solving a problem you can't solve some other way - it's a hugely powerful but complicated piece of kit.

• react-router. This is absolutely central to building the SPA for the Data Catalog.

This one's interesting - at the moment Figleaf doesn't have anything like react-router: it just has a simple reducer which tells the app which page it's on. Currently we can get away with this since we're a SPA running in electron, so the user doesn't actually get to see a URL anywhere or need to care about history. I've read about various problems trying to get redux and react-router to line up nicely, but I don't know how much of a problem they are in real life. If we ever get the need I'd quite like to explore building out routing from the redux end to see how well that works.

Does every npm package we install need to be evaluated in terms of its position on or absence from the tech radar?

This is a good point - the moratorium blog post makes it sound like this is the case, but it probably is overkill for smaller libraries like classnames or uuid (which we're also currently using). @fffej what's your take on this?

[fffej]

Does every npm package need to be evaluated in terms of its position on or absence from the tech radar

With NuGet the libraries are "chunkier" so having all the libraries there feels plausible. JavaScript has a very different outlook (see On the Impact of Micro-Packages...).

What about if we exclude micro-libraries? uuid and classnames both have zero dependencies (and all the others mentioned on this thread don't).

Shall we exclude NPM micro-libraries (those with zero dependencies) from the tech radar?

[andrew-farries]

Shall we exclude NPM micro-libraries (those with zero dependencies) from the tech radar?

I vote yes, we should exclude them. The radar will be too cluttered with irrelevant detail otherwise.

[ChrisHurley]

We also use draftjs for our search bar (possibly a bit of a specific use for a rather more general library).

We use pegjs to generate a parser for the search bar.

We've ended up with both react-select and react-autocomplete, sadly, because react-select doesn't support a behaviour we needed.

We actually use underscore rather than lodash, but I imagine we could move across. We've used it recently for groupBy, for example; we could reimplement it ourselves using ES6 if we wanted, though, but it's nice to have a library function you're fairly confident works.

[garethbragg]

Point of interest: Enzyme is the in Adopt section of Thoughtworks' own tech radar:

Enzyme has become the defacto standard for unit testing React UI components. Unlike many other snapshot-based testing utilities, Enzyme enables you to test without doing on-device rendering, which results in faster and more granular testing. This is a contributing factor in our ability to massively reduce the amount of functional testing we find we have to do in React applications. In many of our projects it’s used within a unit testing framework such as Jest.

[allymparker]

Out of curiosity why is RxJs labelled as 'old'?

@deneboulton We have a bunch of VERY legacy rx.js based UIs in SQM - It is Microsoft Reactive Extensions for JavaScript but is pre-2013. We have exactly 0 hope of ever upgrading to the latest RX.js

[deneboulton]

Thanks for clarifying @allymparker . $0.02: To me that feels like an exercise in deciding what you should replace you legacy code with and not, at least in the first instance, to inform a "contemporary" tech radar using old standards?

Unless a broader consensus exists - that RxJS should not be used - then would it simply be a matter of being explicit, e.g. denoting that you deem this to be "legacy rxjs"? Sticking my nose in because I like RxJS and COREDev has recently used it (v6).

[fffej]

Let's pick this up again and find out what we've reached agreement on 😄

This list of things doesn't seem controversial from what I've read ⬆️ there?

Adopt:

• React
• Honeycomb Web Tool Kit
• SignalR
• Webpack
• Babel
• Enzyme

Endure:

• KnockoutJS

Retire:

• jQuery

[allymparker]

As dumb as it sounds, (and if it goes into the tech radar I don't know) but it'd be nice to define some commonly used utility libs too eg lodash vs underscore, moment, numeral etc too. Thoughts?

Moved to #90

[fffej]

@allymparker Could you create a separate issue for JS utility libs? This issue feels too broad to make much progress with at the mo'.

[allymparker]

@ffej Can we add Redux to Adopt too (with the caveat only if needed?)

[allymparker]

Oh and SASS for styling

[fffej]

Adopt:

• React
• Honeycomb Web Tool Kit
• SignalR
• Webpack
• Babel
• Enzyme
• Redux (caveat if needed)

Endure:

• KnockoutJS

Retire:

• jQuery

Anyone disagree with this lot? 👍 if you agree (if I see a handful I'll create a PR). 👎 and some follow-up comments if something's controversial.

We'll try and unpack the rest of this issue as separate issues to help close this one out.

[fffej]

I created a PR and asked @allymparker and @deneboulton to review as they've contributed the most to this thread.

If everyone's happy I think the next step is to merge (which will resolve this comment) and break out any further issues into new issues.