Embarking on learning React
When I was front-end lead bootstrapping the new Solicitors Regulation Authority website, the world of Web Development was a different place. Although most of our visitors were using IE6, we only had IE5 on the internal systems, so I had to work from home if I needed to do debugging with Firebug (thank you, thank you, Joe Hewitt). We were given a domain name and an open-source Java-based MVC templating language called Freemarker to generate dynamic pages (I had to print the manual because our censorware wouldn’t allow me to read it online). Non-dynamic pages were coded by hand, using semantic XHTML that degraded gracefully (I’m still proud of the accessibility policy we wrote, and our Constitution document that established our priority of constituencies to competing internal stakeholders).
But the thing that scared me the most was making changes to the CSS. I used to minify the stylesheet, not so much for performance reasons but to strip out all the comments like “Don’t delete this. I don’t know what it does”. I remember developing some elaborate system of classes etc so that I could “namespace” rules to try to stop them clashing and (if I recall correctly) making Freemarker hash a page’s URL into an id on the <body> element so I could have page-specific rules. Basically, I was trying to override the Cascade.
I’d minify the CSS using a webpage into which I’d paste the raw stylesheet (styles.full) into a textarea and press a button to receive the output, which I’d paste into styles.css. Unfortunately it barfed on universal selectors (or was it that it couldn’t distinguish between .class1 .class2 {color:red} and .class1, .class2 {color:red}? PTSD has blanked my memory) which made for some panicky reversions.
So I have a lot of sympathy with the developer love for CSS-in-JS, allowing you to scope styles to individual components. If you haven’t done so already, read and re-read the excellent blogpost A Unified Styling Language that calls for more understanding between the React and the CSS communities; like the post’s author, I find myself in a foot in both camps.
I’m currently consulting with Wix Engineering, the people who make the website-building tech that enables 100 million users to create sites with drag-and-drop editors. As you’d expect, the tech stack is pretty damn complex, and a lot is based on React.
When I first encountered React, I was sceptical; it didn’t smell like the web development I knew. But it did feel like the systems programming and architecture I’d done in the early 90s: making reusable components, maintaining state and passing props around, with a compilation stage and a subsequent linking stage to hook the compiled modules together and to the underlying Operating System (in my case, VAX/VMS).
There are performance penalties for sending down loads of JavaScript across the network and asking potentially low-specced devices to parse and execute it in order to build a DOM, although React’s ability to render as HTML on a server can certainly help with (perceived) performance. Whether an app can work in a not-much JavaScript environment like Opera Mini is unclear to me at present; I suspect that if the developer chooses to make it all work with Progressive Enhancement, it’s possible (but I’m just getting started learning the nuts and bolts).
I note, too, that Opera Mini finally got an ‘automatic’ data savings mode that will use heuristics to decide whether to use the Presto-based server-side ‘extreme mode’ rendering, or to use the webview-powered ‘high’ mode that compresses all assets but is fully JavaScript-enabled. I know from my time at Opera that fewer and fewer sites work without JavaScript, and I think that (for better or for worse) the line between native and web is blurring (users expect ‘apps’), and that JavaScript will be the way forward. (Chris Coyier has an excellent article called What is the Future of Front End Web Development?, which I heartily agree with.)
Whether or not this is the “right” way for the web to be heading, I don’t know. But that doesn’t matter; it seems clear that it’s the direction the web is heading. (I’m a pragmatist; I disliked developers only using -webkit- vendor prefixes, and then we at Opera supported them — as does everyone else now. Opera lost so much time competing against WebKit/ Blink that we had no time for cool UI stuff and features, so we dropped Presto and used WebKit/ Blink, which gave us time to implement Progressive Web Apps, AdBlocker, Power Saving Mode, in-browser VPN, Video pop-out etc.)
Therefore, I want to learn the tools (React, Typescript etc etc) so I can help this incarnation of the web be better. Wix have asked me to help them make their products better, more performant, easier to use, and be more inclusive. How can we help non-programmers build Apps that are accessible? (And, to be clear, JavaScript isn’t a barrier to accessibility; it can often be beneficial).
On my return from WebConf Asia next week, I’ll be immersing myself in frameworks,Typescript, Webpack, node, even the horrible Git. There’s a lot for me to learn.