Everybody’s Talkin’ ’bout the New Sound

By Chris Bartek

Not too long ago I had the displeasure of using Smarty in a PHP project for a major client. You’re probably wondering what the heck anyone would be using Smarty for in 2012… well, lots of turnkey systems (shopping carts, CMS, etc.) built from 2007-2010 use all sorts of templating engines, but Smarty, at the time, was definitely the most popular. These days, I guess PHP developers have wised up to what I had been saying for years, since you don’t really see these things being used anymore. Old-school templating engines had many obvious problems that nobody really thought of, while they were busy worshipping the concept of model-view separation. Don’t get me wrong, there’s nothing inherently wrong with this line of thinking, but… why did this seem to always necessitate the creation of an entirely new programming language? Did the Smarty people forget that PHP itself is already an amazing text processing language, and doesn’t really need an additional templating language written on top of it? To be fair, there are some nice templating engines out these days that use PHP itself as a templating engine, but honestly with good development practices, you can adequately MVC your way through a project without the need for a templating engine. If it scares your designers, then hire new ones. So anyway, the team got together and we basically all said, “is it just me, or is Smarty, well, stupid?” Unfortunately, we were stuck with it, so it didn’t matter that the development team loathed it.

I believe that templating system fiasco of yesteryear serves to prove an important point: the web development fads of today may or may not be the practice of tomorrow. It’s incredibly important that you don’t unnecessarily tie up thousands or millions into a project because it “has to be done in Node.js-SproutCore-Backbone-ExtJS-Coffeescript-SASS-HAML-960gs-Bootstrap-NoSQL”, or whatever bleeding edge technology stack of the week. It might be the hipster CTO thing to do, but keep in mind: some of these technologies may be keepers, but half of these technologies will be long forgotten in 3 years, and one or two of these will make your new programmers laugh, then hard-time you until you pay them to rewrite it in something more sensible. There’s a reason Java, .NET, and PHP continue to thrive, while stuff like Python and Rails seem to have peaked last year could be going the way of Perl and Tcl/Tk. They’re proven scalable, they have support of millions of developers, they have robust libraries already written basically everything, and they are used by the largest sites on the web. They may all be sugarless, downright ugly languages, but heck if they don’t get the job done everytime. I’m not saying all new technology is bad, obviously. Lots of amazing stuff has been popping up lately, but it doesn’t mean I’m going to rush out and use some unproven technology on a Fortune 500 company’s project, though I might experiment in certain places. There’s doing the cool thing, and there’s doing the smart thing. And yeah, I know it’s scary to use the “old way” on new websites sometimes, but I’ve certainly seen my share of situations where the old way was apparently done that way for a reason. Hopefully this doesn’t make me sound like a cranky old person afraid of change, because that’s not at all what I’m trying to convey, heh.

Leave a reply

The Future of Software Development

By Chris Bartek

I have a dream. A dream that one day, we will remove the shackles of syntax. We will stop living in the punchcard era of programming. Object-oriented will really mean visual on-screen manifestations, not junk compartmentalized in curly braces. We will stop putting the security of our computers at risk by programming everything in low-level languages. We will stop trying to abstract low-level and high-level languages by creating yet more complicated languages. We will stop using those scripting languages that function like they were created by aliens. We will give up on static typed variables, pointers, and other memory management concepts unnecessary in the 21st century. We will end the possibility of buffer overflows. We will stop the compiler errors. We will end the garbage strike. We will revolt against the Hungarians. We will stop using camels, and instead use spaces. We won’t have to memorize or rely on autocomplete. We will put logic together visually, instead of just typing code. We will truly collaborate in realtime, instead of merging and versioning. We will develop on web browsers, in the cloud. We will develop easily on a touchscreen; the keyboard won’t hold us back. We will stop writing the same code over and over again, and instead make others’ libraries easy to use and share. We will separate programming languages from software development. We will stop worrying about MVC and instead ask why the separation isn’t natural. We will bestow the power of development to frontend designers who are worthy. We will stop worrying about which language is ugly or pretty, and instead worry about why we even need languages. We will stop making programming more difficult than it needs to be. We will stop over-engineering software and go back to the KISS rule, like designers have already figured out. We will stop celebrating “clever” solutions that no other programmer understands. We will make code read more like a flowchart, and less like ASCII vomit. We will stop creating bugs and memory leaks. We will make software impossible to freeze and crash. We will modularize visually. We will create development environments so abstracted from code, it will make Python look like Assembly. We will stop creating hundreds of languages that keep failing to make our jobs easier. We will finally merge the desktop and web. We will make programming so accessible, anybody can do it. We will stop working in cubicles and instead work from the cloud. We will merge design and development. We will make programming an art again. We will make programming cool again, and not just for analytical, lispy grumps with Aspergers. We will end the seemingly endless best practices arguments. We will abolish tabs, semicolons, and braces. By the end of the decade, we need to make this happen. We must be the last developers that ever have to suffer under 1950s programming paradigms. We will go free. We MUST go free.

