All You Need is JavaScript | John Papa

John Papa

Evangelist on the loose

All You Need is JavaScript

...

Is all you need JavaScript? Will writing everything yourself without helper libraries relieve the stress and get you an equally if not better solution? You may be shocked to learn that it might. And at the same time, it might not. So how do you know what to do?

Recently I wrote about JavaScript Soup: the phrase I like to use to refer to the plethora of JavaScript libraries and frameworks that have infiltrated our daily development lives. Is turning away from libraries and writing all the code yourself in JavaScript the answer?

Vanilla.js

First let’s explore the attraction to Vanilla.js. Scott Hanselman pointed me to Vanilla.js, a clever site that sheds light on the fact that you could really get all you want with plain old vanilla flavored JavaScript. The reason it’s so clever is that it’s so true! There is a lot we can do with JavaScript.

Let’s consider AngularJS, a super powerful presentation framework. Does it do anything you could not do with JavaScript? Nope. It is JavaScript. How about Breeze.js? Again, all JavaScript. So the argument could be made that if it’s just JavaScript, why not just write it yourself. After all, you could probably do what you need in fewer lines of code, right? If you write it yourself then you won’t have to learn Angular or any other library/framework! So this is always the best answer, right? Maybe.

If you do write an awesome bit of JavaScript code, take the next step and share it via Open Source it! If you found value, maybe someone else will too.

Pros and Cons

There is no panacea to web development. If we choose VanillaJS we have complete control and likely a smaller code base overall, but is it as maintainable? If we choose to use popular and stable libraries we get a lot out of the box to jump-start us and help us long-term with maintenance, but at what cost?

The VanillaJS is appealing as you know exactly what you are getting. There is no box of chocolates here Forrest! You want to interact with the DOM, go for it. You want AJAX or promises, code them yourself. No jQuery and no other libraries.

In some ways it’s entirely empowering. When writing VanillaJS you learn more about the core of JavaScript and can really raise your expertise. The power can be intoxicating! In fact I highly recommend you give it a try if you have not. I’ve gone here and through that experience I learned quite a bit.

The downside of VanillaJS is that you may be reinventing the wheel at times. You could spend a week (or even a day) writing code that already exists in a stable library. Is that bad? Not necessarily, but you need to decide the value for your time spent writing your code and then the long-term up-keep of it. Do you want to be writing cross browser code, test it in all environments, and keep it updated when something already exists? It might be more performant (yeah I know that’s not a real word, but it sounds cool).

The other side is choosing a library that handles it for you. If you choose a stable library you can save those hours or days (or weeks) of coding and gain a lot of maintainability. But Are you using the library for 1% of its features and thus carrying a ton of baggage with you for features you are not using? That baggage could be in latent bugs or simply in the size of the library (think performance). You definitely need to consider this as you don’t want a massive footprint in memory and size if you are not using 90%+ of it.

What Do We Do?

The picture gets a bit cloudy if you see this as an “either or” situation. But if instead of thrashing one side or the other as a global solution you consider when and where it makes sense to use each, the picture becomes much clearer.

You don’t have to choose 1 or the other. Often a mixture is a good path to follow. Rarely in life do we have cut and dry decisions, and this is no exception. In my JavaScript Soup post I mention some guidelines I try to follow for choosing a library. These still apply here. If the library offers you an advantage based on that checklist and you will be using a considerable amount if its features, then feel good about using it.

It’s all about value. If you find value in it and can live with the costs, then go for it. This applies to both libraries and VanillaJS. Don’t kid yourself, they both have costs. What we get paid to do is decide how to balance those costs with the project and company needs.

There is nothing wrong with using a stable library. If you can add value to your project by integrating that with some of your own VanillaJS, then go for it. That’s even better! I recommend striking a good balance between the two.

tags: javascript
  • Steve Davis

    I find that my JavaScript expertise is tremendously enhanced by the libraries when I dig into the code. When I want to understand how a library is handling something in particular understanding that code often exposes new patterns or capabilities of JS that I just wasn’t aware of to that point.

    I look at it as an opportunity to gleam insight from a community of programmers that are held to very high standards.

  • http://mike-ward.net/ Mike Ward

    What about cross browser/platform compatibility? Many libraries are tested to work across different browsers on different platforms. That alone is worth the weight in my experience.

  • Ward Bell

    See this link – https://moot.it/blog/technology/frameworkless-javascript.html – for a passionate, contrary view in which (almost) all libraries are proscribed. The author wallows in celebration of his solo coding achievements.

    I am impatient with this view which strikes me as juvenile, selfish, and solipsistic. I have difficulty believing his objectives are important to anyone but himself.

    Which brings me to an important question, perhaps overlooked in your discussion: Who is this application for? Who are the stakeholders?

    I don’t write software for me. Some do, I suppose, but those who do seem unable to remember that most of us write software with and for other people … often the people who trusted us enough to pay us.

    That trust implies a sense of responsibility that is absent in his piece. When we write sponsored software with colleagues – present and future – we are obligated to choose technologies with them in mind. Development is a social practice, not a heroic individual act. At least that’s been my experience and I’m pretty sure that’s the understanding of the person who pays me to do it.

  • Daniel

    Hi John, this is off-topic but yet I am optimistic.. 9-)

    Being Silverlight guy and someone aware of vendor’s implementation of feature, do you think if WPF’s non-rectangular geometry would be so much resource hungry that it would affect the performance of low-powered ARM devices running Windows 8x? Its one of the major library missing from the modern desktop environment.

    Apparently, Microsoft has no plans for brining non-rectangular geometry to Windows Store. http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3794118-non-rectangular-shapes-in-windows-rt-and-windows-p. I would love to consume http://wpfbookcontrol.codeplex.com in a Store app.
    One way is by using JavaScript “turnjs” library http://www.turnjs.com/. But wpfbookcontro is by far superior and has rich full features. Then there is a hard way: by creating a game project for Win Store and redoing the wpfbookcontrol in native C++ (just saying its doable with DirectX API’s). My point is: isn’t it silly to revoke the native WPF feature for Win8/8.1 platform from their primary language, C#, while an implicitly equivalent feature exists in other supported languages? Or is it by design because WPF implementation is not optimized, a resource hog?

  • jphamilton

    Gotta go with Ward on this.

  • Maxim T

    What you are discussing is the choice between self written javascript and some libs in javascript language. But you are omitting languages which are compilable to javascript. For example, typescript language. The benefits, you eleminate at once a lot of bugs, leaving only logical ones. You can auto generate interfaces to your db backend. It gives you full intelisence and compile time checkings. In the end you get verified and checked javascript. But, there’s more. The typescript can be outputted to different javascript dialects, you don’t need to rewrite your code, only supply a different compiler flag.

  • Chris A Zias

    I’ve come to realize that most things in life come down to striking the right balance. Balance, it’s just that simple.

%d bloggers like this: