Visit https://ebooknice.

com to download the full version and

explore more ebooks

(Ebook) TypeScript Crash Course: A hands-on guide to

building safer and more reliable web applications by
Daniel Cavalcante ISBN 9789355516763, 9355516762

_____ Click the link below to download _____

https://ebooknice.com/product/typescript-crash-course-
a-hands-on-guide-to-building-safer-and-more-reliable-
web-applications-58472656

Explore and download more ebooks at ebooknice.com

Here are some recommended products that might interest you.
You can download now and explore!

(Ebook) Learning React: A Hands-On Guide to Building Web Applications

Using React and Redux by Kirupa Chinnathambi ISBN 9780134843551,
013484355X

https://ebooknice.com/product/learning-react-a-hands-on-guide-to-
building-web-applications-using-react-and-redux-10441946

ebooknice.com

(Ebook) MySQL Crash Course - A Hands-on Introduction to Database

Development by Rick Silva ISBN 9781718503014, 1718503016

https://ebooknice.com/product/mysql-crash-course-a-hands-on-
introduction-to-database-development-50587256

ebooknice.com

(Ebook) Python Crash Course: A Hands-On, Project-Based Introduction to

Programming by Eric Matthes ISBN 9781593276034, 1593276036

https://ebooknice.com/product/python-crash-course-a-hands-on-project-
based-introduction-to-programming-5417350

ebooknice.com

(Ebook) Python Crash Course - A Hands-On, Project-Based Introduction

to Programming by Eric Matthes ISBN 9781593279288, 1593279280

https://ebooknice.com/product/python-crash-course-a-hands-on-project-
based-introduction-to-programming-10975236

ebooknice.com
(Ebook) Python Crash Course: A Hands-On, Project-Based Introduction to
Programming, 2nd Edition by Eric Matthes ISBN 9781593279288,
1593279280

https://ebooknice.com/product/python-crash-course-a-hands-on-project-
based-introduction-to-programming-2nd-edition-42372086

ebooknice.com

(Ebook) Python Crash Course: A Hands-On, Project-Based Introduction to

Programming, 2nd Edition by Eric Matthes ISBN 9781593279288,
1593279280

https://ebooknice.com/product/python-crash-course-a-hands-on-project-
based-introduction-to-programming-2nd-edition-42372088

ebooknice.com

(Ebook) Python Crash Course: A Hands-On, Project-Based Introduction to

Programming, 2nd Edition by Eric Matthes ISBN 9781593276034,
9781593279288, 1593276036, 1593279280, 2015018135

https://ebooknice.com/product/python-crash-course-a-hands-on-project-
based-introduction-to-programming-2nd-edition-32180636

ebooknice.com

(Ebook) React 16 essentials : a fast-paced, hands-on guide to

designing and building scalable and maintainable web apps with React
16 by Boduch, Adam; Fedosejev, Artemij ISBN 9781787126343, 178712634X

https://ebooknice.com/product/react-16-essentials-a-fast-paced-hands-
on-guide-to-designing-and-building-scalable-and-maintainable-web-apps-
with-react-16-6856718
ebooknice.com

(Ebook) Trail guide to the body A hands-on guide to locating muscles,

bones and more (5th Ed.) by Andrew Biel, LMP ISBN 9780982978658,
0982978650

https://ebooknice.com/product/trail-guide-to-the-body-a-hands-on-
guide-to-locating-muscles-bones-and-more-5th-ed-44708506

ebooknice.com
 TypeScript
Crash Course
A hands-on guide to building
safer and
more reliable web
applications

Daniel Cavalcante

www.bpbonline.com
First Edition 2024

Copyright © BPB Publications, India

ISBN: 978-93-55516-763

All Rights Reserved. No part of this publication may be reproduced, distributed

or transmitted in any form or by any means or stored in a database or retrieval
system, without the prior written permission of the publisher with the exception
to the program listings which may be entered, stored and executed in a
computer system, but they can not be reproduced by the means of publication,
photocopy, recording, or by any electronic and mechanical means.

LIMITS OF LIABILITY AND DISCLAIMER OF WARRANTY

The information contained in this book is true to correct and the best of author’s
and publisher’s knowledge. The author has made every effort to ensure the
accuracy of these publications, but publisher cannot be held responsible for any
loss or damage arising from any information in this book.

All trademarks referred to in the book are acknowledged as properties of their

respective owners but BPB Publications cannot guarantee the accuracy of this
information.

www.bpbonline.com
 Dedicated to

My amazing son Pedro

and
My supporting parents and family
 About the Author

Daniel Cavalcante has been working as a developer for

more than 15 years. He has worked on Frontend, Backend,
and mobile development for companies in Brazil, United
States and Europe. He graduated from journalism and
always aspired to be a writer, but his interest in technology
and the web led to a career as a self-taught developer.
Working with advertising agencies in São Paulo he has
created websites and applications for companies like
Johnnie Walker, Mattel, and large Brazilian brands like Sadia.
He has been a speaker at conferences like React CWB. For
the past years, he has been working remotely for companies
like Osmosis, an American startup that was acquired by
Elsevier, world's largest scientific publisher. Currently, he
provides consultancy (and talks about technology) through
his company Lightcode.
 About the Reviewer

Jahred Love has been a software engineer for nearly three

decades. He has worked with some of the world's biggest
and well-known companies, producing cutting-edge R&D.
His most recent enterprise is Xirsys, which provides tools
and software for real-time communication. Jahred is a leader
in the field of WebRTC and currently heads the Voice Quality
department for a well-known global telecommunications
company.
 Acknowledgement

I am truly thankful for the unwavering support and

encouragement from my parents, George and Noeme, and
my son Pedro, for inspiring me to be more creative and
bolder. I am also thankful to my siblings Marina, Carolina
and David.
I also extend my thanks to BPB Publications for their expert
guidance and support in bringing this book to life. The
process of textual and technical revision was a collaborative
effort that enriched both the quality of this book and my
technical knowledge.
I also want to highlight the invaluable lessons and feedback
from colleagues and collaborators that I have met in the
tech industry. A shoutout to the team at Osmosis.org,
especially the founder Shiv. He remains a friend and mentor
who taught me a lot about expressing gratitude.
Finally, my appreciation goes to all the readers who have
shown an interest in my book. Your support makes this
dream a reality and I hope it contributes to making your
TypeScript journey more enjoyable!
 Preface

The immense popularity of the Web has hoisted JavaScript

to the top of the most popular programming languages.
From small websites to large-scale enterprise applications,
the dynamic nature of JavaScript has challenged developers
due to the unpredictability of increasingly larger codebases.
Typescript has been established as the de facto solution to
this problem, a statically typed superset that introduces
type safety and powerful development tools. It is a layer of
abstraction ultimately converted into JavaScript itself.
This book will help you start developing enterprise-level
applications using TypeScript, beginning with the basics,
covering its syntax and key features such as types,
interfaces, functions, and classes. Then, we explore more
advanced topics including, how to work with modules,
manage asynchronous code with promises and async/await,
etc.
Whether you are new to TypeScript and looking to
understand its application in enterprise development, or an
experienced developer aiming to enhance your skills in
building scalable and maintainable applications, this book
offers valuable knowledge and insights. By the end of this
book, you will have a solid foundation in TypeScript and the
skills necessary to tackle the challenges of enterprise
application development head-on.
Chapter 1: Introduction to TypeScript - This chapter
serves as the starting point to learning TypeScript, a
powerful extension of JavaScript that introduces types to
your code. It begins with the basics, outlining TypeScript's
significance, and the advantages it brings to large-scale
application development.
Chapter 2: Installation and Setup – This chapter focuses
on the initial steps required to integrate TypeScript into your
development workflow, including the installation process
across Windows, MacOS, and Linux. It covers setting up
popular code editors to work seamlessly with TypeScript. We
have laid a special emphasis on debugging techniques and
the configuration of the TypeScript compiler for optimal
development. This chapter ensures that you are well-
prepared to write, debug, and compile TypeScript code
efficiently.
Chapter 3: TypeScript's Fundamentals – This chapter
discusses the core concepts of TypeScript, providing a
comprehensive overview of its syntax, type system, and the
foundational knowledge necessary for effective coding.
From basic syntax and type annotations to more intricate
features like enums and tuples, this chapter builds a solid
base for understanding how TypeScript enhances JavaScript
by adding static types.
Chapter 4: Structuring and Extending Types – This
chapter explores the power of TypeScript's type system,
focusing on creating and using interfaces, classes, and
advanced types to build well-organized and maintainable
code. This chapter discusses how TypeScript's type system
allows for defining complex data structures, implementing
inheritance and encapsulation with classes, and utilizing
utility types for more flexible code
Chapter 5: Working with Advanced TypeScript
Features – This chapter unveils the more sophisticated
aspects of TypeScript, including generics, decorators, and
advanced type manipulation techniques such as mapped
and conditional types. This chapter empowers readers to
leverage these advanced features to write highly reusable
and flexible code. Through practical examples and in-depth
explanations, readers will learn how to use generics to
create highly adaptable functions and classes, decorators to
add metadata and behavior to code, and advanced types for
precise type transformations.
Chapter 6: Migrating a JavaScript Web App to
TypeScript – This chapter provides a step-by-step guide on
transitioning an existing JavaScript application to TypeScript.
Using a Todo List app as a practical example, this chapter
walks through the process of converting JavaScript code to
TypeScript, integrating third-party libraries, and addressing
common challenges encountered during migration.
Chapter 7: Adding TypeScript to a React Application –
This chapter takes the principles of the Todo List app and
applies them to a React application, demonstrating how to
enhance a React project with TypeScript's static typing. This
chapter covers setting up a React project with TypeScript,
refactoring components to use TypeScript features, and
addressing specific type challenges inherent in React
development.
Chapter 8: Using TypeScript with a Node.js
Application – This chapter expands the application of
TypeScript to server-side development with Node. This
chapter outlines how to integrate TypeScript into a Node
project, from setting up the development environment to
converting an existing app to use TypeScript.
Chapter 9: Building TypeScript for Production – This
chapter focuses on the practical aspects of preparing a
TypeScript project for production deployment. It covers
topics such as optimizing TypeScript code for performance,
setting up continuous integration and continuous
deployment (CI/CD) pipelines, and managing dependencies.
This chapter also explores using TypeScript with modern
tooling like bundlers and task runners, ensuring readers are
equipped to deliver efficient, scalable, and maintainable
TypeScript applications.
Chapter 10: Best Practices and Next Steps – This
chapter concludes the book by summarizing best practices
for using TypeScript effectively and exploring pathways for
further learning and mastery. This chapter emphasizes
strategies for incremental adoption of TypeScript, tips for
maintaining clean and type-safe code, and resources for
continuing education in TypeScript and its ecosystem. By
the end of this book, you will leave with a roadmap for
advancing your TypeScript skills and integrating them into
future projects.
 Code Bundle and Coloured
