- My Little Geek — children’s primer with a geeky bent. A is for Android, B is for Binary, C is for Caffeine …. They have a Kickstarter for two sequels: numbers and shapes.
- Visible CSS Rules — Enter a url to see how the css rules interact with that page.
- How to Work Remotely — none of this is rocket science, it’s all true and things we had to learn the hard way.
- Raspberry Pi Twitter Sentiment Server — step-by-step guide, and github repo for the lazy. (via Jason Bell)
How much do you need to know?
I expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.
In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.
Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
An experiment in containing stylesheet complexity.
This post is part of my personal notes about the benefits currently specified in Shadow DOM, but contentious and held up in committee. We’ll work it out in standards, I’m sure — but given the number of things Shadow DOM was addressing, it may still be several years until we have solutions widely implemented and deployed that solve all of them. This has me doing a lot of thought exercises about what can be done in the meantime. The following reflects one such exercise: specifically, what would it mean to solve just the styling end of this on its own. Warning: it may be mildly crazy.
The Pandora Box
CSS works really well if you can follow good patterns and have nice rich markup. It lets you define broad rules and inherit and override selectively, and if used well it cleanly decouples a separation of concerns — it’s pretty elegant actually.
On the other hand, in the real world, things are often not that simple: until pretty recently, HTML wasn’t especially expressive natively, so we worked around it — many times on our own by adding classes like “article.” But, there wasn’t a standard. Likewise, our ideas about the patterns we should follow or best practices continues to change as we gain new powers or spend more time with the technology. Of course, there are a vast number of cases where you’ll just go and upgrade your philosophy and be the better for it, but there are a number of times when this just isn’t an option. This is sometimes referred to in standards circles, less colorfully, as “the composition problem.”
When it comes to these sorts of cases, quality and philosophy are inevitably mixed and not entirely in the control of any one team. In these sorts of cases, CSS selectors are kind of like live hand grenades, it’s just way too easy to do damage you didn’t intend to do because it requires a level of coordination of approach which is, for business reasons, highly impractical. And so you try really hard to analyze the problem, get the right select/cascade/descend/inherit/specificity, pull the pin, lob it into the pages and… hope. Frequently, all hell breaks loose. The more you mix it up, the harder it gets to reason about and the more our stylesheets explode in complexity. You’ve opened the proverbial Pandora’s Box.
Avoid problems associated with a quick fix by creating a stable workflow.
A long time ago (circa 1999) a creative director tried very hard to convince me how great working in print design was compared to web design. One afternoon before a big event for a Fortune 100 company, she showed me an invitation her team had been working on for the past 2 weeks. It had folds, panels, and colors that would wow anyone. It had just come back from the printing press and she was excited to show me how amazing it was. She began reading me the big invitation title first — to her horror she found that there was a spelling mistake on the cover. The entire set of 10,000 invites would have to be thrown in the trash and at the cost of $15,000 — that would be hard mistake to swallow. She was speechless.
My response to what had just happened was this…”That’s why I like designing for the web. I would have been able to change that spelling mistake in 5 minutes…”
At that point in the web’s history anyone with a web connection, an FTP program and a text editor could edit HTML code on the fly. It really was the wild wild west of web development — this was the web’s best and worst attribute. For many young developers and designers it gave us a chance to create, edit, and publish web pages as fast as we could code them.
Uncertainty is a feature, not a bug.
After decades of work on programming, we finally got a development environment with massive reach and tremendous power. Somehow, though, the web isn’t centered on a comprehensive programming environment. The web succeeded with a (severely) lowest-common denominator, specification-driven approach that let it grow with time, technology, and multiple communities, across multiple platforms.
Almost two decades ago, I was all excited about Java. Write applets once, run anywhere, with libraries to make sure it all came out the same wherever anywhere might be. Java is still a powerhouse, but it all worked out differently than I expected. Even in Java’s early years, before the Java news was filled with security bulletins, applets felt like a strange mix with their surrounding web pages. Creating an applet demanded programmers to build every detail. Even with Java’s ever-improving libraries, creating a Java applet that did much was an intense experience focused on programming.
Java wasn’t the only comprehensive way to build web apps, of course. Flash demanded programming, but its values always incorporated design, action, and well, flash, in ways that meshed well with the way people built sites. Flash kept growing and growing before its ecosystem took a fatal hit from the iPhone as HTML5 offered replacements for some of its key strengths. I mostly notice Flash these days because it asks me to update it regularly and because pages tell me when it’s crashed.
Compared to either of those rich environments, web technology is a tangled mess. The early web was functional but unstyled, with no behavior beyond navigating among pages. That? That would dominate client-side computing? Read more…
Site speed is essential to business success, yet many pages are getting bigger and slower.
Earlier this year, I was researching online consumer preferences for a client and discovered, somewhat unsurprisingly, that people expect web sites to be fast and responsive, particularly when they’re shopping. What did surprised me, however, were findings in Radware’s “State of the Union Report Spring 2014” (registration required) that showed web sites, on average, were becoming bigger in bytes and slower in response time every year. In fact, the average Alexa 1000 web page has grown from around 780KB and 86 resources in 2011 to more than 1.4MB and 99 resources by the time of the early “2014 State of the Union Winter Report.”
As an experiment, I measured the resources loaded for Amazon.com on my own computer: 2.6MB loaded with 252 requests!
This seemed so odd. Faster is more profitable, yet companies were actually building fatter and slower web sites. What was behind all these bytes? Had web development become so sophisticated that all the technology would bust the seams of the browser window? Read more…
A new mantra for your next (programming) meditation session.
You might feel fine.
Geeky Primer, Visible CSS, Remote Working, and Raspberry Pi Sentiment Server
Web Tooltips, Free Good Security Book, Netflix Economics, and Firewire Hackery
- toolbar — tooltips in jQuery, cf hint.css which is tooltips in CSS.
- Security Engineering — 2ed now available online for free. (via /r/netsec)
- Economics of Netflix’s $100M New Show (The Atlantic) — Up until now, Netflix’s strategy has involved paying content makers and distributors, like Disney and Epix, for streaming rights to their movies and TV shows. It turns out, however, the company is overpaying on a lot of those deals. […] [T]hese deals cost Netflix billions.
- Inception — a FireWire physical memory manipulation and hacking tool exploiting IEEE 1394 SBP-2 DMA. The tool can unlock (any password accepted) and escalate privileges to Administrator/root on almost* any powered on machine you have physical access to. The tool can attack over FireWire, Thunderbolt, ExpressCard, PC Card and any other PCI/PCIe interfaces. (via BoingBoing)