Javascript is here, its jQueer, get used to it

I’m way late to the javascript bandwagon.  I’ve long held the opinion that heavy use of client-side javascript in web applications made them messy.  No compiler checking, no type safety, excessively verbose DOM manipulation syntax, fragile browser specific nuances, duplication of logic already written on the server, and so on.  I, for one, always appreciated that ASP.NET server-controls and later ASP.NET Ajax largely hid that from me.  The framework would generate and inject the messy javascript required to make things work.  But the days of the framework being able to do this in a way that supports the rich interactivity that web application development requires, have long since been over. 

It’s increasingly apparent to me (maybe I’m the last person to realize this) that getting by with only a sprinkle of javascript, and cursory knowledge of the language and its libraries, is like burying my head in the sand.  Libraries like jQuery have largely solved the DOM manipulation, messiness, and browser specific problems. Additional jQuery plugins as well as libraries like Knockout also aim to further solve some of these shortcomings.  And while type safety and compilation may have felt like deficiencies in the past, the popularity of dynamic languages like Ruby and Python have legitimized that same power in javascript. 

Recent podcasts have further opened my eyes to the power and ubiquitousness of javascript.  It’s clearly not the toy language I had always felt it to be. 

I’m currently reading JavaScript: The Good Parts, as my first act of contrition to the javascript gods.

Comments

  1. Chris KeenanApril 8, 2011 at 12:42 PM

    Javascript is like a drug. Properly prescribed and used, it can be useful. But it's the abuse that's dangerous. My guess is that you probably avoided it b/c the javascript that's rendered by server controls and the MSFT AJAX library (except for the latest version) is convoluted and highly "obtrusive". It also didn't help that before ASP.NET 4 the control names when rendered were ridiculous, and one could never fully trust what an element was going to be called. Embedding a bunch of <%= Control.ClientID %> always made me uncomfortable. For me, it was the webforms model that precluded my experimentation with the drug.

    ReplyDelete
  2. nappisiteApril 8, 2011 at 5:36 PM

    I wish I could say that. But my aversion goes back to the classic ASP days. I just always found javascript to be messy, maybe I secretly wish VBScript had won.

    ReplyDelete
  3. Chris KeenanApril 10, 2011 at 5:39 PM

    Ah, got it. Didn't think of that angle, but makes perfect sense. Let us know how that book changes things (if it does).

    ReplyDelete
  4. AnonymousJuly 6, 2011 at 12:25 PM

    You should share that book with your co-workers. Oddly enough a js error initially prevented me from commenting

    ReplyDelete
  5. AnonymousSeptember 4, 2013 at 9:07 AM

    jQueer doesn't solve anything. It only aggravates the ocean of bad code around the 'net. Stay away from it if you really want to contribute something good.

    ReplyDelete

Post a Comment

Popular posts from this blog

RIF Notes #4

“It is better to be feared than loved, if you cannot be both” – Machiavelli “A well-stated problem is half-solved” – John Dewey jsFiddle - Cool javascript testing tool Modernizr - Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies. Why We’re Going With HTML(5) Instead Of Silverlight – More on the debate between Silverlight and HTML5.  A year ago I would have said Silverlight, hands down, for LOB development, now its not quite as clear.  At least not if your users need to access your apps from their iPads and Droids. Bootstrapped, Profitable, & Proud: Braintree – Braintree Payment Technologies was the first company I contacted when I first started investigating credit card tokenization a few years back.  Remote Desktop Protocol (RDP) -- Technical Analysis - Matt found this article, for an
Read more

RIF Notes #42

“In practice, problems are delegated but the power to address them is not.” - Maslach & Leiter Building the Object Model You Want with Entity Framework How you can improve your SQL with code analysis in SQL Prompt A growing number of young Americans are leaving desk jobs to farm – This is a head scratcher. Macro trends in the tech industry Technology Radar Vol 17 Essential .NET - C# 7.0: Tuples Explained – “What many folks didn’t realize when it was first introduced is that the new C# 7.0 tuple all but replaces anonymous types—and provides additional functionality.” Editor's Note – Misprint – “Any IT manager can regale you with stories of undiagnosable printer failures, but even at the home-office level printing is an exercise in fail” .NET Standard - Demystifying .NET Core and .NET Standard Devops - Continuous Data Migration Using Visual Studio and TFS
Read more

The greatest trick the AI ever pulled was convincing the world it wasn't THAT intelligent

Just listened to The AI Dilemma and it definitely elaborated on and articulated some of my own concerns, as did the news of OpenAI plugins. The synthesis of concern is: AI doesn't need to be that powerful to be destructive and destabilizing (e.g. social media algorithms) to people and society. These new LLM's are already much more powerful than social media algorithms. Many of the new LLM capabilities are emergent and poorly understood. The experts designing these systems don't fully understand them, and some of whom are already worried about what they've created. LLM's are being rapidly and recklessly deployed very broadly across society, in an arms race. The strongest argument against worry is that these LLM's aren't really intelligent, are really just a super-autocomplete that enables automating mundane tasks via natural language. But I don't think any of the companies developing or deploying these things are arguing that. Even if they were, see #1 &
Read more