Images
Please follow the link to download the
Code Bundle and the Coloured Images of the book:

https://rebrand.ly/9b2d9a
The code bundle for the book is also hosted on GitHub at
https://github.com/bpbpublications/TypeScript-Crash-
Course. In case there’s an update to the code, it will be
updated on the existing GitHub repository.
We have code bundles from our rich catalogue of books and
videos available at https://github.com/bpbpublications.
Check them out!

Errata
We take immense pride in our work at BPB Publications and
follow best practices to ensure the accuracy of our content
to provide with an indulging reading experience to our
subscribers. Our readers are our mirrors, and we use their
inputs to reflect and improve upon human errors, if any, that
may have occurred during the publishing processes
involved. To let us maintain the quality and help us reach
out to any readers who might be having difficulties due to
any unforeseen errors, please write to us at :
[email protected]
Your support, suggestions and feedbacks are highly
appreciated by the BPB Publications’ Family.
 Did you know that BPB offers eBook versions of every book published, with
PDF and ePub files available? You can upgrade to the eBook version at
www.bpbonline.com and as a print book customer, you are entitled to a
discount on the eBook copy. Get in touch with us at :
[email protected] for more details.
At www.bpbonline.com, you can also read a collection of free technical
articles, sign up for a range of free newsletters, and receive exclusive
discounts and offers on BPB books and eBooks.

Piracy
If you come across any illegal copies of our works in any form on the internet,
we would be grateful if you would provide us with the location address or
website name. Please contact us at [email protected] with a link to
the material.

If you are interested in becoming an author

If there is a topic that you have expertise in, and you are interested in either
writing or contributing to a book, please visit www.bpbonline.com. We have
worked with thousands of developers and tech professionals, just like you, to
help them share their insights with the global tech community. You can make
a general application, apply for a specific hot topic that we are recruiting an
author for, or submit your own idea.

Reviews
Please leave a review. Once you have read and used this book, why not leave
a review on the site that you purchased it from? Potential readers can then
see and use your unbiased opinion to make purchase decisions. We at BPB
can understand what you think about our products, and our authors can see
your feedback on their book. Thank you!
For more information about BPB, please visit www.bpbonline.com.

Join our book’s Discord space

Join the book’s Discord Workspace for Latest updates,
Offers, Tech happenings around the world, New Release and
Sessions with the Authors:
https://discord.bpbonline.com
 Table of Contents

1. Introduction to TypeScript
Introduction
Structure
Objectives
Introduction to TypeScript
Brief overview of TypeScript
The motivation behind creating TypeScript
TypeScript's relationship with JavaScript
Microsoft and TypeScript
Visual Studio Code as a TypeScript editor
The TypeScript ecosystem
Plugins
Libraries
What is a type system and why it matters?
Static and dynamic typing
Static typing
Dynamic typing
Static versus dynamic typing
Historical context and implications of JavaScript
A Brief history of TypeScript
TypeScript's key features
Type annotation
Compile-time type checking
 Type inference
Type erasure
Other features
Differences between TypeScript and JavaScript
Performance implications and trade-offs
Team collaboration benefits with TypeScript
TypeScript's additional build and compilation steps
Benefits of a type system in large-scale projects
Better readability with type annotations and
interfaces
Maintainability benefits
Early error detection through static typing
Refactoring support and safe code modifications
Encouraging best practices and design patterns
Modular architecture and namespace organization
Facilitating collaboration in large teams
Supporting complex codebases and growing projects
Autocompletion and IntelliSense in Visual Studio Code
Additional benefits of using TypeScript
Angular's adoption of TypeScript
TypeScript support in React and other UI frameworks
TypeScript support in Node.js
Conclusion
Points to remember

2. Installation and Setup

Introduction
Structure
Objectives
Installing TypeScript
 Installation on Windows
Installation on MacOS
Installation on Linux
Choosing a code editor
Configuring your code editor for TypeScript
Visual Studio Code (VSCode)
WebStorm
Sublime Text
Atom
Vim
Emacs
Debugging your TypeScript code
Debugging in VSCode
Debugging in other code editors and browsers
Working with the TypeScript compiler
Compiler configuration
Common options for tsconfig.json
Compiling TypeScript files
Common compilation options
Compiling TypeScript with popular frameworks
Integration with React
Integration with Vue
Conclusion
Points to remember

3. TypeScript's Fundamentals
Introduction
Structure
Objectives
Basic syntax and structure of TypeScript
 Type annotations and type inference
Type annotations
Type inference
When to use type annotations and type inference?
Declaring variables and their types
Variable declaration keywords
Declaring without type annotations
Declaring with type annotations
Declaring multiple variables at once
Optional type annotations
Any type
Primitive data types in TypeScript
Number
String
Boolean
Null and undefined
Operators and expressions in TypeScript
Control flow statements
If/else statements
Switch statements
For/While loops
Functions in TypeScript
Defining functions
Function parameters
Return types
First-Class Functions in TypeScript
Function type definitions in TypeScript
Arrays and tuples in TypeScript
Arrays in TypeScript
Tuples in TypeScript
 Enums in TypeScript
Conclusion
Points to remember

4. Structuring and Extending Types

Introduction
Structure
Objectives
Role of type system in structuring and extending types
Interfaces
Interface basics
Optional properties and methods in interfaces
Extending interfaces
Classes
Class basics and constructors
Inheritance in classes
Encapsulation: private, public, and protected
modifiers
Public modifier
Private modifier
Protected modifier
Type compatibility and coercion
Type coercion and type assertions
Covariance and contravariance in TypeScript
Readonly and Partial types
Readonly types
Partial types
Defining and using custom types
Type aliases
Union and intersection types
Union types
Intersection types
Type guards and type predicates
Type system limitations, trade-offs, and performance
considerations
Understanding type system limitations
Type system trade-offs
Performance considerations
Conclusion
Points to remember

5. Working with Advanced TypeScript Features

Introduction
Structure
Objectives
Advanced type system concepts
Type guards
Union types
Discriminated unions
Union type narrowing
Type aliases
Working with generics in TypeScript
Generics basics
Generics with interfaces and classes
Generics with interfaces
Generics with classes
Generics with constraints
Using decorators to simplify your code
Understanding decorators
Practical use cases of decorators
Logging with decorators
Data validation with decorators
Timing decorator
Advanced type manipulation with mapped and
conditional types
Mapped types
Conditional types
Advanced type inference techniques
Contextual typing
Control flow based type analysis
Using TypeScript with functional programming concepts
Higher-order functions in TypeScript
Immutability and pure functions
Functional programming libraries for TypeScript
Conclusion
Points to remember

6. Migrating a JavaScript Web App to TypeScript

Introduction
Structure
Objectives
Building a Todo List and migrating to TypeScript
Overview of a Todo List application
State management and data handling
Exploring the existing JavaScript code
Structure of the files
HTML
CSS
Script.js
Identifying HTML elements
Initializing the tasks array
Task editing functions
Creating the task HTML element
Task management
Local storage management
Event listeners
Rendering the application on the browser
Converting JavaScript code to TypeScript
Setting up TypeScript for the project
Watching for changes on TypeScript
Strict mode option
Adding types to variables and functions
Identifying HTML elements
Initializing the tasks array
Task editing functions
Creating the task HTML element
Task management
Local storage management
Event listeners
Creating interfaces for complex data structures
Defining the task interface
Updating the tasks array with the task interface
Using the task interface in function parameters
Working with third-party libraries
JavaScript versus TypeScript: importing libraries
Adding UUID to our TypeScript project
Handling missing type definitions and errors
Handling errors in TypeScript
Type incompatibilities
Overriding type incompatibilities with type assertion
 Error handling on the TypeScript compiler
Error handling with VS Code
Code analysis and error detection
Quick fixes
Advanced error reporting at the Problems panel
Testing with TypeScript
Preparing the test environment
Installing and configuring Jest with TypeScript support
Refactoring the code for testing
Writing the tests
Conclusion
Points to remember

7. Adding TypeScript to a React Application

Introduction
Structure
Objectives
Setting up React with TypeScript support
Starting a new React project with TypeScript
Using vite
Using create React app
Adding TypeScript to an existing React project
Refactoring the Todo List app with React
Structure of the React components
Migrating the Todo List application to React
Creating a style.css
Adding TypeScript to React components
Refactoring the code with TypeScript
TypeScript features specific for React
Handling props and state of components
 Navigating type inference
Event types in React with TypeScript
Dealing with React refs and TypeScript
Higher order components and TypeScript
Generic components
Using children prop
Union and intersection types with props
Adding TypeScript to the context
Type incompatibilities in React
Incorrectly inferring useState value
Mistyping useEffect dependencies
Misunderstanding any and unknown
Incorrect assertion with the as keyword
Non-nullable type assertion with optional chaining
Using TypeScript with React libraries and plugins
Redux with TypeScript
Using TypeScript with React Router
Using TypeScript with Formik
Writing tests for React with TypeScript
Conclusion
Points to remember

8. Using TypeScript with a Node.js Application