Flame on, lispy grumps. 🙂

Leave a reply

Javascript CDNs: A Ticking Timebomb

By Chris Bartek

Sorry for the mainstream media headline, but the truth hurts. Javascript CDNs are dangerous and want to harm your grandparents, your kids, and your little dog too. What do I mean by this? Well, let’s look at the advantages and disadvantages:

Advantages:

  1. Potential to sometimes make your website load slightly faster

Disadvantages:

  1. Potential to make your website take longer to load
  2. Potential to prevent your website from loading
  3. Complete reliance on external servers (single point of failure)
  4. Many popular CDNs do not use optimal cache control settings
  5. SSL introduces ethical issues

So let’s look at the first one. the CDN can make your script load faster. It can make it run slower. Consider the odds of the user already having the script. What do you think the chances are of that user having already specifically downloaded, for instance, jquery.min.js v1.7.2? It’s probably safe to assume less than 50% for the average user, right? So then we should all use jquery.latest right? Ha, no. NEVER trust the latest version of jQuery; I speak from firsthand experience. Also consider, if the user does NOT have that version of jQuery, it will have to connect to an external server, and thus will take longer to download than if it were local.

Second, the potential to break your website if the CDN doesn’t connect, or gets hacked. Don’t say “that’s Google’s server, it’ll never happen!” It can, and it does. It’s not a question of if it will happen, but when. And when it happens, a lot of websites are gonna go down for putting too much trust in the cloud. On top of that, some places have a ban on Google domains (such as some schools, workplaces, and entire countries). I’ve seen this happen in the past, and had to stop using CDNs in K-12 educational projects.

Third, reliance on external servers. You are introducing a single point of failure by using a CDN-hosted script. Luckily, there is a way around this; have a local fallback in place. However, this can introduce problems when trying to test your website locally.

Fourth, CDNs don’t generally cache like you think they would. You’d think they’d cache a solid version of jQuery for a week or month, since it’s highly unlikely it’ll change. As far as I can tell, they only cache for days or hours. Does this not defeat the purpose of a Javascript CDN? I think it does.

And finally, SSL. When someone connects to your website via SSL, they are entrusting you not to communicate their requests with remote servers. You are essentially breaking their trust by using a CDN. It may not be a big deal to me and you, but to some users it is.

I have to admit, I’ve been using Javascript CDNs blindly for years now, and only recently did I begin to question whether the effort was worth it. When you do the math, honestly it doesn’t look like it is. Are we really willing to put our eggs in other baskets to save 15kb? Does the potential savings in loading time have enough of an impact to positively affect the user? Are the odds in the user’s favor at all? Ask yourself these questions, and you might be surprised you’ve been living in the cloud computing matrix, and this stuff about CDNs making things faster is irresponsible marketing at best, dangerous at worst. Am I onto something, or am I just being an idiot?

Leave a reply

Thoughts on Flash

By Chris Bartek

Yeah, I know I’m a little late to this discussion.

