Frameworks / Libraries
Intro
Scripts provide a single utility Libraries provide utilities for the development process and within applications (MICRO) Frameworks provide opinionated architectures for building applications (MACRO)
Scripts have always enabled experimentation and learning by allowing people to write new and adapt other people's code.
For the frontend, advocates have promoted resilience in web browsers to ignore code segments they don't understand. To support multiple browsers and a range of versions, developers write polyfills and fallback solutions.
Public and community-maintained software for web development picked up speed in the early 2000s on a variety of fronts:
Web Applications
Intro
Rails
Content Management Systems
JavaScript
Developers created projects that provided utilities for easier working with the DOM, making async network calls using XHR, simplified creating reusable components, and provided cross browser support. Two notable JS projects were jQuery and Prototype.
CSS
First came best practices and tools for general styling, layouts, and consistent cross browser rendering. Frameworks followed, often focused on particular UI aspects including grid layouts, forms, typography and menus.
UI Design Systems
Bootstrap emerged in 2010 as a comprehensive visual design framework that included a style language that met the need for consistency required for larger websites and applications.
Choosing a Tool
While the landscape for libraries and frameworks has and will continue to evolve due to varying feature and audience profile needs, the high level characteristics developers may consider include:
Features
Compatibility with your software ecosystem
How widely used and maintained is it?
How easy is it to learn and use?
How productive does it make a developer?
How comprehensive v. focused is it in terms of features?
How heavy is it in file size?
How is the documentation?
Can one select just the features/modules one needs?
What is its stance on convention versus configuration?
Secondary considerations include:
Can actions be customized with configuration objects?
Does it provide sensible default behavior to common actions?
Are on ramps provided to achieve basic functionality?
Does it use or encourage good programming practices?
How are actions called? Can they be chained or composed?
Are errors thrown for obvious misusing actions or providing invalid values?
How are errors communicated?
Debates
Client v. Server Applications
why for each
Seriously question the benefit of added complexity, time, and cost
Go Serverless?
Next Steps
With the basics out of the way, it's up to you whether
Next
Minimalistic framework for server-rendered React applications by Zeit. Features:
Server-rendered by default
Automatic code splitting for each page with option to lazy-load modules and components.
Each endpoint gets its own bundle
Primary routes are defined by files in a "pages" directory
Single page-based client-side routing; dynamic routes handled with query strings
Route masking can be used for pretty URLs or adding server-side routes
Preconfigured Webpack, Babel with less bloat and opinions than CRA
Customizable Webpack dev environment with hot module replacement option
Can use Express or another Node HTTP server
Can use GraphQL, Redux, MobX and other options
Special features:
Prefetch attributes can be added to route navigation that after the current page is finished rendering, will async download the resources for corresponding route(s).
Developer writes one codebase that the app runs on server or client, according to the situation.
To get data when the page loads, the page component has a lifecycle method: getInitialProps. This is
Executed on the server for initial load at an endpoint.
Executed on the client whenever using client-side navigation
A context object for the method provides access to pathname, query, request/response.
Dynamic routes with query strings and link components (with added paths). Adding an "as" attribute to the link component creates the route masking.
Server rendered routes though are by default only enabled for those listed in the "pages" directory. Thereby, routes with queries and dynamic data will return 404 errors if the user refreshes the page.
Solution: Custom API Server Add a Node Web Server. Update dev script to run server.js instead of just calling next. Then setup custom routes.
Gatsby
Give Gatsby React components and it'll compile an optimized site. Inlines critical CSS, uses <link preload /> for critical resources Per-route code/data splitting Prefetch soon-to-be-needed resources
Last updated