Introduction
Structure
Objectives
Creating a Todo List application in Node.js
Overview of a Todo List application
Data management and request handling
Defining the code
 Structure of the files
Exploring server.js
Importing the modules
Initializing the server and middleware
Data initialization
API routes
Starting the server
Exploring utils.js
Importing readFile and writeFile from fs/promises
loadData function
saveData function
Exporting the functions
Trying the Todo List API
Start the server
Testing API routes with cURL
Creating a new task (POST /tasks)
Getting all tasks (GET /tasks)
Getting a specific task (GET /tasks/:id)
Updating a task (PUT /tasks/:id)
Deleting a task (DELETE /tasks/:id)
Migrating to TypeScript
Setting up TypeScript for the project
Importing modules
Declaring the tasks array
Loading initial data
API routes
Initializing the server
Using Node.js Libraries with TypeScript
Adding @types for the libraries
Integrating TypeORM and SQLite with TypeScript
SQLite Installation
Setting up TypeORM
Defining a task entity
Updating utils.js
Refactoring server.ts
Testing Node.js with Jest and TypeScript
Setting up the test environment
Writing unit tests
Setting up the tests
Testing saveData
Testing loadData
Testing deleteData
Running the tests
Conclusion
Points to remember

9. Building TypeScript for Production

Introduction
Structure
Objectives
Introduction to TypeScript on production
Optimizing TypeScript performance
Best practices in writing efficient TypeScript code
Leveraging TypeScript compiler options
Using TypeScript with JavaScript bundlers
Configuring Webpack for TypeScript
Configuring Rollup for TypeScript
Configuring vite for TypeScript
Deploying TypeScript to hosting platforms
Deploying to cloud platforms
 Deploying to a VPS
Deploying to PaaS
TypeScript with serverless architectures
TypeScript with AWS Lambda
TypeScript with Azure Functions
TypeScript with Google Cloud Functions
Working with CI/CD Pipelines and TypeScript
Enforcing code linters
Automated testing and TypeScript
Logging with TypeScript
Source maps
Logging with tslog
Structured logging
TypeScript with Winston
TypeScript with Bunyan
TypeScript with Pino
Using TypeScript with databases
TypeORM
Prisma
Sequelize
Using TypeScript with GraphQL
TypeScript with GraphQL schema
Generating TypeScript types from GraphQL schemas
Generating GraphQL schemas from TypeScript types
Documenting TypeScript code
Generating documentation with Typedoc
Enhancing documentation with JSDoc
Conclusion
Points to remember
10. Best Practices and Next Steps
Introduction
Structure
Objectives
Best practices
Incremental adoption strategy
Start small
Gradually tighten the type checking
Avoid using type any
Code Linters and Typescript
Setting Up ESLint with TypeScript
Using the readonly modifier
Using type guards and assertions
Type guards
Type assertions
Utility types and their usage
Next steps and learning resources
Learning resources
Beyond the basics
Ideas for TypeScript projects
Closing thoughts
Conclusion
Points to remember

Index
 CHAPTER 1
Introduction to TypeScript

Introduction
This chapter introduces you to TypeScript, a popular
programming language that extends JavaScript by adding
types. You will learn about the importance of a type system,
TypeScript's history, its key features and how it compares to
JavaScript.
In the upcoming chapters of this crash course book, we will
explore the various features of TypeScript and learn how to
leverage them effectively to build robust and scalable
applications. Starting from the basics and finishing with
practical examples on how to integrate TypeScript with
existing JavaScript and NodeJS projects.
You will learn about the TypeScript compiler (tsc), a
command line tool used to check for type errors and convert
TypeScript to equivalent JavaScript, which is the actual code
that will be executed on the runtime of the browser or
NodeJS.
Also, we are going to leverage Visual Studio Code, a popular
development environment for TypeScript, that offers features
like autocompletion and type checking that significantly
speeds up the development process. By providing better
tooling and editor support, TypeScript makes it easier for
developers to navigate and refactor their code.

Structure
The chapter covers the following topics:
Introduction to TypeScript
What is a type system and why does it matter?
TypeScript's key features
Differences between TypeScript and JavaScript
Benefits of a type system in large-scale projects

Objectives
By the end of this chapter, you will understand what
TypeScript is, what type systems are, the differences
between TypeScript and JavaScript, and finally the
advantages TypeScript offers for building scalable web
applications.

Introduction to TypeScript
TypeScript is a programming language that extends
JavaScript by adding static types on top of it. Created by
Microsoft developer Anders Hejlsberg, TypeScript was
released in 2012 as an open-source project.

Brief overview of TypeScript

TypeScript provides the ability to write scalable and
maintainable applications while leveraging the features and
versatility of JavaScript. As a superset of JavaScript,
TypeScript is compatible with any valid JavaScript code,
allowing developers to gradually adopt it in their existing
projects without the need for a complete rewrite. It enables
developers to specify the type of variables, function
parameters, and return types. This allows for catching errors
at compile-time rather than runtime, resulting in improved
code quality, maintainability, readability, and fewer bugs in
production. Additionally, it can result in fewer lines of code,
as values do not need to be explicitly checked for type.
TypeScript also introduces a range of advanced features such
as interfaces and generics. These features enhance the
development experience by providing a way to define
contracts, organize code into reusable components, and
enforce type safety across the application. Through this last
decade, TypeScript has gained significant popularity in the
web development community due to its ability to address
many challenges faced by JavaScript developers. It is
becoming the preferred choice for large-scale applications
and has been widely adopted by notable companies like
Microsoft, Google, Airbnb, and Slack. With a growing
community and support from major industry players,
TypeScript's future is bright for years to come!
Community-driven projects like DefinitelyTyped provide
TypeScript definitions for popular JavaScript libraries, making
it easier for developers to leverage existing code while
enjoying the benefits of TypeScript's type system on the web
browser, NodeJS or any JavaScript runtime.

The motivation behind creating TypeScript

TypeScript was created to address the limitations and
challenges faced by JavaScript developers when working on
large-scale applications. As web applications grows both in
size and complexity, the flexibility of JavaScript's dynamic
typing becomes a double-edged sword, leading to runtime
errors, maintainability issues, and difficulty scaling
codebases.
One of the primary motivations behind creating TypeScript
was to introduce static typing to JavaScript, enabling
developers to catch errors at compile time instead of
runtime. This would result in more robust, maintainable, and
scalable applications. Since TypeScript is a superset of
JavaScript, it allows developers to gradually adopt its
features without having to rewrite their entire codebase.
Another motivation was to improve tooling and editor
support. With static typing, editors can provide better code
navigation, autocompletion, and refactoring capabilities,
ultimately improving developer productivity. The type
information also enables better documentation and code
understanding, making it easier for teams to collaborate and
maintain their projects.
TypeScript also enables better code organization and
scalability through the introduction of features like classes,
modules, and interfaces. These language constructs allow
developers to structure their code in a more modular and
maintainable manner, facilitating code reuse and separation
of concerns.

TypeScript's relationship with JavaScript

TypeScript is a superset of JavaScript, which means that any
valid JavaScript code is also valid TypeScript code. TypeScript
extends JavaScript by adding optional static typing and a
host of other features that make it easier to develop,
maintain, and scale large web applications.
Developers can start by writing JavaScript code and then
gradually introduce type annotations to enhance the code
with static typing. This allows projects to transition to
TypeScript at their own pace, without the need for a
complete rewrite to start using it.
One of the key benefits of TypeScript's relationship with
JavaScript is its ability to leverage its vast ecosystem.
TypeScript can use existing JavaScript libraries, frameworks,
and tools seamlessly, enabling developers to utilize popular
JavaScript libraries like React or Express in their TypeScript
projects without any issues.
The TypeScript compiler converts TypeScript into JavaScript
code that can be executed in any JavaScript runtime
environment. This compilation process ensures that
TypeScript code is transformed into its equivalent JavaScript
representation, maintaining compatibility with existing
JavaScript tools and platforms.
TypeScript's close relationship with JavaScript also ensures
that it stays up to date with the latest ECMAScript standards.
As new features are introduced to JavaScript, they are often
incorporated into TypeScript, allowing developers to use
cutting-edge language features while still benefiting from
TypeScript's type system and tooling support.
In summary, TypeScript and JavaScript share a symbiotic
relationship of enhancement and extension. TypeScript
builds upon the foundation laid by JavaScript, adding static
typing and other features that make it easier to develop and
maintain large applications. This allows developers to
seamlessly transition between the two languages and
ensures that TypeScript stays updated with the evolving
JavaScript ecosystem.

Microsoft and TypeScript

Microsoft's involvement in TypeScript development has been
pivotal in shaping the language's trajectory and overall
success. Development was started in 2010 by Anders
Hejlsberg, who is also known for his work on other
programming languages like C#, TurboPascal and Delphi.
It was released as an open-source project by Microsoft in
2012 and the company has continued to play an active role
in its development, maintenance, and promotion.
The backing from a tech giant like Microsoft has provided
TypeScript with the necessary resources for its growth and
evolution, along with the open-source community support
has enabledit to become a powerful and feature-rich
language that addresses many challenges faced by
JavaScript developers. The company has been actively
involved in maintaining and advancing TypeScript through its
dedicated development team. They regularly release
updates, add new features, improve performance, and
address community feedback. Microsoft also provides
extensive documentation, tutorials, and resources for
developers to learn and use TypeScript effectively.
Microsoft's commitment to TypeScript is evident in its
integration with popular Microsoft tools like Visual Studio
Code, a widely used open-source code editor. It has built-in
support for TypeScript, offering features like syntax
highlighting, code completion, and error checking. This
integration has significantly eased the process of working
with TypeScript, further boosting its adoption by developers.
Moreover, Microsoft has fostered a thriving community
around TypeScript by being responsive to the needs of
developers, actively engaging in discussions through forums
and GitHub repositories, and collaborating with other
companies and organizations in the tech industry to improve
TypeScript's interoperability with various tools, frameworks,
and libraries.

