
Front End Development Guide for Large Engineering Teams - yangshun
https://github.com/grab/front-end-at-grab
======
acconrad
I was hoping this would be a guide on managing architectures, common use case
traps for handling things like scalability and state. Instead this is just a
long-winded way of recommending an opinionated front-end tech stack with
resources to learn those stacks. Was not exactly what I was hoping for.

~~~
BigJono
Yep, this is just rehashing the same stuff you can find on any one of 1000
other blog posts, articles or pieces of documentation.

The current literature on front-end development in React is woefully short on
real world case studies. It seems like everyone is building 30k loc throwaways
with a 40 library boilerplate and slathering the internet with masturbatory
praise for all the tooling and architectural patterns involved. If you try and
Google for any actual details about said libraries, it's buried under mounds
of beginner tutorials and faux praise.

For example, we just made the decision to use ImmutableJS in a project.
Everyone else on the team seems to be happy enough just reading a few blog
posts about how great it is and then throwing it into the mix. I have a bunch
of questions though, where are all the benchmarks? The docs, and everyone
else, claims massive speedups from using immutable data structures, but it's
never accompanied by any actual metrics, at least as far as my Google-fu gets
me. All of our data lists are paginated server side, we're not doing any mass
inserts on large data structures anywhere, and I've never noticed a
performance problem on anything else I've written with similar requirements,
so I find the claim that ImmutableJS is somehow going to speed up our app to
be dubious at best. Moreover, every article under the sun craps on about how
great it is to "enforce immutability", but nobody seems to be able to tell me
when they last encountered a bug due to an inadvertant mutable update, how
much time it cost them, or why they're hiring people who make such elementary
mistakes in the first place; or if they do, it's some airy parable with no
code example of the bug or the ImmutableJS code that could have fixed it.

~~~
z3t4
You don't need a library. Just have a policy that everything should be
immutable by default and only turn into mutable objects when optimizing, for
example for-loops. The benefit with immutability is not performance (it's
actually slower) but manageability and debug-ability. It's easier to reason
about code when the variables doesn't change, and you'll get all the variable-
states when debugging. Example:

    
    
      var foo = 1;
      var bar = foo + 1;

~~~
didgeoridoo
The "Performance" section of Facebook's own React docs has this line at the
end:

"Immutable data structures provide you with a cheap way to track changes on
objects, which is all we need to implement shouldComponentUpdate. This can
often provide you with a nice performance boost."

What I don't really get is, if you've implemented PureComponent and
shouldComponentUpdate wherever possible, how can adding Immutable possibly
improve performance? I.e. if your components are ASSUMING their inputs are
immutable, how does throwing errors on mutation attempts actually speed things
up?

~~~
eyko
With immutable objects, you can compare them (obj1 === obj2) and assume that
if they're the same, none of the properties have changed. You don't have that
sort of guarantee with normal JavaScript objects, so you need to do a deep
comparison.

If your component's state and props are immutable objects, then
shouldComponentUpdate becomes a much easier problem to solve.

~~~
BigJono
That's not what GP was saying.

The standard, non-library way of handling state in React is to use plain old
mutable Javascript objects, and just pretend they're immutable (i.e never
perform any mutable operations on them). The popular claim is that Immutable
"enforces" immutability, leading to less "accidental mutation" bugs. (A claim
which is bogus IMO. 0 !< 0)

~~~
acemarke
No, I'd say it's a _fairly_ valid claim. You have to interact with
Immutable.js objects using its API, and every update API call returns a new
instance. So, it _does_ generally enforce immutability. As far as I know, the
only way to accidentally mutate stuff with Immutable.js is if you insert plain
JS objects inside an Immutable.js object, and possibly also use one of its
"update this using a callback function" methods and misuse things inside the
callback.

~~~
BigJono
The bogus claim is that it leads to less bugs, not that it enforces
immutability. It very obviously does that.

------
flor1s
Maybe I'm confused, but I always thought front-end development included
graphics design. It seems like this guide does not discuss graphics design at
all. I don't just mean Photoshop, but also subjects like when/where to use
which color, typography, etc. Also this guide contains no information about
other product design disciplines such as requirements gathering etc.

I was working for a Dutch company a few years ago and our front-end developers
worked closely with the graphics designers and the back-end developers to be
able to properly do their work. We also had a business analyst who was working
more on requirements gathering. In the end the entire team was however
responsible for creating a good product for the customer.

~~~
HappyTypist
I've never heard of front end development include graphics design.

