Should You Write Vanilla JS?

I saw the following tweet and it got me thinking....

People who still use vanilla JS are the same people who still write hand-written letters...

We have email now, you don't have to do this.

— I Am Devloper (@iamdevloper) September 24, 2018

What a load of rubbish.

I write vanilla JS all the time. Don't get me wrong, I don't want to reinvent the wheel, if I can use a snippet of code that does what I need it to do then great but in the vast majority of cases, you have to import some form of library.

That's where the problems start.

Let me set the scene a bit. If you write an enterprise web application one of your main concerns is performance and if it isn't, it should be. Traditionally, enterprise applications are client-server based and therefore, they're usually pretty damn quick. If you take out the data access layer then opening a new window? Rapid. Navigating around? Instant.

Matching that performance level within a web application is a challenge.

There are plenty of reasons for this but a big one is the downloading, parsing and execution of JavaScript.

There are trends occurring in the industry that help tackle this issue. Most big web applications are now single page applications, look at Twitter and Facebook as an example. You log in, your web browser will download (or retrieve from the browser cache), parse and then execute JavaScript when the page first loads and then that's it. The initial page load may be a little slow but once you've got over that hurdle, everything else should be pretty quick. The browser has everything it needs to run the application.

That's great for applications that can be written as SPA's but in some instances that's not a realistic aim. The product I work on is originally a port from Oracle Forms (very old stuff) and the port involves opening new windows and closing them as you navigate around the system, creating and editing records.
It's one thing having the performance hit on the first page load. It's quite another having a performance hit for every single window / iframe that opens.

Back to the problem then... using some form of library. A library is just that, it's not a single book, there's lots of books in a library, most of which you're never going to read. Each book in the library has a cost and in the JavaScript world, that cost is performance. You need to download extra code, you need to parse that extra code and then you have to execute it.... then you never use it.

That performance cost can just be too high and so writing vanilla JS becomes a better option.

As always in the developer world, nothing is ever black and white and it's why that tweet annoyed me.

Rule number 1: use the right tool for the job.

There's a time and place for libraries, I use ExtJS and KendoUI on a regular basis, they provide some great UI components. For me to code that from scratch and then maintain that code base is just too significant a resource cost.

On the other hand, there's a time and a place for vanilla JS. I could add jQuery to a page to animate a DIV to fade in and out but there's a performance cost with that. Instead, I could write vanilla js in around 6 lines that provides the same functionality, without all the extra baggage which will barely impact on load time.

In my opinion then, it's all about making sensible decisions based on your own particular scenario and requirements. Don't be governed by a blanket rule like that tweet!

HTML5 - Prefetching

Once upon a time I blogged about the new features included in the HTML5 spec and I was slowly making my way through the big new additions.

That pretty much died out due to a lack of time but I recently attended WebPerfDays and a new feature mentioned there jumped out at me. This feature is prefetch and it has some fantastic implications for web performance.

What is Prefetch?

Prefetching is the ability to request a page even though you're not on it, in the background. Sounds odd right? Why would you want to do that? Well, requesting a page means the browser can pretty much download all the content of a particular page before the user has requested to see it so, when the user does click on a link to go to that page, the content is immediately shown. There's no download time required, it's already been done.

To enable this, all you have to do is add a link tag like so.

<link rel="prefetch" href="http://clementscode.blogspot.com/somepage.html" />

And that's it. When the browser comes across that tag, it'll initiate a web request in the background to go and grab that page. It will not affect the load time of your original page.

The implications of this for web performance is obvious. Having the content of the page available before it's even requested by the user can only speed up your website but it has to be used properly. Adding prefetching to every web link on your website will cause unnecessary load on your web server so this functionality needs to be thought about before being used. A good example of this is Google. If you search for a term on Google, the first link brought back by Google will be prefetched (feel free to check the source to prove that I'm not lying!). The other links brought back are not prefetched. That's because Google know that in the vast majority of cases, the user clicks on the first link brought back and this functionality allows Google to provide you with that page as quickly as possible.

Are There Any Other Benefits?

That depends on your point of view... I primarily work on ASP.NET WebForms applications most of which are not pre-compiled... not ideal but we have our reasons. Using prefetching enables us to request pages before they're hit which, if it's the first time that page has been hit, forces it to be compiled. So we're improving performance two-fold. That initial compilation time has now been taken away from the user and we're getting the usual benefit of prefetching so users are presented with a page almost instantly after clicking.

That Sounds Awesome But What Are The Downsides?

Well, you're requesting additional pages, as long as the user actually goes to that page then that's great but, if they're not, you're placing an additional load on your server that serves no purpose.

Also, if you're gathering website statistics such as number of page hits and such then this will throw those stats off as technically, the user may not actually view that page even though it's been requested.

Finally, this obviously uses client resources, where as this may not be a problem on a nice big powerful desktop, it may be a problem on small mobile device.

