Category Archives: Javascript

Cache Rules Everything Around Me

By Chris Bartek

Are you getting a “merge conflict marker encountered” error when compiling a Node app? I ran into this issue for the first time recently, which was confusing as I had definitely fixed all previous merge conflicts, and could verify this by searching the codebase for “<<<<“, “>>>>“, “====” etc. and there were none to be found.

How is it encountering something that doesn’t exist, you ask? Beats me as to why, but when ghosts end up in the code I usually suspect the cache first.

So after trying several methods to clear out the issue, the one that seemed to work best was the following:

rm -Rf node_modules/.cache
(then yarn, then yarn start)

App booted up perfectly. Hope this helps somebody out there. I usually don’t come across caching issues in React apps but they sure are weird when they happen.

Leave a reply

Fantasy Healthcare

By Chris Bartek

I have an announcement to make: I placed 3rd in the Robert Wood Johnson foundation’s Games to Generate Data Challenge. I have been secretly working on this project for most of the year, and now that it’s over, I can talk about what I’ve been building.

Fantasy Healthcare is a game that allows friends (in the Wisconsin area for this version) to create their own healthcare provider dream team and pit it against other friends and players online. The provider data and provider names are 100% real, but the doctor/department names have been changed to protect the innocent. The idea is that players will better familiarize themselves with providers in the area, while also learning which providers perform best in certain areas.

The interesting part of all this is how it all got started. At my public sector job, I joined up with a group that was looking to enter the Games to Generate Data Challenge as a team, but alas, government red tape (and lawyers) prevented this from happening. However, since I was a contractor, I was able to take an idea of my own into the challenge and see how far it would get. It ended up being a good enough idea to place in the Top 5, so from there I developed the game on my own.

Fantasy Healthcare is written in HTML5, Canvas, CSS3, Javascript, jQuery, jQuery Mobile, PHP, and MySQL. The back end stuff runs on a Linux server. The Canvas stuff is also cross-compiled to native iOS and Android platforms for the efficiency and fast performance you expect from a game. I did it all myself, so considering I competed with some large teams and some big industry players, I guess I did pretty well for 3rd place.

So besides winning some nice prizes, I also got a trip to Boston to attend Games for Health, and a trip to the Health 2.0 Conference in San Jose to see the winner announcements. First off, Ben Sawyer’s Games for Health project in Boston was a wonderful experience, and I wish I were able to go again. There are really some amazing interactive ideas out there ready to transform the industry. As far as Health 2.0, I also had a great time hanging out in the Valley, drinking local brews and eating some In-N-Out Burger. The 1st and 2nd Place winners were totally deserving of their prizes, each having some fun-looking and interesting games, and I sincerely wish them all the best with their endeavors.

While I was in San Jose I got caught up in the government shutdown, but that’s a story for another time.

The Robert Wood Johnson Foundation and Health 2.0 are doing some wonderful things right now to provoke and promote bleeding edge ideas in the healthcare industry, so be sure to visit their challenge site.

What’s next for Fantasy Healthcare? I’d like to publish the apps and expand it to more cities. This will take some time I don’t have at the moment, though. In the meantime, it is available here for anyone to play with.

Leave a reply

The New Way to do Event Bubbling

By Chris Bartek

All Javascript developers should be familiar with event bubbling. For those of you who don’t know, event bubbling is when DOM events move up the chain from bottom to top. In other words, if you click on a <li>, the <body> will get clicked first, then the <ul>, then the <li>. In IE, of course, it does the exact opposite (“event capturing”), but with the advent of jQuery, this is pretty much a moot point.

So why is it important to know? Well, imagine you’ve attached a click event to an <li>. It may not be a problem now, but if your <ul> ends up with thousands of <li>s, you’ve got thousands of bindings in the DOM, which is going to be a performance killer among other things. Instead, simply attach the click event to the <ul>, then inside the event, figure out what <li> got clicked on and react accordingly.

By the way, this is an interview question for every Javascript-related job ever. Know what it is and why it’s important.

I was going to post a simple example on how to do this, but apparently this is entirely the point of jQuery’s new “on” method. I use “on” all the time, and you should too, and if you are still using “delegate” or the dreaded “live” to bind events dynamically, you should start using “on” instead. So anyway, here is how to use “on” to efficiently bubble events:

$('ul').on('click','li', function(evt){
alert("cream cheese");
});

What this code is doing is binding to the <ul>, but only firing the callback if a child <li> node was targeted. I’ve always used $(document).on as a force of habit, but really you should be using the parent of the object you want to bind to. Folks, it doesn’t get any simpler than this. Sure wish I understood this months ago….

Leave a reply

Project Workflow for Lone Developers

By Chris Bartek