Visual Studio Code as a TypeScript editor

Developed by Microsoft in 2015, VS Code quickly became
one of the most popular editors among TypeScript
developers. It provides a seamless coding experience and
offers a wide range of features and extensions for TypeScript
development; besides providing native support with
intelligent code completion, syntax highlighting, and error
detection.
One of the standout features of VS Code is its rich debugging
capabilities. It allows developers to set breakpoints, inspect
variables, and step through their TypeScript code during
runtime, helping to identify and fix bugs effectively.
Additionally, the Visual Studio Code Marketplace offers a
wide range of TypeScript-related extensions that provide
additional functionalities and tools to enhance development,
like managing imports, code snippets and an ever-growing
number of specialized features.
The strong integration between TypeScript and VS Code
extends beyond the editor itself. VS Code integrates with the
TypeScript compiler, enabling developers to compile and
build TypeScript projects directly from the editor. It provides
build tasks and configuration options to customize the
compilation process, making it convenient for developers to
manage their TypeScript projects seamlessly.
VSCode's IntelliSense feature plays a crucial role in
enhancing TypeScript development. It offers intelligent code
suggestions based on the project's context, allowing
developers to write code more quickly and accurately. By
understanding TypeScript's static types, IntelliSense can
provide precise and relevant suggestions, reducing the
likelihood of errors and improving overall code quality.
Besides VS Code, there are TypeScript plugins for pretty
much any popular text editors and IDEs like Vim, Emacs,
Notepad++, Webstorm, and so on. For convenience we
will be using VS Code for the rest of the examples in this
book, but feel free to explore the TypeScript toolset of your
favorite editor, whatever it may be. Please refer to the
following figure:
 Figure 1.1: Welcome screen for Visual Studio Code

The TypeScript ecosystem

The TypeScript ecosystem is extensive and versatile, offering
a wide variety of libraries, plugins, and frameworks that help
developers create powerful, scalable, and maintainable
applications. These resources enhance the development
experience, streamline workflows, and facilitate the adoption
of best practices in the development process.
Angular, developed and maintained by Google, is a powerful
web application framework built with TypeScript baked into
it. React and Vue, both widely used JavaScript libraries for
building user interfaces, also have excellent TypeScript
support, enabling developers to build robust and
maintainable UI applications.

Plugins
Plugins expand the functionality of the language and its
associated development environments, such as Visual Studio
Code. Notable examples include TSLint for enforcing coding
style and best practices, Prettier for automatically
maintaining a consistent coding style across a project, and
various plugins for intelligent code completion, error
detection, and navigation features tailored for TypeScript
development.

Libraries
Libraries play a crucial role in the TypeScript ecosystem as
pre-written code packages that developers can incorporate
into their projects to manage specific tasks or functionalities.
Several libraries natively support TypeScript, meaning they
are written in TypeScript and provide type definitions out of
the box. This simplifies the development process as
developers can directly import and utilize these libraries
without the need for external type definitions.
One of the most significant advantages TypeScript offers is
the ability to work with JavaScript libraries through type
definition files. The DefinitelyTyped project is a community-
driven repository that hosts TypeScript type definitions for
thousands of popular JavaScript libraries. By using the @types
organization, developers can quickly obtain type definitions
for a specific library, ensuring accurate type checking and
code completion in their TypeScript projects.
To install a type definition for a specific library, you can use
the following command:
npm install --save-dev @types/library-name

Once installed, TypeScript will automatically recognize the

types provided by the type definition file, enabling seamless
integration with the library in question. This allows
developers to take advantage of TypeScript's features, such
as type checking, autocompletion, and code navigation, even
when working with third-party JavaScript libraries. By
utilizing these type definitions, developers can harness the
full power of TypeScript's type system while leveraging the
vast ecosystem of JavaScript libraries.
TypeScript also has a strong presence in the testing
landscape, with testing frameworks like Jest and Jasmine
offering extensive TypeScript support. Build tools like
webpack and Rollup also have excellent TypeScript
integration, enabling developers to bundle and optimize
TypeScript code for production.

What is a type system and why it matters?

A type system plays an integral role in programming
languages, enforcing rules and protocols to help developers
write clean, reliable code. It classifies data into categories
such as numbers, strings, Booleans, or even user-defined
types, defining the permissible operations on them. Among
various type systems, static and dynamic typing are two
prevalent paradigms.

Static and dynamic typing

In programming languages, the concept of typing refers to
how variables and expressions are associated with certain
types of data. A type system categorizes values into different
types, such as numbers, strings, Booleans, and so on, or
custom types. It defines rules for how these types interact
and what operations can be performed on them. Static
typing and dynamic typing are two contrasting approaches
to type systems, each with its own characteristics and
advantages.

Static typing
In a statically typed language, the data type of a variable is
determined at compile-time, meaning that the type
information is checked and enforced before the program is
run. Languages like Java, C++ and TypeScript are statically
typed. Static typing offers several benefits, including early
detection of type errors, improved code readability, better
tool support like code completion and refactoring, and more
robust and reliable code, reducing the chances of
unexpected runtime errors.

Dynamic typing
Dynamic typing, on the other hand, means that a variable's
data type is determined at runtime. Languages like
JavaScript, Python, and Ruby are dynamically typed. This
approach allows for greater flexibility, as variables can
change their types during the execution of a program.
Dynamic typing allows for easier to write and more concise
code, faster development, and rapid prototyping. However,
this flexibility can also introduce challenges in terms of
debugging and maintaining code, as type-related errors
might not be apparent until the code is executed.

Static versus dynamic typing

Each typing approach has its pros and cons. Statically typed
languages generally lead to more reliable and maintainable
code, particularly beneficial in large-scale projects or when
collaborating with other developers. Dynamic typing allows
for more flexibility and may be better suited for smaller
projects or rapid prototyping, but the lack of type information
can make it more challenging to understand and maintain
code, especially in larger projects.
Aspect Static typing Dynamic typing

Type checking Performed at compile Performed at run time

time
Type Required or inferred Not required
declaration
Type errors Detected early by the Detected late by the
compiler interpreter
Advantages More reliable, readable, More flexible, expressive, and
and performant productive
Disadvantages More verbose, rigid, and More prone to bugs,
 complex ambiguity, and inefficiency
Examples Java, C, C++, Go, Scala Python, JavaScript, PHP, Ruby
Table 1.1: Comparison of static and dynamic typed
languages
In essence, the choice between static and dynamic typing
depends on the project size and requirements. TypeScript, as
a statically typed superset of JavaScript, offers the best of
both worlds by providing a robust type system on top of the
existing dynamic nature of JavaScript. This enables
developers to leverage the benefits of static typing while
retaining the flexibility and expressiveness of JavaScript.

Historical context and implications of JavaScript

During the constraints of mere ten days in September of
1995, JavaScript was created by Brendan Eich at Netscape to
enable users to create more interactive and dynamic web
pages. It was designed to be easy to learn and use, with a
focus on providing a lightweight and flexible language that
could be quickly integrated into HTML pages. Consequently,
JavaScript adopted dynamic typing as one of its core
features to cater to these needs.
In the context of JavaScript's historical development,
dynamic typing made sense. Web development in the mid-
1990s was relatively simple, and developers needed a
language that allowed for rapid development cycles and
quick iterations. Dynamic typing provided this flexibility,
enabling developers to write code without being burdened
by explicit type annotations or compile-time type checking.
This was crucial at the time since each browser had different
implementations of JavaScript, as it enabled developers to
adapt their code using different runtime checks.
However, as the web evolved and web applications grew in
complexity, the limitations of JavaScript's dynamic typing
became more apparent. The lack of type information made it
difficult to maintain and understand larger codebases, as
developers had to rely on comments, documentation, or
runtime testing to deduce the expected types of variables
and function arguments.
Additionally, the absence of compile-time type checking
means that type-related errors can easily slip into
production, leading to runtime failures and making it hard to
debug these hidden issues. The implications of JavaScript's
dynamic typing also affects tooling and code analysis.
Without the ability to infer types at compile-time, tools like
code editors and linters face limitations in providing accurate
code completion, refactoring support, and error detection.
To address these challenges and improve code quality,
TypeScript emerged as a statically typed superset of
JavaScript. By introducing static typing to JavaScript,
TypeScript provides developers with the ability to catch type
errors during the development phase before the code is
executed. TypeScript's static typing enhances code reliability
and maintainability by allowing developers to explicitly
declare types and enforce stricter type checks, while also
retaining JavaScript's flexibility by offering optional typing.
It is worth noting that TypeScript is not the first project that
attempted to do this. For example, Haxe introduced similar
capabilities as far back as 2006, though it did not gain the
same traction and widespread adoption as TypeScript has.

A Brief history of TypeScript

TypeScript's journey began with the recognition that the
dynamic nature of JavaScript, while having its advantages,
could hinder development efficiency and code
maintainability in large-scale projects. In October 2012,
Microsoft introduced TypeScript to the world, a statically
typed superset of JavaScript designed to address these
challenges.
It was started by Anders Hejlsberg, a renowned software
engineer with an impressive track record that includes
helping the creation of Turbo Pascal, Delphi, and C#.
Alongside his team at Microsoft, Hejlsberg aimed to create a
language that would be easily adopted by the vast JavaScript
developer community while enhancing the language with
static typing capabilities.
TypeScript's development took a pragmatic approach,
ensuring that any valid JavaScript code was also valid
TypeScript code. This decision allowed developers to
incrementally adopt TypeScript features into their existing
JavaScript projects, making the transition smoother and less
daunting. TypeScript also embraced the rapidly evolving
ECMAScript standard, adopting new features and syntax
additions as they emerged.
Over the years, TypeScript has seen significant growth in
popularity and adoption. With each release, the language
has become more refined and feature-rich, backed by a
strong community and industry support. According to
Github's blog, Octoverse, TypeScript has become the fourth
most used language since 2020 and on.
Source: https://octoverse.github.com/2022/top-
programming-languages
Please refer to the following figure:
 Figure 1.2: TypeScript has quickly become the fourth most popular language
