Skip to main content

SimpleYUI, thoughts on NodeJS development

I've been a huge fan of YUI for a few years, even back when they were named YUI-Ext. Recently, they rolled out SimpleYUI. When asking other web developers why they don't like YUI, they say, "their package system is too complicated" or "you can't just start accessing the DOM by including the library easily". Incidentally, back in the day, it was far worse--YUI didn't even have a selector engine until they ported someone else's into YAHOO.util.Selector (remember this guy?). This design flaw in the library is probably what cost them in terms of people adopting YUI. As a developer, you want a consistent way of doing the most common things (dom access).

Back in the day, you would have to call YAHOO.util.Dom.get(element or string for ID of element). This was terrible because they introduced YAHOO.util.Selector.query(cssSelector) right after and soon developers were choosing between fetching DOM elements by selector or by ID. MooTools has the same problem but separates it in $() versus $$(). How about jQuery? $(cssSelector or element). Everything is passed as a css selector or a DOM element and it stays consistent through $(). I am certainly glad that they have aligned towards having a consistent API for fetching DOM elements. At my last job, some projects were using the old YAHOO.util.Dom.get('') and some projects had YAHOO.util.Selector.query(). With SimpleYUI, you're able to get the simplicity of how you're using jQuery but you also get the power of swapping back to using YUI's powerful packages.

NodeJS: why you should jumping in to help bring NodeJS into the production-ready realm


When people ask me about whether we should adopt NodeJS into a production-level deploy, I have to state the clear and obvious answer: no, it isn't proven yet and we would burn too much budget trying to seek the answers that haven't been answered yet.

Every single time I say that exact sentence a part of me gets disheartened. Why? Because saying "no" to it is the most responsible thing to say if you're a technology leader. What happens when your project goes overbudget because you didn't have the technical skill set to handle this new technology? You get blamed for trying to push it into production.

I understand that it is new and unproven; so the question is: what can I do to ensure that NodeJS can be fully integrated into production deployments (big builds or small builds). I have been asking myself this for quite some time now and I find it way too easy for someone to disapprove of NodeJS because of how unproven it is; so the best thing to do for the NodeJS community would be the following:

1) More Node Knockout tournaments (I've showed this off to my coworkers and they are highly impressed with the apps developed)
2) More technical writers and video producers (viral video for how to setup your website in 5 mins on Node)
3) More web hosting solutions than just Joyent/Heroku/Linode, let people start creating sites on top of a solid backend!
4) More enterprise solutions, such as, application server replacements like JBoss

The most exciting part about NodeJS isn't the fact that we can move towards fast real-time web applications, or the fact that you can scale out to more users with less hardware--it's the fact that it has never been done before. Furthermore, having Javascript run on the front-end and the back-end is the most exciting part about NodeJS development; if you find yourself without a challenge, try NodeJS out!

Incidentally, after watching Douglas Crockford's Loopage talk, he said, "That's why software development is so slow, you basically have to wait for a generation to die off before you can get critical mass on the next great idea" and "We're about to take maybe the most important step we've ever taken in terms of the technology fo the web and Javascript is leading the way. Who would ever imagine that? Javascript is the technology leader, it's not just the thing we tolerate." Such an inspiring speech by Douglas Crockford. That said, my passion for advancing software development has been lit once again. Good stuff will be coming out in the near future! Believe it!

Good luck and have fun,
Jaime Bueza

Jaime Bueza is a software developer in Vancouver, British Columbia, Canada. He has developed web applications for Nintendo, Electronic Arts, Ritchie Brothers, Kiwi Collections, and Cox Communications. When he's not developing useful software that constantly evolves with business requirements, he's creating tutorial videos for aspiring front-end developers.
Post a Comment

Popular posts from this blog

TextMate Tutorial: How to add a Strikethrough keybind to your Markdown bundle

Markdown is awesome for quickly generating Readme's on Github. After looking at other projects using the strike tag, I've decided to create a custom keybind for it in my TextMate Markdown bundle. Here's how:

1) Click the + sign on the bottom left and click New Command.
2) Paste this into the editbox and make sure you name your command "Strikethrough".

For the input field, select WORD in the drop down.
For the output field, select "insert as snippet".
As for the keybind, you can totally map it to whatever you're comfortable with but I chose Command-D as it is the same thing in Microsoft Word.

Cheers,
Jaime

Using Git Hooks: Prepare Commit Message to automatically prepend branch names on commit messages

When you're practicing branch by feature with distributed version control, typically you'll get assigned a ticket or issue and that ends up being your feature branch. Instead of always typing in the branch name in every commit, you can edit your Git hooks (specifically prepare-commit-msg).

Assuming that this is a brand new git repository:

mv .git/hooks/prepare-commit-msg.sample .git/hooks/prepare-commit-msg
vi .git/hooks/prepare-commit-msg

Edit the file by commenting out what was originally in the file and then add this:



Now, whenever you make a commit, it should show up like this in the log:



Since GitHub and Bitbucket both support Emojis inside commit messages, you can do something cute like this



Want more emojis? check out the Emoji Mardown Cheatsheet!

NodeJS Hack Session: MMO Pokemon with NodeJS/WebSockets

The primary focus of this proof of concept is to determine how easy it is to build real-time web applications for all iPad, iPhone, droids, Safari, Chrome users on top of NodeJS (non-blocking event driven server side Javascript platform). The proof of concept was built within 6-8 hours including the following:

Uses Express framework for server side Javascript development (inspired by Rails / Sinatra / Django)Uses EJS for templating language (much like Django templates and symfony) -- allows partials and passing parameters into partials like symfony PHPReal-time chat using WebSocketsArena Queueing System for real-time competitive matchplay using WebSocketsHTML5 AudioCSS3 transitions for all hand cards, tappable cards, transparent panels, rounded corners, drop shadowsFallbacks for Firefox, IEFirefox/IE will fall back to Flash socketIE will fall back to XHR long poll if the user doesn't have Flash installedNoSQL CouchDB for fetching users and soon cards, achievements, friend associat…