Web design – KidsLearnToCode

I’ve been thinking about teaching HTML/JavaScript lately and why I don’t do it. One of the main reasons is that front-end as it’s done today is much harder than learning a language like Python or Java or C. This will surprise you if you’re a developer who fell into a Rip Van Winkle type sleep in about 2002.

It used to be that making the “front end” of a web page (basically HTML + stylesheets + JavaScript) was a great way to get started learning to code. After all, you could start with something like this:

<html>
<body>
Hello world!
</body>
</html>

And hey, open that code up in a browser and it will still work! The difference is that in those days, every single element or file you added, no matter how complicated it was, was written by your own hand. You never looked at your file structure and said “what the hell is all this stuff for?” (At least, not if you recently wrote it.) And you could use code that you entirely wrote by hand for professional -level production! Sure, you could by using FrontPage or DreamWeaver, but even then if you spent a little time you’d understand what the code they put in was for.

And if you wanted to see how it was done, you could just go on the web and hit “show source.” You could read everything that made a web page do what it does, and if you spent enough time you could understand it.

Nowadays, however, professional-level front-end almost always involves some kind of “framework.” The definition of a framework is kind of hazy, but I’m going to use a broad definition that includes everything from Angular to Ruby on Rails to .Net to React, knowing very well that those don’t really go in the same category. What many of them have in common is that there is a moment of instantiation where some huge file structure is automagically constructed for you. It will usually create something like this:

Angular File Tree

And that’s just the top tenth or so of it. Note that depending on the “framework” (again using that term very loosely) your file structure there could include a lot of backend stuff too, for example in Ruby or .Net.

So someone set all this stuff up to make it easier for you, right? No way you were going to make all those files. But here’s the problem: now you have a digital house of cards where if you screw up just the wrong thing the whole thing comes crashing down and stops working.

But, I mean, you can’t just leave it alone either unless you want to publish a page that says “Welcome to [framework]! Click here for a tutorial to make your page.” Presumably you started this whole process because you want to make a website with some content.

So a lot of the time you spend is learning what small tiny fraction of these files it’s (sort of) safe to screw with. And you may work with this framework for a very long time before you know what most of those files ever do. I’ve been doing .Net long enough to at least know what most of the files in an MVC file structure do. But sooner or later they’re going to change the whole framework and everything will be confusing again. If you don’t believe me as anyone who learned Angular 1.

And things get worse when you need to use more than one of these frameworks at the same time, as often you do. If you think that a .Net or an Angular framework alone are confusing, try to figure out how to shuffle these two houses of cards into a single house that still stands.

And forget seeing how someone else does something. Most professional javascript today goes through a minifier, Now if you try to read someone’s script you’ll see something like this:

minified javascript

Good luck trying to figure out how that works!

Of course you could still teach people to make a website the old-fashioned way. But the question is, is it worth it? Might it be that the baroque intricacies of cascading stylesheets will become as distant to users in the future as pointer-level memory management is to most people that use languages like Java or Python?

Not sure what to do about this. What people want from a web app nowadays requires these frameworks. But it’s sad to think of how it’s changed.

screen-shot-2016-10-10-at-1-05-48-pm How often has this happened: you click on something you didn’t actually want to see (maybe because you were trying to scroll with your finger), causing an image to fill the screen obscuring whatever you were actually trying to read. Instinctively you hit the ‘back’ button to get back to whatever you were trying to look at.

And…you’ve lost everything. You’re somewhere else completely. You go back to the page you were on before Facebook. Annoyed, you try to go forward again, but you’re looking at an entirely different post. You scroll down, but the post you were reading is nowhere to be seen. What happened?

Let’s go back a few years, like maybe 15. I was making websites back in the days when dinosaurs roamed the web. Modern developers, in the middle of fighting over whether to use React or Angular2, might entertain themselves looking at this list of old 15-20 year websites moldering on servers that nobody ever bothered to update or shut down. They laid things out with tables. Tables!

If that doesn’t mean anything to you, let me explain. Back in the day, when you got a Photoshop mockup from a designer, the first thing you’d do is chop it up into little boxes, export them from Photoshop as jpegs or gifs (no pngs or svgs in those days). Then you’d use the HTML <table> feature to plan the page out in rows and columns. This was a hack; the tables tag was made to create, well, tables, like rows and columns with headers. But before browsers had consistent and reliable stylesheets, it was the only certain way to always get the layout you were looking for.

But in the middle of laughing at the silly old animated gif backgrounds, you might notice something, as for example on this page for Dole Kemp ’96: before the page even finishes loading everything is in exactly the right place, even before any of the images loaded. And after it loads everything stays exactly where it’s supposed to.

There’s a reason for that. Back then, instead of using styles, every image had a HEIGHT and WIDTH attribute (yeah, back then some people capitalized their HTML too). In the days of 56k dial-up modems, every kilobyte that went over the was precious, so you exported the images at the precise right size and then set that through the attributes in a table.

Compare that to many framework-driven applications today, especially when you’re loading them on a phone. You’ll be in the middle of reading a paragraph, and it will jump 300-400 pixels above and below you. The Talking Points Memo site for example (whose content I love, by the way), is terrible at this; when I read it on my phone I feel I’m chasing the content all over the page.

Nobody uses tables to build pages anymore (except Visual Studio’s .NET templates, because Microsoft). Now people declare the size of their images using stylesheets, if they even bother. When they do it’s probably done dynamically, sometimes by resizing on the fly using Javascript.

Now let’s get back to the lost Facebook post you meant to read, and lost when you hit ‘back.’

Back in the primitive days of the Web, the back button was a reliable thing. It took you back to whatever you were looking at last. Sure sleazy advertisers could try to override it with Javascript, but you learned to avoid those sites.

But the back button won’t get you back to what you were looking at now. Why didn’t it just close the image and go back to the post you were reading? Because the image you were looking at is actually the same url that you were reading before (because Facebook is what developers today call a ‘single page application’). There was actually some little ‘x’ in the upper right hand corner of the screen that would have closed the image and allowed you to read what you were reading, but you didn’t see it.

Now it’s too late, because you went off Facebook. When you tried to go back, in the continuously loading application the particular post you were reading is far down the feed. Facebook has loaded twenty or forty new posts in the time you were away; there’s no way to know how far you’ll have to scroll to get back to where you were. And because of Facebook’s constantly shifting algorithm weighing what should and shouldn’t be shown, it might be gone altogether. You may never even get a chance to like your friend’s cat pictures or make an angry face in sympathy to her political rant.

But it has to be that way, say the developers as they look up from their scrambling efforts to learn whatever Javascript framework displaced the one they were using last year. It’s Web 2.0! Anyways, why don’t you just get the app?

Listen: whenever engineers tell you ‘it has to be that way,’ they are failing at their job. There is no technical impediment to making a web that works the way people expect it to. Instead of fighting over what Javascript superset to transpile from, maybe we should be talking about that. Let’s start with making pages that stay in place while people read them, and making pages where the ‘back’ button does what it’s supposed to.

Why Front-End Is So Hard Nowadays

How the Web’s interface is broken