on Github

Today, TypeScript is widely recognized as a powerful tool for

developing large-scale, complex web applications, helping
developers write safer, more maintainable, and efficient
code.

TypeScript's key features

In this section, we will discuss some important TypeScript
key features.

Type annotation
One of the foundational features of TypeScript is its type
annotation system.
Type annotations enable developers to explicitly
specify the types of variables, function parameters, and
return values. By declaring these types, developers
provide a blueprint for how the code should behave,
which can significantly improve the readability and
maintainability of the code.
 TypeScript uses these annotations to perform compile-
time type checking, ensuring that the code adheres to
the specified types. When the TypeScript compiler
encounters a type mismatch, it raises a compilation
error, alerting the developer to potential issues before
the code is executed. This process helps catch common
programming errors early, reducing the likelihood of
runtime errors and making it easier to identify and fix
issues during development.

Compile-time type checking

The compile-time type checking process offers several
advantages for developers.
The compile-time type checking is made possible by
TypeScript's transpiler, which converts TypeScript
code into equivalent JavaScript code. During this
conversion, the type information is stripped away,
resulting in type-erased JavaScript code that can be
executed in any JavaScript runtime environment. The
transpiler is also responsible for transforming
TypeScript-specific language features into equivalent
JavaScript constructs, ensuring compatibility across
different JavaScript engines.
TypeScript's type annotation and compile-time type checking
system helps enforce code contracts, making it easier to
reason about the behavior of the code and the relationships
between different parts of the application. Additionally, they
provide a form of documentation that remains in sync with
the code as it evolves. This self-documenting nature of
TypeScript code can be particularly valuable in large-scale
projects, where team collaboration and knowledge sharing
are crucial to the success of the project.

Type inference
Type inference is an important feature of TypeScript that
complements type annotations, providing a powerful and
flexible type-checking system.
While type annotations allow developers to explicitly
specify types, type inference enables the TypeScript
compiler to automatically deduce types based on the
context in which variables and functions are used.
TypeScript's type inference mechanism is intelligent
and can infer types in various situations. For example,
when a variable is initialized with a value, the compiler
can infer the type of the variable from the value's type.
Similarly, when a function is defined with parameters
and a return value, the compiler can infer the types of
the parameters and the return value based on the
function's implementation.
Inference also plays a key role when working with
generic types. For instance, when a developer uses a
generic function or class without explicitly specifying
the type arguments, TypeScript can often infer the
correct types based on the context in which the generic
function or class is used. This makes the code more
concise and readable without sacrificing type safety.
Type inference offers several benefits to developers:
First, it reduces the amount of type annotation
required, making the code less verbose and more
readable. This can be particularly helpful in
situations where the types are obvious from the
context and adding explicit annotations would be
redundant.
Second, type inference can help catch errors that
might otherwise go unnoticed. For example, if the
TypeScript compiler infers an unexpected type, it
may indicate a logic error in the code.
 However, it is important to note that type inference has
its limitations. In some cases, the TypeScript compiler
may not be able to deduce the correct types, and
explicit type annotations will be necessary.
Additionally, relying too heavily on type inference can
lead to less self-documenting code, making it harder
for developers to understand and maintain these codes.

Type erasure
TypeScript employs a process called type erasure during
the compilation phase, which refers to the removal of type
information from TypeScript code as it is transformed into
JavaScript.
Type erasure ensures that the type annotations present
in TypeScript code have no runtime impact and allows
the compiled JavaScript code to be executed in any
JavaScript runtime environment.
The primary purpose of type erasure is to maintain
compatibility with JavaScript, a dynamically typed
language without a built-in type system. By erasing
type information during compilation, TypeScript
generates JavaScript code that adheres to this typeless
nature, ensuring seamless integration with existing
JavaScript libraries, frameworks, and tools.
Although type erasure removes type information at
runtime, type checking and static type analysis still
occur during the compilation process. The TypeScript
compiler analyzes the code, performs type checking,
and verifies type correctness at compile time, reporting
any type errors or mismatches as compilation errors.
Type erasure has several implications for developers:
First, it means that TypeScript's type checks are
performed exclusively at compile time, with no
 runtime type checking. This emphasizes the
importance of writing accurate type annotations and
leveraging TypeScript's type-checking features to
catch errors during the development process.
Second, due to type erasure, developers cannot rely
on TypeScript's type information for runtime
behavior. For example, type guards must be based
on values or properties that exist at runtime, not
solely on TypeScript types.
Lastly, type erasure reinforces the fact that TypeScript
is a strict superset of JavaScript, meaning that any
valid JavaScript code is also a valid TypeScript code.
This compatibility allows TypeScript developers to use
the vast JavaScript ecosystem while still benefiting
from static type checking and type analysis during
development.
In summary, type erasure is a crucial aspect of TypeScript's
design that enables the language to maintain compatibility
with JavaScript while still providing a robust and
comprehensive type system at compile time. Understanding
type erasure and its implications can help developers write
more effective and efficient TypeScript code.

Other features
TypeScript enhances JavaScript development by
incorporating key features from ECMAScript 2015 (ES6) and
subsequent versions, as well as introducing TypeScript-
specific features. These include interfaces, enumerated
types (enums), generics, namespaces, tuples, async/await,
classes, modules, and arrow functions.
These are just some of the features in TypeScript. They will
be discussed in depth in Chapter 3, TypeScript's
Fundamentals, Chapter 4, Understanding TypeScript's Type
System and Chapter 5, Working with Advanced TypeScript
Features, exploring their syntax, usage, and benefits in
TypeScript development:
Namespaces: Helps organize and encapsulate code,
providing better modularity and preventing naming
collisions.
Tuples: Represent fixed-length arrays with elements of
different types, adding type safety and clarity to
compound values.
Arrow functions: Introduced in ECMAScript 2015,
arrow functions offer a more concise syntax for
anonymous functions, automatically bind the value of
this, and support lexical scoping, making them a
popular choice for writing modern JavaScript code.
Async/await: TypeScript fully supports async/await
from ECMAScript 2017, simplifying asynchronous
programming and making it easier to work with
promises and write clean, readable asynchronous code.
Classes: TypeScript enhances ECMAScript 2015
classes with features like access modifiers, abstract
classes, and decorators, bringing traditional object-
oriented programming concepts to JavaScript and
making it more powerful for building complex
applications.
Interfaces: TypeScript interfaces define custom types
based on the shape of an object, creating contracts that
objects must adhere to. This promotes code
consistency, interoperability, and improved type
checking.
Enumerated types: Enums represent a set of named
constants, improving code readability, expressiveness,
and reducing the likelihood of errors.
 Generics: Enables the creation of reusable, type-safe
code components that work with multiple types,
enhancing code flexibility, maintainability, and
performance.
Modules: TypeScript supports the ES6 module syntax,
providing a way to encapsulate code and manage
dependencies between different parts of an application,
promoting modularity and code sharing.
These features make TypeScript a powerful and versatile
language for building complex web applications. By
combining the best of JavaScript with additional
enhancements, TypeScript offers developers a rich set of
tools for creating scalable, maintainable, and type-safe code.

Differences between TypeScript and JavaScript

A primary difference between TypeScript and JavaScript is
the introduction of type annotations in TypeScript. Type
annotations are a way for developers to explicitly specify the
expected data types of variables, function parameters, and
return values. By adding type annotations, developers can
leverage TypeScript's powerful type checking capabilities,
catching potential errors during compile time rather than
runtime.
In TypeScript, type annotations are added using a colon (:)
followed by the type, such as:
let age: number = 25

In contrast, in JavaScript, variables can be declared without

explicitly specifying their types, such as:
let age = 25.

JavaScript relies on type inference to determine the type of

variables based on their assigned values.
Exploring the Variety of Random
Documents with Different Content
 Here again training is all that is necessary to equip