~~~
stupidcar
"Front end development" didn't exist as a separate software development
discipline until a few years ago. Before that, you had "web developers" for a
while, and before that, "web designers". These latter two categories were
people whose primary responsibility was to translate Photoshop designs into
HTML and CSS, and for that they needed, at least, a strong eye for visual
design. Their use of JavaScript was limited to use of libraries like
Scriptalicious, Mootools and (later) jQuery to add "Web 2.0" enhancements.
Oftentimes they were simply designers who'd learnt HTML and CSS in order to
help accurately translate their own designs, either because there was nobody
else to do it, or because they couldn't entrust it to back-end programmers.

Although the roles of designer and front-end developer were gradually
bifurcating by around 2010, if you were recruited by an agency as a front-end
developer, you were still almost certainly expected to demonstrate graphics
design abilities, and would often be considered part of the design team than
the programming team. It was only really with the rise of Single Page
Applications that you started to see front-end development completely shed its
origins as a adjunct to a designer's role.

~~~
Silhouette
The picture was never quite as black and white as you're suggesting, I think,
though certainly there were plenty of the kind of people you mentioned around.
For example, some people working in web world have always just built stuff
directly in-browser rather than slicing Photoshop images. This wasn't a new
idea when responsive sites came along, nor when SPAs started to become a
serious business; those trends just provided more awareness to some people who
hadn't thought of working that way before. Some people expanded from a
programming background into making more interactive web sites rather than from
a design background, and it probably would never have occurred to them not to
at least consider building with the native technologies from day one.

It's true that as those front-end technologies develop, more substantial
programming work is being done on the browser side, and so there has been a
degree of specialisation in the roles involved, particularly in larger
organisations. Even so, I'm not personally a fan of trying to maintain too
strict a division between those roles. As with almost anything in a technical
field, if you don't have at least a basic working knowledge of related skills
and technologies, you're probably not going to be very good at whatever
specialist task you're trying to do either. Similarly, if some key decisions
and resources aren't managed by all of the relevant people collectively,
problems will inevitably creep in for those who weren't as involved as they
should have been.

------
acemarke
It's an excellent set of advice and resources. Good explanations of why each
topic matters and what it includes, with links to a few selected resources for
each topic and an estimate for study time. I've already added it to my
standard advice for getting started with React.

I'm _very_ pleased to note that the guide links to my "(R)Evolution of Web
Development" presentation [0] and my React/Redux links list [1], and that a
number of the other articles referenced are definitely based on my links list
contents too :) (Also, for good measure, I'll toss in a link to my "Intro to
React and Redux" presentation here as well [2].)

[0]
[http://blog.isquaredsoftware.com/presentations/2016-10-revol...](http://blog.isquaredsoftware.com/presentations/2016-10-revolution-
of-web-dev/)

[1] [https://github.com/markerikson/react-redux-
links](https://github.com/markerikson/react-redux-links)

[2] [http://blog.isquaredsoftware.com/2017/02/presentation-
react-...](http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-
intro/)

------
graphememes
This is less for "Large Engineering Teams" and more for beginners who don't
know about the current landscape.

The second issue I have with this is that it is an opinionated tech stack
which can lead to poor choices.

------
darklrd
It's a great guide with excellent suggestions along the way. I would suggest
adding few links on React Optimization to it. A guide on how to break React
components and how to implement store/state once you start to scale would be
very helpful. :)

~~~
acemarke
This guide is meant as an overview of an array of technologies. My React/Redux
links list, on the other hand, has you covered :) See the "React Performance",
"React Architecture", "React Component Patterns", and "Redux Architecture"
sections:

[0] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/react-performance.md)

[1] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/react-architecture.md)

[2] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/react-component-patterns.md)

[3] [https://github.com/markerikson/react-redux-
links/blob/master...](https://github.com/markerikson/react-redux-
links/blob/master/redux-architecture.md)

~~~
andrewjrhill
Your list has been absolutely instrumental in my path towards mastering
react/redux. A big thank you for all the hard work. You are multiplying the
communities knowledge and we're all improving because of it.

~~~
acemarke
Thanks! Comments like yours are why I keep working on updating my lists :)

------
kuharich
Grab is the Southeast Asia rival to Uber. Their stronghold is in Singapore,
but they're the market leader in that region. Alibaba is looking to invest in
their $1.4 billion upcoming round led by Softbank. I know for a fact that they
are creating a technical, iOS development center of excellence in Seattle ...

~~~
flor1s
Or maybe the Southeast Asia rival to Didi Chuxing?

~~~
kuharich
Excellent point. My American bias is showing ...

------
dlwdlw
I've always disliked these top down plans that require so much setup and
upfront work. The best tools I've worked with are progressive in their
discovery and mastery of features without lowering the ceiling too much.
Sublime for example has a command palette to just fuzzy type your desired
command as a fallback, showing the shortcut key right next to the command as
well. Vue also markets itself as having this type of "progressiveness".