I’m not ashamed to admit I’m a designer-developer hybrid. I worked as a graphic and web designer for several years. I did back end development professionally for 4 years. I’ve done UX development professionally for 3 years. I love design and I love coding, and I love doing both at the same time. So it’s not uncommon for me to build entire web applications by myself. This practice gets a bad rap because developers are typically awful designers, and vice-versa, but for me it comes naturally.

I’ve been designing since age 6 and programming since age 11, and never quite knew how I could merge those talents. Since kindergarten, everyone always told me I would grow up to be an artist, but I wanted to be a programmer. Once the time came when I needed to choose a major, I chickened out at the last minute and chose multimedia (I hated math and still do). Back in 2001, CD-ROMs and VB were king, and Director and Flash were still in their heyday. That was how you built interactive applications. But slowly, web and mobile took over this space, and bridged the gap between design and development. I was lucky to be caught in the middle of that merge.

Throughout the years, I’ve typically been unmanaged throughout the web development process, since the stuff I do is usually highly experimental. Because of this, I’ve developed and refined my own process for development that seems to work great for me. Your mileage may vary, but I’ve found this workflow to be the winning combination, especially for projects where I’m going it solo.

Lone Developer Workflow

  1. “Liveframing”, what I call wireframing with HTML. Create a preliminary GUI with no design, just basic structure. I prefer this to wireframing in most cases… honestly, I’ve never been a fan of wireframing tools, and I avoid them whenever possible. It depends on the project though.
  2. Mockup. Based on your liveframe, use Photoshop to design what the final website will look like. You want to throw a bone to the client to keep them busy awhile, but you also want to put a vision in your head of what you’re working towards.
  3. Database schema. This is the third thing I usually do, for two reasons. One, after building the GUI I have a pretty good idea of what data I’m collecting and how it will be used, and second, I want to do this before starting on the back end. I usually use Excel or pen and paper to draft a schema, and then build the actual tables as I need them. The schema will always change from start to finish, but usually I nail it with 90% accuracy. And usually, I end up needing fewer tables than I had originally schemed.
  4. Back end development. Once I have a barebones liveframe and a schema, I’m ready to start back end development. Of course I start in the planning stages, figuring out which pages do what, how the API will work, .htaccess considerations, etc. and generally decide how communications will be coded. Communication formats will also be decided in this stage (XML vs JSON, data structure, REST considerations, etc.). Then, I start coding, and hook the liveframe up to the code as I go for testing purposes.
  5. UX development. I start elaborating on the liveframe by adding the necessary Javascript and jQuery.
  6. Test, test, test. As I move through my prototype on the front and back, I add or modify decisions for both sides. The pieces slowly come together. The client should be engaged during this time to verify the project is functioning under the proper requirements.
  7. Once the project is 90% solid, then I start slicing the front end. The liveframe’s header, footer, and CSS will be replaced with the new design, and if you did it right, it should pop right in.
  8. Beta and QA testing. This is probably something you don’t want to do yourself. Find friends willing to test it out.
Leave a reply

Let’s Talk about Pre-Processors Like it’s 2010

By Chris Bartek

Reading some of my past entries, you’d think I hate pre-processors or something. Well, that’s not quite right. Setting aside the obvious (PHP, etc.), I want to have a quick discussion on the pre-processors that have been popular over the last few years, and my take on them.

SASS & LESS
Great ideas, but pretty much the same thing. They don’t offer any real benefit over old-school CSS for small projects, but they’re certainly useful for the larger ones. But you know what’s better? Stylus. Stylus seems to take the whole idea a step further with the whitespace syntax.

CoffeeScript
Mixed feelings. I used it on a project recently, and while I love how easy it makes OOP and the syntax is lovely compared to the mess that is Javascript, it seemed to have a few frustrating quirks, and whitespace syntax is not always your friend. But then again, it beats getting lost in the “});});” forest. Debugging can quickly become frustrating as well.

HAML
I won’t lie, I can’t stand HAML. I want to like it, but the fact is HTML, like XML, is incredibly well suited for, well, markup. Here is an example of the number one reason HAML drives me nuts:

HTML
<span class="test">this</span> <strong>is <a href="test/" target="_blank">a</a></strong> <em>test</em>

HAML
%span.test this
%strong
  is
  %a{:href => "test/", :target => "_blank"} a
%em test

…so what happened here? Well, I traded a simple, common line of text for a mess of carriage returns, indents, hashrockets, and… colons? why?… and at the same time made it more difficult to read. I saved 20 characters, but at the expense of readability, and I made my brain hurt. HTML. Isn’t. A. Programming. Language. The verbosity of XML serves its purpose, like it or not. Although like everyone else these days I use JSON over XML most of the time, when you are dealing with lots of inline data, it makes more sense to use XML instead. Repetition and verbosity != not readable. This just doesn’t seem like the solution to any kind of problem HTML might have had. A better solution? Stick with HTML, and for templating, use mustache.js (the only Javascript-based templating engine that doesn’t suck, in my opinion).