It’s been two and a half years since the famous Steve Jobs letter, and the web has definitely seen some changes because of it. jQuery has replaced most of the incidental interactive uses of Flash. Many canvas IDEs have started popping up on the market, though many are in their infancy. Video and audio tags have become popular fallbacks for Flash video, though they have not replaced Flash due to H.264, MP3, and IE8. Some tools, like Google Swiffy, exist to help facilitate the conversion of assets from Flash to HTML5, though they are slow and rudimentary. IE9 marks the return of Microsoft finally taking web standards seriously. Nearly all games are still made in Flash, but everything else has seen a significant drop in Flash use.

Bottom line on all this? HTML5, as a Flash replacement, has gained some real momentum, but it is still woefully lacking in most ways. A/V tags have caught on as fallbacks only, if at all, due to the standard’s inability to support DRM technologies and fullscreen modes, as well as the spotty format implementations that cause some serious production considerations. jQuery, though a great replacement in many ways, lacks a lot of the advanced keyframing, masking, 3D, etc. that really made Flash captivating. Canvas, though growing by leaps and bounds in Webkit, is still unsuitably slow in most web browsers and mobile devices, often incapable of a consistent 30fps for games that would easily get 300fps in Flash. The latter begs the question: is the V8 Javascript runtime the savior of HTML5 like we think it is, or is there still more work to be done? A lot more?

Here’s a real world scenario for you. You have a client with an animation and video-intensive project for you. They want it to run on IE8, Firefox, and iPad, among others. Simple, right? Well, no. here’s the situation. IE8 has no canvas support. iPad has no Flash support. What technology do you use to create the animations, and what technology do you use to play them? Guess what, I’m faced with this problem right now, and many others have also. The answer usually ends up being, you can’t use animation, and you have to double up on video formats. For this particular project, not using animation wasn’t an option, so the solution we came up with was: Flash as an animation IDE. Swiffy to create HTML5 fallbacks. Flash and H.264 for video, canvas as a fallback, Flash as the fallback-fallback for absence of H.264 support. Why is this so stupidly complicated for such a simple thing? Microsoft and Apple, that’s why.

As much as I dislike Flash, I don’t really see it going away anytime soon. More like what happened to Java applets; you see fewer and fewer as better technologies become more capable of replacing it (Flash). This is already happening with Flash, but Flash is still a lot more suited for certain projects at this time. Just off the top of my head, here are a few pointers canvas could learn from Flash:

  1. IDE is king. Flash is two things: a runtime plugin technology, and a development environment. Canvas currently has no de-facto, and what is available is not fully-baked yet. Creating animations in Flash was so easy. In canvas, it usually means a Javascript nightmare to get something awful-looking.
  2. Sub-pixel accuracy. This was in Flash from the start, and so well-integrated it was a little annoying. But useful. Maybe this can be done in WebGL at some point, but right now I don’t think it’s possible.
  3. Speed. Really, this should be at the top of the list. Speed, people. Get it together. We want fast frame rates. No tearing. No lag. No major browser inconsistencies. If there’s a problem with Javascript, then it needs to be solved.
  4. DRM. Sure Javascript can be obfuscated, but there needs to be ways to protect media from getting jacked, if so chosen. This is easier said than done with the way the internet works, and I’m aware of that, but it would be nice.
  5. Asset containment. It would be nice to be able to shove all data into a single binary, instead of having PNGs, MP3s, etc. scattered all over your server and needing to be downloaded individually. Maybe the canvas IDEs of the future will have the option of base64’ing everything, but that may make the problem worse (filesize and whatnot).
  6. A/V synchronization. Flash can be easily synced so that animation and music don’t go rogue. Also, ways to read audio levels to make interactive queues, and ways of generating custom audio during runtime. Not sure if there’s a way to do any of this in canvas. Doubt it.
  7. 3D. Okay, so WebGL. The other browsers need to get with it, because Flash seems to be years ahead on this. How it will compare to Flash remains to be seen.
  8. A common binary runtime. This is the only way canvas will ever be nearly as fast as Flash. Right now, your runtimes have to be written in Javascript. Every IDE has their own. What if there was a binary runtime to hook into, that every browser supported? Oh wait, I guess that’s what Flash is, and what canvas will never be. Heh.
  9. Compatibility. Not really canvas’s fault, but not even half the web supports canvas. IE8 and below, plus mobile devices are still far behind… and when they do support canvas, they’re too slow. Flash, even if its mobile forray was short-lived, at least had a faster implementation than canvas.
  10. Camera and microphone support. Seems like Chrome might implement some of this, but as far as I know there are no common APIs for this like there are with GPS.