And that's about it. Another great addition to the HTML5 spec. As with most things in our world, you need to think about its use rather than just blindly prefetching everything without any thought of the disadvantages of doing so.

Enjoy!

Improving Build/Start Up Time

In fairness, there's nothing better to do while
waiting for compilations

I've recently had the pleasure of upgrading to Visual Studio 2012 and for the most part, I love it. However, I've noticed that debugging my web application has become a very time consuming event. From hitting the F5 button to getting to my start up page, it was taking over 3 minutes and needless to say, it was driving me crazy and was seriously affecting my productivity. The xkcd comic on your right may just point to why...

For the sake of my sanity, I set out to find out how to improve this and I've now got that time down to 20-30 seconds. Here's what I've done...

Web.config Changes

There's a couple of changes you can make in order to speed things up. I should say these should only be applied to your local development environment. They're not changes that should be applied to a production environment as they'll have a direct impact on your application's performance.

Firstly, the configuration tag has two attributes you should make use of. There's the batch attribute and the optimizeCompilation attribute. You should set the batch attribute to false and the optimizeCompilation attribute to true, so your tag should look something like this:

<compilation debug="true" batch="false" optimizeCompilations="true" />

Let me explain what this does. First off, the batch attribute. By default, this is set to true and what this means is that when your web application starts up, ASP.NET will pre-compile all your un-compiled files (aspx, ascx files for example) in one big batch. Depending on the size of your application, this can significantly increase your load time. By setting it to false, this will no longer occur and instead, the file will be compiled as and when you access it. That means when you visit a particular page, the load up time for the first time you access that page will be a little slower as it'll need to be compiled but the chances are, if you're debugging a particular problem, you're only going to be visiting a very small subset of the total files that get compiled when the batch attribute is set to true so overall, you'll be saving yourself a significant portion of time. For more info, check out the MSDN documentation.

The optimizeCompilations tag is a bit of an odd one. I can't seem to find any documentation about it apart from this blog post so I don't know if it's valid in .NET 4 (Although I use it in my applications and it seems to do the job). Anyway, the reason this is helpful is that by default every time you change a file in the bin directory, the global.asax file or anything under the App_Code directory, the application is re-compiled during start up (the same re-compile process we spoke about above). By setting this to true, this re-compilation no longer occurs. Now this can cause problems which is why it's not turned on be default (more info about that can be found on the blog post mentioned above) but in the majority, if you're like me, you're usually changing method implementations rather then creating or change method specifications. So, turning it on means no more recompilations, again saving more time on start up.

Fusion Log

For those of you that don't know, fusion is a tool that enables you to log DLL binds to disk (more info on this tool can be here). This is particularly helpful when at runtime you're getting errors about DLL versions or particular DLLs not being found and you can't work out why. The log will tell you where ASP.NET is looking for those DLLs, what it's finding and whether or not it fails. This can be a very handy tool. 

In .NET 3.5, I found that it was sometimes a little unreliable. I'd turn on logging and the logs wouldn't be generated. It was a tad frustrating it must be admitted. In .NET 4, I don't have this problem and logs seem to be generated as you'd expect. The problem with this is that creating these logs takes time and if you happen to have hit the "Log All Binds" option and then forgot about it, you'll notice a significant performance decrease.

Long story short, only log binds if you absolutely need to and make sure it's turned off when you're not using it.

Application_Start

Application_Start is a method in the global.asax file and it'll fire when when the application domain starts up. This is great but if you're running code in there then it'll obviously effect load up time. So, if you don't need to run that code, don't. I know in our application we have features that are initiated in that method. If I'm not testing one of those features then I don't need it enabled which helps speed up the application start up time.

Solution Changes

Finally, you can make a few changes to your solution to ensure only what you need to be built, is built. 

Firstly, do a full re-build of your application so that all necessary DLLs are generated. Then, unload any projects you're not working on. If you change a class or method in one project, Visual Studio will compile all projects that have references to that project. Unloading those projects will ensure they're not rebuilt saving you some precious seconds on your build time.

Secondly, if you right click on the solution at the top of the solution explorer within Visual Studio, you can select "Configuration Manager". In here you can un-tick the "build" option on all projects that you're not working on. As with the option above, this will ensure un-neccesary projects aren't built. What it does mean is that when you change code in a project that you've marked not to be built, you have to explicitly build that project otherwise your changes won't be picked up.

Warning. These solution changes do have down sides. If you change a method signature within a project and projects that reference that have not been built, then any errors caused by that change will not be picked up at compile time. With that in mind, it's well worth compiling everything before committing/pushing/releasing any code, just to ensure everything compiles as you'd expect.

And that's all I've got. If you've got any other tips or tricks regarding application start up time then I'd love to hear them. Very few things frustrate me as much as waiting for the web applications start up screen to actually load.

Happy coding!