John Sheehan - Creating React Front-End Web Applications with Python

John Sheehan

JennaSys

React to Python
by John Sheehan

Copyright 2021 by John Sheehan. All rights reserved.

No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher.
Technical Reviewer: David Ford
Cover Design: Mike Lugin
May 2021: First Edition

"Python" and the Python logos are trademarks or registered trademarks of the Python Software Foundation, used by the Author with permission from the Foundation.

Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark.

The information in this book is distributed on an as is basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author(s) nor publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work.

To report errors, please e-mail:

Source code used in this book is available to readers at:

• https://github.com/rtp-book/code
• https://github.com/rtp-book/project

For update notifications, subscribe at : https://pyreact.com

ISBN: 978-1-7365747-1-3
[1346348]

John Sheehan graduated with a degree in Computer Science & Engineering from the University of Illinois at Chicago, and has been programming primarily with Python for over a decade. As a freelance software developer, they have developed custom business software for scores of companies throughout the United States. In their free time, John is an avid DIYer, electronics enthusiast, and musician. They are currently based in sunny Southern California, and are the meetup organizer for the local Python and Raspberry Pi user groups.

I would like to thank Dave for introducing me to React and consistently keeping me intellectually honest, and especially Rachel for always being there for me no matter what direction I was heading and for helping to keep me alive in general.

Dedication
For my Dad, someone who was never afraid to think big.
1940 - 2020

Some time ago I made a walk, together with a colleague, in one of the rare patches of nature in the vicinity of Rotterdam, the Netherlands. In order to reach the nice and quiet parts, we had to cross a large road construction project, connecting two main highways in order to lessen the traffic through the city. As we stood on the high pedestrian-bridge, I was struck by the professionality and the amount of planning that was demonstrated below me. People moving like ants in parade, machines like large bugs, each seemingly knowing exactly where to go, what to do and when. A best practice for everything. Safety procedures. Second sourcing of materials. Well tested long term behaviour of constructions. Appropriate and well kept tools and machines. Of course, sometimes roads get washed away. But road construction is rarely abandoned after threefold overruns in budget and planning. Whereas for software... Well, that's normal, isn't it. Whether you look at space travel, air transportation or car electronics, software is the Achilles heel. Still.

While the infrastructure supporting the web world features a lot of redundancy by virtue of its distributed nature, this doesn't hold for the software that pumps data through its veins. Under a cloak of ever changing IT-slang, referring to ever changing silver bullets, there's a patchwork of organically grown "technologies", a euphemism for ad-hoc approaches to challenges that are bound to arise if a solution to a very particular problem is pushed far beyond its limits, rather than rethought from scratch. Datastreams coded in ASCII rather than binary, requiring five times more bandwidth than physics dictates, sandboxed interpreters that try to cover up for security challenged operating systems well in their sixties, relational databases serving bulk numerical data from power-hungry server farms, languages designed to add some motion to static webpages, but now used for neural nets and handling big data. And then the XMLHttpRequest, the cat flap through which massive streams of largely redundant data try to convince consumers that they need a new mobile phone since the old one gets so slow. And of course 4GL, or 5GL.

In such a situation of organic growth, a primitive law drives progress: Survival of the fittest. For every JavaScript library that's still alive after three years, at least a handful have been abandoned, leaving a trace of unmaintainable applications. Web development is the art of finding the winners. And wherever I look, one winner seems clear. If one of my students has to do a front end job at some company for her graduation, I routinely ask: React? And of late the answer is: Yes. Without exception. The React paradigm works. Once you master it. Out of many possible choices, React seems to have hit a sweet spot. With its declarative approach to data dependencies and DOM-tree updates it really takes a burden off the shoulders of the developer: How to create a GUI that's truly responsive, not in the superficial sense of adapting it's layout to things like screen size and orientation, but in adapting its contents in response to user actions and data dependencies. It makes a GUI behave intelligently, without the vulnerable micro-management coming with purely imperative coding.

React will probably be with us for quite some time, and that's good. But the same holds for the underlying language, and here tastes differ. Nothing wrong with that, some like ice-creams and others like fruit. But, no matter what your preferences are, languages matter! I've never heard a carpenter argue that her tools are unimportant. But it's quite normal to hear a self-nominated IT expert claim that programming languages don't matter. Developers making such a claim should be convicted to programming in assembly for the rest of their career. With web assembly they might. Unfortunately the browser world doesn't offer much choice. Nothing bad about JavaScript. If you grew up with front end development, it's probably your first language and therefore your frame of reference. Mine was Basic. It was the perfect language, I could do anything in it, using only goto's. Until I discovered Pascal. And then C. And then C++. And then: Python.

Python is growing. The push comes from the world of application scripting, simulation, industrial controls, big data and neural nets. That's also the world I come from. And when I had to develop an occasional (unavoidable) front-end I did so in JavaScript. But we didn't match. And writing 80% of my application in Python and 20% in JavaScript led to an inversion of Pareto's rule: 20% of the result cost me 80% of the effort. That was when Transcrypt was born. I tried out some existing alternatives, but performance was a problem in the computationally heavy applications (even in the front-end) I had to deal with. So I did what I liked to do as a student. I wrote a compiler. As the GitHub repo was public, it drew some attention. And cooperation. That's where it started. But the browser world kept changing rapidly. There were bundlers, npm and: React.