Reminds me of vim fans. There's always an undercurrent of elitism or hazing
where something "hard" must be done to be "worthy" of some sort of goodness.

------
sidhuko
"At Grab, we use ES2015 (with Babel Stage-0 preset) to enjoy the productivity
boost from the syntactic improvements the future of JavaScript provides and we
have been loving it so far."

You've not been using it that long then! Stay alive and stick with Stage-3

~~~
tracker1
Well, async/await and several other features were held up at stage1/2 for a
long while. I found quite a few things very valuable far earlier on...
async/await, object rest/spread, class (static) property syntax.

Now most of it is stage-3 or in-browser, so not a bad decision, but for a long
time, you really wanted to be at stage-0/1 and deal with a bit of pain should
things change.

~~~
sidhuko
Async/await was the pitfall for one project as they weren't just held up but
they changed API during experimental implementations. Less concerning now you
can write codemods to transform but if you don't own the code it's better to
keep your client a little behind and safer.

------
mstijak
For large apps and teams, I would recommend CxJS. CxJS is based on React and
offers a more streamlined development experience with a built-in library of
widgets and charts, themes (including Material), and other features such as
form validation, form layouts, culture-sensitive number and date formatting,
optional two-way data binding and much more.

Full disclaimer: It's a commercial product and I'm the lead developer.

[https://cxjs.io](https://cxjs.io)

------
partycoder
The wide adoption of Flow and TypeScript means that people are starting to
realize that explicitly typed code is easier to maintain than implicitly typed
code.

Hopefully a new EcmaScript version adds the ability to specify types. It's
either that or people opting out of JS in favor of wasm based tech in the near
future.

~~~
tracker1
I think it largely falls to the size and discipline of the teams doing the
work. I get by pretty well without them, but if I had to coordinate with over
20 other developers working in a single codebase, then I'd have a differing
opinion. I'd also be pushing for 100% test coverage as it's _FAR_ easier to do
in JS than it is in other languages. Of course, adding types makes it harder
again.

~~~
fedlarm
I used to share this opinion as well, until I started working on an internal
library that was created by a skilled developer. He had very good test
coverage and good quality tests, which turned out invaluable, once I got on
board. We tried to move to library towards being fully typed in TypeScript,
just to get some experience with TypeScript. Our first thought before starting
was, that it would help, but didn't expect it to have a significant impact.
During the port to TypeScript (and being strict on typing everything
possible), we soon found numerous unexpected behaviors in the code. Some of
the issues found, could have been found by a linter, but other things like
models changing over time was only found due to adding static types.

After this experience I changed my opinion towards the value of static types,
from being more than a nice to have feature.

------
mrisoli
This was a disappointing read, coming from such a large company, looking like
a disposable blog post.

It makes it sound like front end development is about knowing CSS, react and
redux, these are good options of tools for the job, not essential ones,
especially when Vue and Angular are still big in the scene.

Maybe I'm wrong about my own profession, as some other comments said, it is
often blurry and in the past it used to be more related to graphics design
even, but for me front end development is about programming, just as full
stack but without worrying about business logic that is supposed to rely on
the backend. This can include design(as in CSS, colors, grids, fonts,
responsiveness), but also worrying about the delivery mechanisms(some API
level knowledge, browser vendors), including performance(consider crappy or
inconsistent networks).

------
daliwali
There's nothing in this guide that couldn't be found on 1000s of other
introductory blog posts. This is just "What to Use With React 2017". I find it
almost disturbing that front-end jobs around the world have adopted a set of
opinionated tools that are so needlessly complex and churn at an amazing rate,
and devs themselves have such a cavalier attitude about it. The self-
congratulatory praise is deafening.

------
ng12
I'm surprised that Flow is recommended over Typescript. Flow's main strength
seems to be the ability to slowly integrate it into a large existing project.
Since this guide seems to be targeted at new applications I don't see why
Typescript wouldn't be the better choice.

------
kayimbo
and.... my eyes glaze over.

------
duncanmeech
Yawn....just another React/Redux fan boy blog.

------
smt88
EDIT: My mistake. I found it.

This is incomplete (to the point of being harmful) if it doesn't discuss and
assess compile-to-JS, especially TypeScript.

~~~
biggestlou
There is a section on TypeScript and Flow

~~~
smt88
I scrolled down and searched and didn't find it. Not sure why it didn't work.

------
CryoLogic
Funny, if you just suggested EmberJS you could cut out a large portion of this
guide. Good guide nonetheless for those looking to hack together their own
front-end stack.