And I could go on. Some of it is nitpicky, I know, but a lot of it is incredibly important to designers and animators.

Bottom line, it’s unfortunate that the late Steve Jobs felt it necessary to start a war over two technologies that aren’t necessarily mutually exclusive. In a way, I’m glad Flash has gone back to what it’s supposed to be (a runtime for when performance, presentation, compatibility, and heavy dependence on animation and object-oriented programming), but it saddens me a little to see the web step a few years back in time, in order to bend over backwards for mobile devices. The result seems to be that the web is a more boring place, and canvas so far has failed to solve the basic problems it claimed it would.

Here’s how I see the future. Eventually, Adobe will make Flash capable of compiling to canvas directly. That way, canvas will be available as a fallback for when Flash isn’t available. If that doesn’t happen, eventually converters will get better, or Adobe will come up with a new IDE. And no, I’m not talking about Edge, Hype, or Muse. Please, Adobe, no more garbage toys; give us what we want. But anyway. At any rate, we’ll likely continue down the path of Flash really finding its niche, and browsers continuing to offer no real solutions to canvas’s shortcomings.

Leave a reply

Your Favorite CSS Grid System is Garbage

By Chris Bartek

There. I said it.

Like most designers, I started tinkering with grid systems such as the mysteriously popular 960.gs back in 2011, and early on, I felt like there was something deeply wrong with the whole concept. For starters, semantics. With all these systems asking us to place all these bazillion class names all over our HTML, surely we’ve all stopped and scratched our heads any wondered why we ever crawled out of the primordial ooze of table-based layouts, only to let CSS devolve back into the very thing we hated (merge of layout and content). Let’s not kid ourselves, this code is not clean, and it’s not semantic. Try to work it into a responsive layout, and you’ll really see what I mean.

Which brings me to the other problems: most of these grid systems lack responsiveness, or heck, some even lack basic fluid capabilities. Sure you can shoehorn it in, maybe, but then your class names will suddenly make even less sense than before. If these CSS grids are the future of web design, maybe I’ll just go back to tables, heh. All they seem to do is make your code less sensical, your layout less flexible, and for what, exactly? To bring us back to the glory days of rowspan and colspan? Ladies and gentleman, Photoshop is your friend. Set up your columns in your mockups, slice from there, and you’ll have nothing to fear. Stop treating design like it’s programming.

Okay, so I’m oversimplifying things, haha. To be fair, CSS grids are a good solution for certain projects. Form-heavy sites. Heavily CMS-generated sites. Sites that won’t need much mobile treatment (or have a separate solution like jQuery Mobile). And also, I haven’t mentioned this yet, but there is a light shining in the distance… from the darkness, a new era of CSS frameworks has emerged, and I rather like it. Of course, I’m talking about Semantic.gs.

If you haven’t heard of this yet… take a look. Semantic. Responsive. Fluid. I was blown away. The secret is they’re using LESS, etc. to do the heavy lifting, and the end result is surprisingly tolerable. I… wow… I *like* this solution. The CSS preprocessor requirement, of course, has advantages and disadvantages on its own, but if your next project is suitable of using LESS / SCSS / SASS / Compass / Stylus / CSSPreprocessorFlavorOfTheWeek or is already using it, give Semantic.gs a try (if it supports your preprocessor). She’s pretty and smart… not like all the other girls.

I’ve also noticed Twitter Bootstrap is attempting something similar, but it’s, well, just like everything in Bootstrap, the implementation is too vanilla and inflexible. That’s right; I went there.

Leave a reply