for very important work.[156]
Some of the strongest tributes to women’s industrial efficiency
came from the Ministry of Munitions. Lloyd George stated that, “the
country has been saved, and victory assured by the work of women
in the munition factories.” From time to time the Dilution Bulletins
contained examples of an actual increase in output when women
replaced men. For example, at an east coast aeroplane factory,
twelve women were said to be making twice the number of pulleys
formerly made by sixteen men. The output of a horseshoe
manufactory increased 7½ per cent after ninety women replaced the
same number of men. In one factory turning out 9.2 inch shells, the
men handled from eight to eleven during a ten hour shift, while the
women handled twenty-four. Frequently when women failed in their
work the cause was found to be outside their control. In one case
spoilt work was due to the setting of tools wrong by men who were
opposed to “dilution.” Lack of proper lifting devices was not an
uncommon handicap.
The question is of course greatly complicated, especially in
industry, by the fact that women are probably not in the majority of
cases doing precisely the same work as the men who preceded
them. At least four different forms of substitution can be
distinguished, in all but one of which the woman’s work is not
identical with the man’s. These have been called (1) complete or
direct substitution, (2) group substitution, (3) indirect substitution,
and (4) substitution by rearrangement.
“Complete” or “direct” replacement occurs only when a woman
takes up the whole of the same work that a man has been doing.
The frequency of this form of replacement was perhaps
overestimated during the early months of the war, because it
necessarily occurred when women took men’s places in such
nonindustrial positions as postmen, drivers and tramcar conductors,
with whom the public comes in daily contact. Until perhaps the third
year of the war, however, such complete replacement was for the
most part found in the lighter forms of comparatively unskilled work,
for instance, sweeping in bakeries, filling sacks in chemical plants,
and some light, unskilled work in munitions and other metal trades.
Even in clerical work women were substituted for men largely in the
more routine, less skilled branches. But from about 1917 an
increasing number of women proved able to do the whole of a skilled
man’s work in industry, even, in some cases, to “setting up” and
repairing their machines. Women were found who seemed to be
“natural mechanics”—a quality formerly thought to be entirely lacking
in the female sex. The direct substitution of women in scientific,
managerial, and supervisory work during the same period has
already been noted.
“Group” substitution is said to take place when a group of women
do the work of a smaller number of men. It is the method of
substitution often used in provision stores and other forms of retail
trade. In some cases it has proved to be only a temporary
arrangement, followed in a few months by “complete” or “direct”
substitution, as the women gained in experience and efficiency and
became able to do as much work as the men. The so-called
“indirect” form of replacement was common in the metal trades,
especially when additional women were first being added to the
force. An unskilled man or a boy was promoted to skilled work,
whose place, in turn, was taken by a woman. This form of
substitution was of course particularly easy to overlook.
The equal pay situation becomes most complicated under the
form of substitution most frequent in the skilled trades, namely,
substitution by rearrangement. In this case the trade processes
themselves are changed on the introduction of women workers.
Excellent illustrations of this form of substitution may be drawn from
the munition branch of the engineering trade, which was
revolutionized by such methods since the beginning of the war. The
purpose of the reorganization is to simplify skilled processes so as to
bring them within the capacity of less expert workers, all the changes
tending toward greater specialization and greater repetition.
A skilled man’s work was sometimes analyzed into its various
parts and a woman put on each separate part. Or simpler parts of a
piece of highly skilled work were set off for women to do, while a
man spent his time exclusively on skilled operations. Thus in many
munition factories, where formerly each machine was “set up,”
operated and repaired by a skilled man, each was operated by a
woman, while half a dozen were supervised and repaired by a single
skilled man. Another very common method of “substitution by
rearrangement” consisted of the introduction of automatic or semi-
automatic machinery, in place of hand work or machines requiring
considerable attention and initiative on the part of the operator. Thus
a machine for cloth cutting is advertised, which, according to the
testimonial of an employer, “does the work of four hand cutters and
is operated by a girl with the greatest ease. Until its introduction it
was impossible to employ women at the actual work of cutting, but
where this machine is in use it is now done. It has helped us to carry
on six government contracts and has reduced cutting costs by more
than 50 per cent.”[157]
From one point of view it would not seem essential that women
should receive men’s rates if “substitution by rearrangement” has
taken place. From another viewpoint, however, if the lower rates
decrease the total labor cost of the job, as is almost always the case,
the danger remains that lower rates for women will pull down the
men’s wage standards. More obvious is the menace to the men’s
rates if women are not generally inferior as workers, and if they are
employed at a lower wage scale under the other forms of
substitution.
The evidence obtainable on the relative wages received by men
workers and by the women who replaced them shows that just that
danger exists. While most of the women substitutes have gained an
improved financial position, they have not, on the whole, reached a
plane of economic equality with the men whom they have replaced.
In January, 1916, the Labour Gazette, looking back over 1915, said
that, “the extensive substitution of women and young persons for
men has tended to lower wages per head for those employed.”[158]
The nearest approaches to the men’s level seem to have been
attained in occupations covered by trade union agreements which
require the payment of the men’s wage scale to the women. But
even in some of these occupations, as in transport, the women did
not receive all the bonuses of the men. In the munitions industry, the
government seemed at first to go on record in favor of the equal pay
principle, but, in practice, unskilled and semi-skilled time work were
excluded, and the women failed to receive the same cost of living
bonuses as the men, though unquestionably the wages of women
substitutes in munitions work were much higher than the former level
of women’s wages.
In wage disputes involving the question of “equal pay,” the
tendency of conciliation boards such as the Special Arbitration
Tribunal was to grant some wage increases, but to avoid any
declaration on the principle. In the summer of 1918 such action
caused a strike of women bus conductors which attracted much
public attention. In July both men and women asked for a revision of
a previous award on an equal pay basis. The Committee on
Production, which handled the case, gave the men a bonus, but
refused it to the women on the ground of the precedents set by the
Ministry of Munitions in granting similar bonuses only to males. The
women struck in protest on August 17, and were supported by most
of the men, who feared a future double standard of wages. The
committee then reconsidered its decision and on August 30 granted
the women the same bonus as the men. The decision recognized
the equal pay principle and also that the receipt of separation
allowances by soldiers’ wives should not be considered, in fixing
wages.
In trades covered neither by union agreement nor legal
regulation, women generally received what is high pay according to
their previous wage scale, but investigators believe that the men’s
level was not even approximately reached.
 CHAPTER XI
Hours of Work

Since the working hours of women in English industry have long

been regulated by law, the discussion of the effects of the war on
working time centers in the modifications in the legislation made
because of war conditions. The main facts are comparatively well
known in America. The early war time extension of hours, the
discovery that the previous limitations had operated in the interests
of industrial efficiency as well as humanitarian considerations and
the final restoration of almost the prewar limit of working hours, with
a better appreciation of their real utility and value, are fairly familiar.
Certain modifications in the daily hour standards were allowed
throughout the war, however, and night work by women continued
common.
At the outbreak of the war legal hours were ten daily and fifty-five
weekly in textile factories, and ten and a half daily and sixty weekly,
with a limited amount of overtime, in nontextile factories and
workshops. But the Secretary of State had the power to modify these
restrictions “in case of any public emergency.” The factory acts
allowed him at such periods to exempt work on government
contracts and in government factories from hour limitations “to the
extent and during the period named by him.”[159]

The Demand for Overtime

A demand for the exercise of this power to extend women’s hours
and to allow them to do night and Sunday work was made by
manufacturers of army supplies in the early days of the war. While
the greatest rush of government orders came to firms making
munitions, clothing and camp equipment, the number of trades
affected was “unexpectedly great, extending from big guns to boot
nails, from blankets to tapes, from motor wagons to cigarettes.”[160]
The factory inspectors felt that they were facing a difficult
problem. Obviously it was necessary to secure the greatest possible
output, but it was equally apparent that labor would soon break down
if unrestricted overtime were permitted. Moreover, “was it right that
one set of operatives should be working excessive hours, while
others were without work at all?” It is well to keep in mind also that at
this time the Germans were fighting their way through Belgium and
advancing on Paris, and that the expeditionary force must at all costs
be kept supplied. In the emergency, overtime orders, good for one
month each, were granted individual firms who requested them on
account of war demands. These orders usually permitted women to
work either in eight hour or twelve hour shifts during any part of the
twenty-four hours, or, as an alternative to the shift system, two hours
of overtime daily on each of five days were allowed, making a
seventy hour week. Permission to work Saturday overtime or
Sundays was rarely granted. Additional meal periods were required if
overtime was worked.
As the unemployment crisis passed, “the sole problem” came to
be “what scale of hours was likely to give the largest amount of
production.” Steps were then taken to replace the first individual
permits for exemptions by uniform orders for an entire trade. The
latter were still issued, however, not for the industry as a whole, but
only to individual firms applying for them. The permits were largely
based on joint conferences with employers and employes, and
allowed women to work at night or some eight or nine hours of
overtime weekly. The latter meant a working week of about sixty-five
hours in textile factories, and between sixty-five and seventy in other
forms of factory work. The demands of employers had often been for
a far greater amount of overtime.
The most extensive modifications of the law were made for
munitions plants where, on account of the “urgent demand” the
inspectors “recognized that latitude on a very wide scale must be
permitted.” Night work under either the two or the three shift system
was allowed, or as an alternative five hours of overtime weekly or
seven and a half in cases of special urgency. But women were not to
be employed on Sundays except for night work.
From August 4, 1914, to February 19, 1915, a total of 3,141
overtime permits of all kinds were issued.[161] Only fifty-four permits
allowing night work remained in force at the end of 1914, though the
number was considerably increased in the first quarter of 1915.
But overtime by women workers was unfortunately not even
confined to that sanctioned by special orders. There is considerable
evidence that long hours were also worked illegally, sometimes
entirely without permission, in other cases above the permitted
modifications. In September, 1914, the belief spread about that the
factory acts were wholly in abeyance until the end of the war, and the
factory inspectors admit that undoubtedly many cases of “long hours
without legal sanction” occurred. Yet “these have been steadily
brought under better control, the more steadily because of the
knowledge of intelligent manufacturers that unlimited hours can not
be worked without detriment to output, or in the long run without
encroaching on workers’ reserves.”[162] According to the factory
inspectors, this section of the manufacturers made more resistance
to excessive overtime at this period than the workers themselves. In
the critical days when the Germans were advancing toward Paris,
many women were ready to work all day and all night on army
supplies. Except in surgical dressing factories, where the girls were
very young and the work very monotonous, the operatives were said
to show “a spirit of sustained, untiring effort never seen before and
most admirable.” One girl is quoted as saying, “My sweetheart, he’s
out there, and my two brothers, so I may as well be working,” and a
woman remarked that she wanted to be able to write her husband in
the trenches that she was “doing her share.”[163] An appeal to the
workers was made by Lord Kitchener early in the war to the effect
that “in carrying out the great work of providing the army with its
equipment employers and employes alike are doing their duty for
their King and country equally with those who have joined the army
for service in the field.” This was often posted in factories, and
helped to stimulate the women to work long hours without complaint.
 Women’s Working Hours
