Clint Hill

Father, Son, Brother, Uncle

Category: JavaScript

July 23, 2011

Next Exciting Thought Exercise

At work and personally my next new shiny thing is the design of a framework for delivering JavaScript applications. It’s more than building modules, listing them in a gallery and then HOWTO documents, rather a top-to-bottom application UX delivery system.

This is more tricky than might be imagined. It’s a gallery of modules. It’s a development environment. It’s a hosting environment. It’s a core library. And not always in this order.

It’s exciting stuff to think about. And it’s really cool to think about doing it with JavaScript (client and server sides). A few things that cause concern are the definitions of things.

  • What is a module?
  • What is a component?
  • Is there a difference?
  • Or are components applications?
  • What does “development environment” mean?
  • Does hosting mean you get what you get or does it mean you can get what you want?

It’s answers to these questions that are critical in designing a system like this.

Fun stuff.

Leave a comment
July 4, 2011

Software Abstractions

Abstrations are hard to debug, require a learning curve of 2x the original problem and are rarely complete.

chrisjsmith

This was part of a comment left on Hacker News to a post about Coffeekup. Coffeekup is a CoffeeScript abstraction over HTML. Just like HAML. The beauty of the comment is how concise it is to the real problem with abstractions.

Abstractions are key to developing good software libraries. They are shortcuts for what otherwise might be lines and lines of code. The jQuery JavaScript library is a great abstraction over JavaScript. It takes what would be tons of “document.querySelectorAll(‘selector’)” kinds of code and distills it down to “$(‘selector’)”. This is a good abstraction because it’s JavaScript over JavaScript.

And in many cases developers will build libraries of abstractions in the name of “platform”. That is to say that you can create a platform for building software based on a frameworks full of these kinds of abstractions. An example might be to use Google Web Toolkit to build web pages which would allow you to write “everything” in Java, and compile it down to JavaScript.

The quote points out why this is not always the best solution. The reason is simple: It’s Java over JavaScript. Right away the learning curve is 2x the original problem. What you may not be familiar with in JavaScript may only loosely compare in Java due to differences in language. It is much harder to debug – regardless of the debugger provided – because of the native differences in runtime for each language. More importantly, is that it requires more lines of code to achieve the same effect. What is typically a few lines in JavaScript inevitably turns into tens to hundreds of lines of code in Java. The compilation process is so effective that the hundreds of lines of code in Java turns back into those few lines of JavaScript. Which to me argues the benefit. Is there one?

 

 

 

 

 

Leave a comment
Follow

Get every new post delivered to your Inbox.