Oh, and if I ever said anything mean about Node.js, I take it back. Without that, none of this would be possible. 🙂

Leave a reply

Presenting my latest project, SoulTrade

By Chris Bartek

As you might have guessed, I’ve been working on another app these past few weeks. This represents only 2 weeks of work, so overall I’m okay with how it turned out. Without further ado, I present:
SoulTrade (soultra.de)
(available for iOS and Android!)

What is SoulTrade? It’s a market for buying and selling souls, basically. Yeah I know, it’s a pretty stupid idea, but I mostly just wanted to flex my design and development muscles with some of my free time. I really didn’t care what the website did, as long as I got to use PHP/MySQL/jQuery/Javascript/HTML5/CSS3. So ironically, this project really has no soul, heh.

Technical details: SoulTrade was written by me in 2-3 weeks with a PHP/MySQL back end using my own framework. The front end was designed by me in Photoshop and Dreamweaver, and of course utilizes HTML5/CSS3/Javascript/jQuery. The website is running on a LAMP stack, while the mobile version is using jQuery Mobile and Phonegap.

Enjoy.

…mwahahaha….

Leave a reply

Custom Accordion Snippet using jQuery

By Chris Bartek

Whenever I’ve built my own accordion script in jQuery, it’s always had the same problem: when you click on the collapsible that’s already open, it closes itself, then immediately reopens. Looking for alternative accordion scripts, I’ve noticed everyone else’s seems to have the same problem, so I came up with a deliciously simple way to solve it.

First, a little background. The reason this is happening is completely logical and due to the synchronous nature of jQuery animation. The way most developers go about their accordions is to make sure all others are closed, then open the requested accordion. This method works great unless you want to be able to close an accordion. Without further ado, here’s the easy solution:

HTML:
<div>
<h2>First</h2>
<p>Content</p>
</div>
<div>
<h2>Second</h2>
<p>Content</p>
</div>

Javascript:
$(document).on('click', '.collapsible h2', function(evt){
$(this).addClass('clicked');
$('.collapsible h2:not(.clicked)').removeClass('selected').next().slideUp(500);
if($(this).hasClass('selected')){
$(this).removeClass('selected').next().slideUp(500);
} else {
$(this).addClass('selected').next().slideDown(500);
}
$('.collapsible h2').removeClass('clicked');
});

Easy, right? Embarrassingly so. But I didn’t see any good examples online, so here you are.

Update 4/10: Fixed a bug in the :not selection.

Leave a reply

Opera Adopting WebKit and Why it Sucks

By Chris Bartek

Everyone who knows me, knows I’m an Opera fanatic. I’ve been using it for 13 years or so, actually. We had some great times over the years… tabbed browsing years before Mozilla copied it. Mouse gestures and easy keyboard navigation. Incredibly fast rendering. Session saving. Security. Stability. I could count on one hand the amount of times its crashed on me over the years (and 90% of it had to do with MSNBC’s old website — I can only hope they fired their UX guy). Admittedly, Opera has been slacking off with standards implementation lately, but it’s not exactly show-stopping stuff.

So why are they ditching Presto in favor of WebKit? I guess they just don’t have the money to keep moving in that direction, especially with the WebGL stuff that complicates future implementation. It’s a sad situation though, and makes me wonder how long until Firefox and IE follow suit. “But wouldn’t it be a perfect world with one rendering engine?” Well, yes and no. This happened once, remember IE6? If you wanted the Internet to work, you had to use that browser. But things weren’t so great… standards were lacking to say the least. New standards stagnated, and Flash workarounds became prevalent. But hey, it was the only browser in town, until Firefox. So if all browsers went to WebKit… not only would it be IE6 all over again, but the WebKit code would probably get forked all over the place anyway and defeat the purpose. You’d just end up with arguments over the direction of the project, and the end result would be WebKit, MozKit, ChromeKit, and IEKit. Hey, it’s happened once before.

I like WebKit, but I don’t love it. I’ve tried to love her, honestly I have, but she’s just not my type. The Javascript API implementation is very nonstandard and IE-ish. Stability seems lacking (might be due to the multi-threading?). Flash barely works (Chrome and Safari need to stop blaming Flash for their browser crashes; other browsers don’t have these problems). It’s slow. To be fair, maybe these are just problems with Chrome and Safari, and not necessarily WebKit. When I was loading up my netbook awhile back and deciding on a browser, I went with Chrome, and for 3 months I gave it a chance. It was excruciatingly slow. It crashed a lot. I figured it was because it was an underpowered netbook, so I didn’t think Opera would work any better if I installed it, but thankfully I was wrong. It made the Internet tolerable again. It’s going to be really lame if I have to start using IE9 instead of WebKit — and worse — if IE9 turns out to be a better browser than Chrome.