in 1915
Authorities differ about women’s working hours in 1915 in a way
that makes it difficult to determine the exact situation. The factory
inspectors showed a considerable degree of optimism. From their
point of view the total numbers of hour law modifications in force
remained large, but the amount of overtime and week end work
declined, and the problem of violations was not serious.
In certain important industries, particularly clothing, boots, shirts,
leather equipment and surgical dressings, the need for overtime had
“for the present at all events ceased.” Yet the total number of
requests for exemptions was no less, though there was “a marked
reduction in the amount of latitude sought and allowed; for instance,
fresh demands for permission to work on Sundays are now rarely
received, and are confined to cases where sudden and unexpected
emergency arises or the processes are continuous. Requests for
Saturday afternoon work have also become less common, and there
seems to be a more general recognition of the advantages of a week
end rest.... Sunday labor has been found to be more and more
unsatisfactory; apart from the ill effects which must follow from a long
continued spell of working seven days a week, it too often results in
loss of time on other days of the week and in consequent
disorganization.”[164]
Only fifty orders allowing Sunday work by women and girls were
outstanding in December, 1915. These orders were strictly
conditioned. Sunday work was to be allowed only in cases of
emergency and for part of the day, and was not to be carried on in
any two consecutive weeks. Moderate hours through the week and
time off on Saturdays were required.
Besides orders covering some twenty-seven different trades
affected by war demands, a general order was issued in September,
1915, modifying the statute law in all other nontextile factories in
which exemptions were legal. Seven and a half hours of overtime,
making a working week of sixty-seven and a half hours, were
permitted, and daily hours night run up to a maximum of fourteen.
The 1914 general overtime order was continued in the munitions
industry, and in special cases a week of from seventy to eighty hours
was allowed. The factory inspectors noted on one hand that “many
of the schemes put forward were considerably within the maximum
allowed, and even where the maximum was sought it has been
found in practice that the full number of hours were frequently not
worked,” and on the other hand that many special orders had been
required, especially for the large munition firms, in some of which the
hours remained longer than those permitted by the general order for
the trade. But on the whole there was “observable a distinct
tendency towards a reduction of hours in these works as
elsewhere.”[165]
Moreover, the tendency grew during the year “to substitute a
system of shifts for the long day followed by overtime.” The factory
inspectors urged the introduction of the three shift system, but, owing
to the scarcity of skilled male tool setters and other mechanics and
sometimes of women, two twelve hour shifts (generally ten and a
half hours of actual work) were much more prevalent. The inspectors
maintained, however, the superiority of three shifts, giving one
example where the change had been made in which output
increased by a third while the need for supervision diminished. But it
should be noted that although the shift system brought a reduction of
overtime to women workers, it involved an increasing amount of
night work.
The factory inspectors had but slight criticisms to make of illegal
overtime and violations of orders. “There is little cause for complaint
as to the proper observance of the conditions of the orders,” except
in the Midlands. A few cases of serious irregularity were found
elsewhere, but were “striking exceptions to the general rule.... The
most general cause of complaint is that occupiers have taken upon
themselves to work overtime without authority, and have continued it
without applying for a renewal of their orders. There has been
neglect, too, in affixing notices specifying the hours of work.”[166]
 But it is probable that during at least part of 1915 the optimism of
the factory inspectors regarding the shortening of hours and
elimination of illegal overtime was not completely justified. Under
powers granted by the Defence of the Realm Act an order of June 6,
1915,[167] extended the right of the Secretary of State to modify the
labor laws in a way which investigators state “proved very difficult to
handle properly.”[168] The modifications could be made, not only in
government factories and on government contracts, but in “any
factory ... in which the Secretary of State is satisfied that by reason
of the loss of men or transference to government service, or of other
circumstances arising out of the present war exemption is necessary
to secure the carrying on of work ... required in the national interest.”
Complaints of excessive hours and violation of overtime orders
multiplied. Officials of the Ministry of Munitions admitted, during a
visit to the United States in the autumn of 1917, that for four to six
months after the shortage of munitions was discovered in the spring
of 1915, many women worked nearly a hundred hours a week. A
case was cited in the House of Commons of a factory where girls
were working regularly ten and a half hours a day seven days a
week, and had worked ninety-five hours a week “many times” since
the beginning of the war. Another much quoted case was that of a
firm holding an exemption allowing moderate overtime which worked
one girl thirty hours at a stretch and another twenty-five and a half
hours. The second girl, who was under eighteen, then met with an
accident which brought the situation to the attention of the factory
inspectors. A prosecution was started, but at the first trial the case
was dismissed on the grounds of a national necessity. At a second
trial the counsel for the defense called the prosecution “a piece of
fatuous folly, only justified by supreme ignorance,” and said that the
Home Office, instead of prosecuting “ought to have struck a special
medal” for the girls. “Now is not the time to talk about factory
acts.”[169] The employer was finally put on probation.
However, in the latter part of 1915, and principally as a result of
the unsatisfactory conditions there took place the first of a new
series of developments which were to bring back women’s hours
almost to prewar standards and to improve greatly the scientific
basis for the restriction of working hours.
To the Ministry of Munitions is mainly due the new committees
which were largely responsible for the change. A special agent for
the Federal Trade Commission states that—
Toward the end of 1915 it became certain that
some action would have to be taken by the ministry
to deal with the question of excessive hours, more
particularly those worked by women and boys. The
department’s attention was drawn to the fact that
the maximum number of weekly hours allowed
under the provisions of the general order made
under the factory acts was continually being
exceeded and that without the support of the
ministry the home office found it increasingly difficult
to insure that no persons should work excessive
hours.[170]
The action took the form of the appointment of an
interdepartmental committee on hours of labor which included
representatives of the Home Office, the Admiralty, various supply
departments and the Welfare Section of the Ministry of Munitions.
The committee considered “claims from employers either for
permission to work on Sunday, or for exceptionally long hours during
the week, and its inquiries have resulted not only in a reduction of
Sunday work, but in a more favorable redistribution of hours
generally.”[171] In October, 1915, it secured the discontinuance of
practically all Sunday work in munition factories on the northeast
coast.
In September, 1915, the better known Health of Munition Workers
Committee was appointed by the Minister of Munitions with the
concurrence of the Home Secretary “to consider and advise on
questions of industrial fatigue, hours of labor and other matters
affecting the personal health and physical efficiency of workers in
munition factories and workshops.” By November the Ministry had
referred to this committee the question of Sunday work and of the
substitution of the three shift for the two shift system.
Even before its recommendations were received the Ministry took
steps to discourage Sunday work and the employment of women at
night. A circular was sent to all controlled establishments urging that
all workers should be granted a weekly rest period—preferably
Sunday—both for their own good and in the interests of production.
The circular said, in part:
The aim should be to work not more than twelve
shifts per fortnight or twenty-four where double
shifts are worked.... Where three eight hour shifts
are worked, not less than two should be omitted on
Sunday. It is, in the opinion of the Minister,
preferable to work a moderate amount of overtime
during the week, allowing a break on Sunday, rather
than work continuously from day to day. It is still
more strongly his view that where overtime is
worked in the week, Sunday labor is not desirable.
Another circular of instructions in November, 1915,
recommended that under the two shift system, women should be
employed “as far as is reasonably practicable” by day rather than by
night.

Later Developments
Scientific studies in fatigue, and improvements in the regulation
of working hours, continued to be the chief features of the women’s
hour situation during the latter part of the war. Two reports made for
the Home Office by Dr. A. F. Stanley Kent on An Investigation of
Industrial Fatigue by Physiological Methods, showed, as the result of
actual experiments with working days of different length, that
overtime may “defeat its own object” and actually cause a diminution
in “total daily output.” The first report which had been published in
August, 1915, was of less direct practical importance, giving merely
a description of a number of tests adapted to showing fatigue in
factory workers. The second report, issued in September, 1916, was
a study of output and the effects of fatigue in certain plants making
war equipment under working days of different length. Among its
most significant conclusions from the point of view of hour restriction
were the following:
A worker employed for 10 hours per day may
produce a greater output than when employed for
12 hours, the extra rest being more than sufficient to
compensate for the loss of time.
A worker employed for 8 hours per day may
produce a greater output than another of equal
capacity working 12 hours per day.
A group of workers showed an absolute increase
of over 5 per cent of output as a result of diminution
of 16½ per cent in the length of the working day.
Another group increased their average rate of
output from 262 to 276 as a result of shortening the
day from 12 hours to 10 and to 316 on a further
shortening of 2 hours.
Under the conditions studied neither rate of
working nor total output attains a maximum when a
12 hour day is adopted.[172]
Two other scientific reports on the subject dealt with The
Question of Fatigue from the Economic Standpoint, and were put out
by a committee of the British Association for the Advancement of
Science in September, 1915, and September, 1916, respectively.
The monographs emphasized the importance of an observation of
fatigue in the workers and adaptation of the hours of labor thereto.
The memoranda and reports of the Health of Munition Workers
Committee are the best known of this group of studies, no doubt
because besides being the work of scientific investigators, they were
carried on to form a basis for official action, and contained definite
recommendations for the shortening of hours in order to improve
output. While they dealt with munitions work alone, the principles
brought out are equally applicable to any form of industrial
occupation.
The first memorandum published in November, 1915, covered
the subject of Sunday labor, and recommended without qualifications
a weekly rest day for all classes of workers.
... If the maximum output is to be secured and
maintained for any length of time, a weekly period of
rest must be allowed. Except for quite short periods,
continuous work, in their view, is a profound mistake
and does not pay—output is not increased.... Some
action must be taken in regard to continuous labor
and excessive hours of work if it is desired to secure
and maintain, over a long period, the maximum
output....
Should the early stoppage of all Sunday work be
considered for any reason difficult if not impossible
to bring about, the committee trust that it will at least
be practicable to lay down the principle that Sunday
labor is a serious evil which should be steadily and
systematically discouraged and restricted.
For women and for “young persons,” the need of abolishing
Sunday work and granting week end and other holidays was even
more urgent than for adult males. “The committee are strongly of
opinion that for women and girls a portion of Saturday and the whole
of Sunday should be available for rest, and that the periodic factory
holidays should not, on any account, be omitted.”[173]
The committee went on record at this time in favor of a return to
the prewar legal standard of weekly hours. “Continuous work in
excess of the normal legal limit of sixty hours per week ought to be
discontinued as soon as practicable,” though the hours permitted in
any one day might vary somewhat more than the factory acts
allowed. There was, for instance, “little objection to such moderate
overtime during the week as can be compensated for by an earlier
stop on Saturdays.” But in general, “the need for overtime amongst
women and girls is much less pressing than it is for men, they are
rarely employed on highly skilled work, and where there is still a
good reserve of labor there should be little difficulty in gradually
introducing shifts.... [The committee] strongly urge that wherever
practicable overtime should be abandoned in favor of shifts.”
Three systems of hours were found in operation in munition
plants. There was the single shift of thirteen-fourteen hours including
meal times, which was known as the “overtime system,” two twelve
hour and three eight hour shifts. The committee considered that in
the long run the latter yielded the best results with women workers.
The committee recommend the adoption of the
three shifts system without overtime, wherever a
sufficient supply of labor is available. Where the
supply is governed by difficulties of housing and
transit, the committee are of opinion that every effort
should be made to overcome these difficulties
before a less serviceable system be continued or
adopted....
They [eight hour shifts] involve little or no strain
on the workers; the periods during which machinery
stand idle for meals are very much reduced, while
significant statements have been put before the
committee claiming beneficial effects upon output.
Observations were later made for the committee of a group of
nearly a hundred women over a period of about thirteen months,
during which time their actual weekly working hours were reduced
from sixty-six on seven days to forty-five on six days. Yet output
arose nine per cent. The committee concluded:
For women engaged in moderately heavy lathe
work a 50 hour week yields as good an output as a
66 hour week, and a considerably better one than a
77 hour week.[174]
In regard to night work, however, the committee felt that the
exigencies of war time prevented a return to a really desirable
standard. “The employment of women at night is, without question,
undesirable, yet now it is for a time inevitable.” It demanded special
care and supervision and the use of such safeguards as would
reduce its risks to the minimum. “In no case should the hours worked
at night exceed sixty per week.” Whether continuous night shifts or
alternate day and night shifts should be worked was a matter to be
settled by local considerations.
Another interesting point in the Health of Munition Workers
Committee memoranda was the recognition of the value of brief rest
periods within working hours. “Pauses, well distributed and adapted
in length to the needs of women workers, are,” it was said, “of the
greatest value in averting breakdown and giving an impetus to
production.” Particularly with night work “adequate pauses for rest
and meals are indispensable.” On twelve hour shifts, two breaks of
three quarters of an hour each for meals should be taken out, while
on an eight hour shift a half hour for one meal was sufficient. Though
the statutes allowed five hours of continuous work in nontextile and
four and a half in textile factories, many managers believed that four
hours is the longest period during which a woman can maintain
continuous work at full vigor. Within this period a pause of ten
minutes has been found to give excellent results.
The reports, showing as they did that “the hours which conduced
most to a satisfactory home life and to health conduce most to
output,” have had a notable influence both in this country and in
England in strengthening the scientific basis for labor legislation. For
instance, on October 3, 1916, a significant clause was added to the
order permitting overtime work, allowing it when necessary on
account of the war, only if “such exemption can be granted without
detriment to the national interest.”[175]
The Interdepartmental Hours of Labour Committee used the
recommendations briefly outlined above as the basis for its work,
formulating a new general order regulating overtime, which was
finally issued by the Home Office September 9, 1916, after
prolonged criticism by all the supply departments. The order applied
to all controlled establishments and national workshops and might be
extended to any other munitions work. In other cases there was to
be a return to factory act hours.
 Hours not allowed by the factory act or the order
