Tuesday 25 September 2018

Should You Write Vanilla JS?

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

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!

Monday 12 March 2018

Reports Builder and TLS 1.2

With the recent security problems found with TLS 1.0 and 1.1, you may find that you want to disable those protocols; allowing only connections over TLS 1.2.

99% of the time this is fine and everything just works but as always, there's always something. For us, that "something" was MS Reports Builder.

The application I work on allows end users to write their own reports using MS Reports Builder. This connects to the SSRS reports server via a web service and if your reports server is in the cloud somewhere, accessing it over HTTPS is certainly recommended.

Turning off TLS 1.0 and 1.1 will make that HTTPS connection more secure, forcing it to use TLS 1.2, the problem however is that Reports Builder is not a fan of that. You'll get the following error.


The reason for this is that Reports Builder is built with a version of the .NET framework that didn't originally support TLS 1.2. Updates to the .NET framework has enabled TLS 1.2 but unless programmatically told to, an application won't use it. We obviously can't change the code that Reports Builder uses. That's a Microsoft product that we can't affect but there is a solution...

Making the following changes to your registry will force the application to use TLS 1.2

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
And with that... Reports Builder will come back to life and will use the more secure protocol to communicate with the report server, fixing the problem once and for all.