Front End Development Guide for Large Engineering Teams
github.com
github.com
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.
var foo = 1;
var bar = foo + 1;"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?
The argument is that if you prevent mutation then you can rely on only a shallow comparison of the object references as a reliable test for whether any of the data has changed. Your shouldComponentUpdate implementation becomes a one-line equality test for each prop that might change, or the equivalent. This may be significantly faster (and potentially easier to maintain) than any more detailed comparison of props to decide whether anything significant has changed in shouldComponentUpdate.
Of course, this doesn't address the performance implications of maintaining your state in some sort of immutable data structures rather than just mutating it. Nor does it address the performance implications of using a library like React that declaratively renders your content and does the whole vDOM diff algorithm thing instead of just poking the DOM in exactly the required places. Both of those strategies can be orders of magnitude slower than the alternatives, and both of them can cause architectural and maintenance headaches of their own, and so the questions in those cases are whether the performance is still good enough and whether the benefits in other respects outweigh those costs.
If your component's state and props are immutable objects, then shouldComponentUpdate becomes a much easier problem to solve.
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)
Immutable.js gives you three primary benefits:
- Its object API largely prevents accidental mutations (although I think it's still possible to make mistakes if you use some of the updater callback methods)
- Internally, it uses specialized data structures that allow "structural sharing" of values. That means that creating a new object based on an existing one doesn't have to copy every single key/value pair onto the new object. This does show perf improvements for copying very large objects (thousands or tens of thousands of keys).
- React perf optimization generally relies on implementing `shouldComponentUpdate` to skip unneeded re-rendering. The standard approach to implementing `sCU` is a shallow equality check that relies on you having handled your data immutably so it can just compare references. React's built-in PureComponent class also implements that approach. As mentioned in other comments, you don't _have_ to use Immutable.js to handle data immutably, but it is one way to do it.
My links list does have links to several discussions of Immutable.js perf [0], and there's specifically one excellent article I've seen that does benchmarks of Immutable.js usage [1] [2]. I also wrote a Reddit comment a while back discussing the reasons why I generally advise against using Immutable.js [3].
As for your comments and questions about app architecture... based on your app description, I don't think Immutable.js would provide any particular speed benefit for you in terms of copying/updating objects. "Enforced immutability", though, _is_ key if you're using Redux, as it's a prerequisite for proper time travel debugging and correct React-Redux UI updates (per my blog post "The Tao of Redux, Part 1 - Implementation and Intent" [4]).
Other than that, my links list does have pointers to many articles about practical usage and lessons learned from real-world React and Redux applications [5] [6].
Your complaints are a bit on the general side, but as always, I'm happy to try to answer any specific questions you might have regarding React and Redux usage.
[0] https://github.com/markerikson/react-redux-links/blob/master...
[1] https://medium.com/@dtinth/immutable-js-persistent-data-stru...
[2] https://www.reddit.com/r/reactjs/comments/5h7pqz/persistent_...
[3] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra...
[4] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
[5] https://github.com/markerikson/react-redux-links/blob/master...
[6] https://github.com/markerikson/react-redux-links/blob/master...
Baby steps. I try to see the silver lining in every cloud.
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.
Incidentally, people at our company who have acquired said combination of wide skill breadth with a specific skill depth, got there because one employer or another (not always us) hired them when they were intent on (or already in the process of) a change of role. For instance, someone with a few years in graphics design who, when given a chance to (or being required to) work with HTML and CSS, found that not only did they like it, they wanted to learn and do more, even if that meant transitioning
There are all sorts of questions I have about how that might fit into the arc of someone's career, how it affects salaries, and so on. Furthermore, I do not think it should be the only lens by which to assess people's skills, at the exclusion of all else. It just seems that many of our A-Players, as it were, came into our organization with that sort of skill distribution, or quickly grew to have it.
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.
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.
I've seen the front end devs you describe in (some) smaller Aussie companies. OTOH every front-end dev I meet in San Francisco does HTML + CSS + JS. In a large enough place, they don't even need the CSS, some other team maintains that and publishes the internal equivalent of http://getbootstrap.com/components/
It makes sense to me that you specialize once you get past a certain team size on the same product.
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...
[1] https://github.com/markerikson/react-redux-links
[2] http://blog.isquaredsoftware.com/2017/02/presentation-react-...
The second issue I have with this is that it is an opinionated tech stack which can lead to poor choices.
[0] https://github.com/markerikson/react-redux-links/blob/master...
[1] https://github.com/markerikson/react-redux-links/blob/master...
[2] https://github.com/markerikson/react-redux-links/blob/master...
[3] https://github.com/markerikson/react-redux-links/blob/master...
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.
You've not been using it that long then! Stay alive and stick with Stage-3
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.
Full disclaimer: It's a commercial product and I'm the lead developer.
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.
After this experience I changed my opinion towards the value of static types, from being more than a nice to have feature.
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).
This is incomplete (to the point of being harmful) if it doesn't discuss and assess compile-to-JS, especially TypeScript.