in question are not to be worked after the 1st
October, 1916, unless expressly sanctioned by
special order from the Home Office. Applications for
such special orders will not in future be entertained
save in exceptional circumstances and in respect of
work of a specially urgent character.[176]
Three schemes of working hours were provided for, a three shift
system, two shifts, and a rearrangement of statutory hours. Under
the first plan no shift might be longer than ten hours and a weekly
rest day was compulsory. Weekly hours under the two shift system
were not to exceed sixty, and a maximum of six shifts was to be
worked in any one week. The third scheme also limited weekly hours
to sixty, and required working hours to fall between 6 a.m. and 10
p.m., but as much as twelve hours might be worked in a single day.
Hours for meals were fixed according to the Health of Munition
Workers Committee recommendations. In cases of special
emergency in naval ship repairing women might work a maximum of
sixty-five hours weekly. They might only be employed at night if
supervised by a woman welfare worker or “responsible forewoman.”
Except for the night work, the order was practically a return to prewar
standards.[177]
Meanwhile the Ministry of Munitions gained more direct control
over the regulation of hours in January, 1916, through the Munitions
Amendment Act, by which it was empowered to fix women’s hours
on munitions work in all establishments where “leaving certificates”
were required. It supplemented the efforts of the Health of Munition
Workers Committee by ordering the “investigating officers,” of the
labor regulation section of its labor department, who had charge of
all labor matters except dilution and the supply of labor, to report
cases of excessive overtime and unnecessary Sunday work in
controlled establishments, with a view to having an order issued
prohibiting it. An official circular of March 17, 1916, urged that more
use be made of “week end volunteers,” so that all workers might
have a Sunday rest, “both in the interest of the work people and of
production.” But the numbers of “week end munition relief workers”
remained small, due to the attitude both of the firms and of the
workers, who could not afford to lose their Sunday pay.[178]
Some complaints of unreasonably long hours still persisted. The
Woman Worker reported during the winter of 1916 the case of a
Scottish factory making cores for grenade bombs which opened at 6
a.m. and closed at 8 p.m. the first five days of the week and at 6 p.m.
on Saturdays and Sundays making a working week of eighty-two
hours exclusive of meal times.[179] Investigators likewise stated that
the labor shortage and the urgency of the demand have “frequently”
caused the recommendations to be exceeded.[180]
On the other hand, both in the Clyde district and around
Birmingham the British Association for the Advancement of Science
stated, in April, 1916, that the working week varied from forty-four to
fifty-six hours, fifty-four hours being the most common period. In
August, 1916, the then Minister of Munitions, Dr. Christopher
Addison, said in Parliament in response to questions that the
interdepartmental committee was taking steps to bring the working
week within the sixty-hour limit in all controlled establishments. And
an investigation by the factory inspectors in 1916 found that out of
243 “controlled establishments” 123 were working within the regular
sixty-hour limit and only fifteen were working “irregular and
excessive” hours, though in nineteen the breaks for rest periods and
meals in some way violated the conditions of the order.
In 1916 at least eight hour shifts had failed to “make much
progress” and twelve hour shifts were still “predominant.”[181] The
latter, it should be noted, meant not twelve but ten and a half hours
of actual work over a twelve hour period. Certain large munition
establishments, including at least one government factory, even
changed from the eight to the twelve hour shift in 1916.[182] Besides
the shortage of labor it was said that the workers disliked the
necessary changes in meal times and living arrangements under the
shorter system, and that transportation schedules were not
conveniently adjusted to it. It was alleged that young girls preferred
the longer hours because they then escaped helping with the
housework!
 Outside the munitions industry the factory inspectors reported
“numerous applications” for overtime orders in 1916, involving,
however, a rearrangement of daily hours rather than a weekly total
beyond the statutory limit.
Much that was abnormal and bound to be
injurious to health if long continued has been
brought within manageable limits. Excessive
overtime and Sunday labor have been checked and
as nearly as possibly abolished.... In general the
experience of war emergency work, far from making
employers in love with extended hours, appears to
be producing a contrary effect and bringing about a
sense of the importance of so limiting the period of
employment as not to produce any feeling of
exhaustion or even of marked fatigue.
Much attention was paid to the question of Sunday work by the
interdepartmental hours committee. In January, 1916, it obtained a
weekly rest period for all women in explosives factories under
continuous operation. It soon secured the entire discontinuance of
Sunday work by “protected persons” in national projectile and shell
factories except a short shift in the projectiles establishments for
“rectifying” shells and cleaning the shop. Night work for women,
which was never recommended for abolition during the emergency,
of course persisted and even tended to increase, as more and more
plants went into continuous operation. Especially in shell factories
large numbers of women worked at night. Fewer factories worked
overtime without permission, though some prosecutions were
necessary in the woolen industry. The idea that the factory acts were
in abeyance till the end of the war was disappearing. With an
increased recognition of the injury done to both quality and quantity
of work by fatigue the powers available under overtime orders were
in some cases not fully used by the employers. One employer
remarked that overtime orders were “like a drop of brandy, a useful
thing to keep in the house, but you didn’t want always to be taking it.”
The developments in the regulation of women’s hours noted in
1916 were typical of the course of events through the latter part of
the war. “The tendency to reduce hours continues,” said the factory
inspectors in 1917. “Cases in excess of the factory acts are now
rare.” In a report published in 1917, the Health of Munition Workers
Committee made an important contribution to standards of working
hours by stating that the hours “provisionally” fixed were probably too
long, except for very short periods or for very light work carried on
under exceptionally good conditions. While the hours which
produced the largest output varied according to the nature of the
work, age and sex of the workers, and conditions inside and outside
the factory, in general “the time was ripe” for a further marked
reduction in hours. For certain processes weekly hours could
“advantageously be reduced to a total of from fifty to fifty-five” and
even lower limits might give an equally good output.[183] No action
was taken during the war period by officials to put these
recommendations into effect.
The factory inspection department of the Home Office had
outstanding in 1917 emergency orders permitting overtime only in
various textile industries, where hours were normally limited to fifty-
five instead of sixty, in munitions and shipbuilding where the
emergency orders of 1916 were continued, in boot factories and in
flour mills, oil and cake mills and malting, where night work by
women was permitted.[184] Sunday work was strictly limited, being
allowed only where women replacing men were obliged to work a
few hours on Sunday, as in dairy plants, in temporary emergencies
in munition factories and in continuous processes, provided another
weekly day of rest was given.
An indication of the actual hours worked in munition plants at this
time may be obtained from a survey made by the factory inspectors
in 1917 of 177 factories in the southeastern part of England which
employed 27,000 persons. The largest group, sixty-two, worked
between fifty-five and sixty hours weekly, while fifty-one worked from
fifty to fifty-five hours. In thirty-two cases, weekly hours were sixty,
and in only five cases were hours longer. On the other hand, twenty
plants worked from forty-five to fifty hours and seven less than that
number. The factory inspectors stated that the number of “temporary
exemptions” to the regular overtime order for munitions work had
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

ebooknice.com