Presto was the little engine that could. Blindingly fast, incredibly stable. It’s just sad Opera never let it live up to what it could have been, or rather what it was, a standards-compliant powerhouse that shamed all other browsers. Why did they let it fall behind? Why don’t they open-source Presto and let the community improve it? Why just piggyback on WebKit?

I know I’m rambling. I’m not happy about this, but I wish Opera the best of luck in their implementation. Perhaps they’ll do a better job than Google, at least.

Leave a reply

jQuery Image Slideshow

By Chris Bartek

Ever wanted or needed to make a slideshow system like you see on news websites? Here is a simple HTML/CSS/jQuery template to help give you a jumpstart. Here are some of the features:

– JSON-based input
– will handle a mixture of horizontal and vertical images of any size
– image descriptions can contain HTML tags
– navigate slides using buttons or arrow keys
– view and jump to slides visually
– automatic advance button
– shows thumbnails when hovering over slide buttons
– responsive layout (for mobile and iframe widgets. Non CSS3-based so it works in IE7 and 8)
– tested in IE8, FF, Chrome, Opera
– lightweight and easy to modify

I started working on a fullscreen mode for it, but got frustrated with the spotty browser support. I hope to eventually come back to that feature… but at any rate, here it is in 1.0 form. You can use it in your projects, but if it’s commercial, be nice and put me in the credits.

(DOWNLOAD COMING SOON…)

Leave a reply

MVVM Frameworks versus Unobtrusive Javascript

By Chris Bartek

So this has been bothering me, and maybe I’m underthinking this, but doesn’t it seem like Javascript frameworks these days are not only breaking the unobtrusive scripting mantra, but also breaking MVC? Example from knockout.js’s website:

knockout

Why on Earth would it be a good idea to “encapsulate data and behavior into a view model”, as their website suggests? Well, to “get a clean, extensible foundation on which to build sophisticated UIs without getting lost in a tangle of event handlers and manual DOM updates.” I’m really on the fence about this. While I’ve always suspected MVC can sometimes complicate development and refactoring, these days I live by unobtrusive scripting. HTML holds your structure. CSS holds your stylesheet. JS holds your business logic. SQL, JSON, XML, etc. hold your data. Why mix and match all that crap in your HTML file? Just because you can, doesn’t mean it’s a good idea, that’s why we all stopped doing that method years ago. And it’s not just Knockout doing this, it’s nearly every framework these days.

So to be fair, there are definitely arguments in some cases against MVC. Likewise, there are arguments against unobtrusive Javascript. For instance, jQuery event handlers can be used irresponsibly and make it easy for your designers to screw up the logic by renaming a class or restructuring the tag hierarchy. I’m definitely familiar with this. And with MVC, I can see the advantages of forsaking it in the backend for some projects since it’s often times building the view itself based on logic. However, in the case of Javascript, your view has already been generated so I fail to really see the benefit of decoupling them.

What is the best way to go about this problem? Honestly, we can chase our tails on MVC and UJ for another decade, but I think the only way to solve this is with smarter IDEs. Can you get “lost in a tangle of event handlers”? Sure, I guess. But you can also get lost in a tangle of MVVM… as a veteran of the “onclick=” era, you can trust me on that. We should demand a web development IDE that makes it easy to manage event handlers and functions, representing them visually in some fashion, and linking them to objects from the HTML side so we can instantly see what logic is attached to them. Then we won’t have to wade through tons of text files to locate what we want. This is the year 2013, why do we continue to pretend this problem doesn’t exist or doesn’t need to be solved?

I don’t mean to sound all negative; modern Javascript frameworks can do some cool stuff… automatic DOM updating, templating, ease of code generation from the backend, etc…. so for some projects, this is absolutely wonderful and perhaps merited, but honestly I can’t think of an everyday use for them that wouldn’t make things needlessly complicated. jQuery forever changed the way we code… it’s a great general-purpose framework that makes it easy to do event handlers and DOM updates, so in a way, doesn’t that already solve the problems that MVVM frameworks are trying to “re-solve”?

In closing, some of these MVVM Javascript frameworks infuriate me and make me want to develop my own cleaner, friendlier framework or IDE. It also makes me reflect on previous posts suggesting that we might be regressing back into 90’s web development; now I’m starting to think it really is happening.

Leave a reply