grab / front-end-guide

Grab Front End Guide == _Credits: Illustration by @yangheng_ _This guide has been cross-posted on Free Code Camp._ Grab is Southeast Asia (SEA)'s leading transportation platform and our mission is to drive SEA forward, leveraging on the latest technology and the talented people we have in the company. As of May 2017, we handle 2.3 million rides daily and we are growing and hiring at a rapid scale. To keep up with Grab's phenomenal growth, our web team and web platforms have to grow as well. Fortunately, or unfortunately, at Grab, the web team has been keeping up with the latest best practices and has incorporated the modern JavaScript ecosystem in our web apps. The result of this is that our new hires or back end engineers, who are not necessarily well-acquainted with the modern JavaScript ecosystem, may feel overwhelmed by the barrage of new things that they have to learn just to complete their feature or bug fix in a web app. Front end development has never been so complex and exciting as it is today. New tools, libraries, frameworks and plugins emerge every other day and there is so much to learn. It is imperative that newcomers to the web team are guided to embrace this evolution of the front end, learn to navigate the ecosystem with ease, and get productive in shipping code to our users as fast as possible. We have come up with a study guide to introduce why we do what we do, and how we handle front end at scale. This study guide is inspired by "A Study Plan to Cure JavaScript Fatigue" and is mildly opinionated in the sense that we recommend certain libraries/frameworks to learn for each aspect of front end development, based on what is currently deemed most suitable at Grab. We explain why a certain library/framework/tool is chosen and provide links to learning resources to enable the reader to pick it up on their own. Alternative choices that may be better for other use cases are provided as well for reference and further self-exploration. If you are familiar with front end development and have been consistently keeping up with the latest developments, this guide will probably not be that useful to you. It is targeted at newcomers to front end. If your company is exploring a modern JavaScript stack as well, you may find this study plan useful to your company too! Feel free to adapt it to your needs. We will update this study plan periodically, according to our latest work and choices. *- Grab Web Team* **Pre-requisites** • Good understanding of core programming concepts. • Comfortable with basic command line actions and familiarity with source code version control systems such as Git. • Experience in web development. Have built server-side rendered web apps using frameworks like Ruby on Rails, Django, Express, etc. • Understanding of how the web works. Familiarity with web protocols and conventions like HTTP and RESTful APIs. Table of Contents • Single-page Apps (SPAs) • New-age JavaScript • User Interface • State Management • Coding with Style • Maintainability • Testing • Linting JavaScript • Linting CSS • Formatting Code • Types • Build System • Package Management • Continuous Integration • Hosting and CDN • Deployment • Monitoring Certain topics can be skipped if you have prior experience in them. Single-page Apps (SPAs) Web developers these days refer to the products they build as web apps, rather than websites. While there is no strict difference between the two terms, web apps tend to be highly interactive and dynamic, allowing the user to perform actions and receive a response for their action. Traditionally, the browser receives HTML from the server and renders it. When the user navigates to another URL, a full-page refresh is required and the server sends fresh new HTML for the new page. This is called server-side rendering. However in modern SPAs, client-side rendering is used instead. The browser loads the initial page from the server, along with the scripts (frameworks, libraries, app code) and stylesheets required for the whole app. When the user navigates to other pages, a page refresh is not triggered. The URL of the page is updated via the HTML5 History API. New data required for the new page, usually in JSON format, is retrieved by the browser via AJAX requests to the server. The SPA then dynamically updates the page with the data via JavaScript, which it has already downloaded in the initial page load. This model is similar to how native mobile apps work. The benefits: • The app feels more responsive and users do not see the flash between page navigations due to full-page refreshes. • Fewer HTTP requests are made to the server, as the same assets do not have to be downloaded again for each page load. • Clear separation of the concerns between the client and the server; you can easily build new clients for different platforms (e.g. mobile, chatbots, smart watches) without having to modify the server code. You can also modify the technology stack on the client and server independently, as long as the API contract is not broken. The downsides: • Heavier initial page load due to loading of framework, app code, and assets required for multiple pages. 1 • There's an additional step to be done on your server which is to configure it to route all requests to a single entry point and allow client-side routing to take over from there. • SPAs are reliant on JavaScript to render content, but not all search engines execute JavaScript during crawling, and they may see empty content on your page. This inadvertently hurts the Search Engine Optimization (SEO) of your app. 2 . However, most of the time, when you are building apps, SEO is not the most important factor, as not all the content needs to be indexable by search engines. To overcome this, you can either server-side render your app or use services such as Prerender to "render your javascript in a browser, save the static HTML, and return that to the crawlers". While traditional server-side rendered apps…