Rethinking Best Practices

In 2013 when this guy stood up in front of a room full of people and titled his presentation "Rethinking Best Practices", he might've been thinking, "Hey, open source, yay, only use it if you need it." and couldn't have imagined that in 3 years every other job in the web world would be using React and the "React Ecosystem" of additional code to fucking, do, this [react freakin out]. To render this [html output] on the server and send a bunch of stuff that looks like this [react templates]. Why? I donno. I don't know why. It's a product among many.

Now, I'm not going to blame this guy for his enthusiasm. I'm just going to accuse the rest of us of falling for the Boy Band syndrome. You see, maybe because we all collectively hated boy bands in the late 90s for screwing up the music industry after the Golden Age of Grunge, we were more suceptable to Syndrome. Boy Band Syndrome that is. It's why the boy talking is so cute and so confident that you fucking believe he loves you and wants what's best for you.

Data and Code

The best practices they were rethinking was the idea of seperating HTML and Javascript into seprate files and updating the HTML on the DOM. And they mentioned the DOM being too heavy. If you hooked up a [Babel] compiler and then let that loose on your code editor, then ah ha, you can have your cake and eat it too. See, you can just write the user Interface as a return value of a function of code. Ifs and data will change and you know, if that happens, we'll recalculate what the UI should be based on all this, and we'll show that. It'll be fine.

This conceptual shift that these young boys arrived at by implementing a templating language step in the JS file, so those HTMLs become JS functions that look totally normal and good and, yeah. setState, setState's called, we save you the trouble, of calling a render function. We, we do it for you.

They forgot to mention the trade offs to their inventions. It's okay, none of them do. I'm onto blaming them, they know not what they do. The trade offs are, when you put the markup in the JS and turn it all into functions, that whole blob, every level of the higherarchy is sent as a additional Javascript. I say additional because the great thing about Javascript and HTML is that they inventors were smart guys too. They didn't have a record deal yet, but they knew that data and code go hand in hand. Data is the stuff that your code works on. Transforms from one thing to another. HTML is XML after all, both designed to provide some structure to the data that the internet likes to move. You got your headings and paragraphs and lists and the like. These are represented in Javascript by accessing the document object in the Developer Tools console.

In document you'll find a big object that includes both the data and the functions to manipulate that data, because you know, in the 90's guys that I just said were so smart. Well they didn't know that Object Oriented Programming is a complete joke and Java was a popular language, still is. Anyway, this object is the HTML. It's what you get when you parse the HTML on the page into it's data. It could be smaller but it's still right there, in memory. Reactive as hell already. Change anything, your browser will change the document.

And that's the beauty, by the HTML being the data we actually get to have the best of all worlds. We get structured data that anything can read without a full javascript parser (just an HTML one). We get smaller Javascript bundles, because they're crafted to opperate on the data as presented. And there are plenty of sweet patterns to loop over elements in the DOM and quickly update them. You don't have to straw man .innerHTML everything. And the JS bundle doesn't really interfere with the rendering speed of the page. It attaches interactivity after the fact and the browser does the right thing because that's what it was designed to do.

The web in general is very different from the rendering environment these boys built React to solve. Instagram Web was an advertising platform that also shows pictures of children and I donno, cactuses. Theses lots of pictures and there's a feed and then there's ads. The feed needs to "React" to how the user is using it. Did they stop on the hand bag, quick, let's get a hang bag ad ready for further down the page. You get what I'm saying? It's a mini facebook. Without the margin, [fb] stuff. Facebook and other realtime apps might benifit from React. Having the ability to break the page into boxes and assign whole teams, whole departments to that box, it might be best to build something that automatically encapsulates that box. People are going to be waiting anyway, it's the web. It's not indexable by search engines. It's an app.

The web in general are public facing, searchable and mostly text. There's a lot of text. Did, I mention the web is basically a library of text? Even E-Commerce suffers from not being quick enough. Can you believe the fall off of users who actually buy the thing buy the milisecond. Somebody needs to publish more data on page load times and sales loss to motivate the management set on the fundamentals.