JavaScript Frameworks & Vanilla Goodies

Starting with Vanilla JavaScript
While I’ve done a lot of work utilizing the jQuery library and more recently a strong amount of JavaScript Frameworks activity…  I’ve done a lot with native JavaScript development (otherwise known as Vanilla JavaScript). It’s really a good thing to know native JavaScript in web application development. However, the issue with ‘just’ JavaScript is the different web browsers and devices do not render JavaScript code the same exact way, which results in different browsers displaying information inconsistently.

Why is that bad? Because we generally want people to have the same quality of experience regardless of what device they happen to be picking up at the time.

The Library
https://jquery.com
jQuery always comes to mind which is an excellent JavaScript library and extension, however, it can conflict with some frameworks if used together. I also say ‘extension’ because I feel I’ve used jQuery on many occasions and I know I haven’t had to use all of what it offers. It really is a thing where you can use it for one out of a thousand things on a given web page, and not necessarily use it for anything else for the entire web application. That is… if such a thing was desired for the business of that page. Or, you could potentially use jQuery selectors and events for every single thing on the page if that made sense for the application.

There are competitor JavaScript libraries out here with more seldom use. A library is technically slower than native JavaScript since it’s operating on top of it, however, that’s a performance differential that the human eye will not care much about until we’re dealing with an insane amount of data on one page. The advantage is that jQuery does generally deal with most cross-platform inconsistencies, which means it will look the same on almost if not all web browser devices.

JavaScript Front-End Frameworks
Since JavaScript was initially meant for Front-End Design/Development of web applications, let’s start here. I’ve recently had the chance to use various different front-end frameworks out there. They all take a different spin on the idea of using JavaScript for selectors and element functionality changes as well as template systems, similar to popular web systems like PHP as well as the more basic SSH configurations for including information from completely separate files.

Vue(https://vuejs.org) & React(https://reactjs.org) are two excellent examples of Front-End frameworks which are JavaScript based. The selling point is that they are coded in JavaScript (more-or-less), so, any given web developer wouldn’t necessarily have to learn something foreign like PHP to perform more complex inter-file web application behavior. They also include their own versions of library-like syntax which gives short-codes for things that would otherwise require more complex code. This gives them the same effective functionality as using jQuery with PHP.

React will not work well in combination with jQuery, and, why is that not possible? Well, even if a developer tried to use them together; React offers another library of its own which would be attempting to call the same triggers in the browser at the same time; effectively an invisible traffic jam. The more important thing is that React doesn’t render via the front-end… it renders to the client browser from a copy of the DOM on the server while using JavaScript as listeners for the user requests within the area it is rendering to the client browser.

If you know about servers, that would generally be a big performance advantage. However, as aforementioned in the case of jQuery, it’s only a visual difference if there is so much information being managed that it needs to utilize a larger amount of processing power.

Vue also does not render via the front-end. The files are not all accessed on the public domain as with standard JavaScript or jQuery use. A brief run of starting to use Vue in a few examples reveals that it works very similar to React, but I found it to be more intuitive in certain ways. It gives the developer a formatted code to begin with in the template files (.vue), while with developing in React you’ll want to save your own bare-bone snippets to begin with.

Vue also seems to be a bit “smarter” or flexible with HTML files than React by the way it can run code directly into an HTML file rather than rely on the server-side DOM for everything. Unless using the template, it doesn’t need to be inserted via a block element. In this way, it can be run on the public file in conjunction with a CDN script include as you would with jQuery or Bootstrap….

https://cdn.jsdelivr.net/npm/vue@2.5.13/dist/vue.js

However, I am not yet certain whether or not this provides a full alternative to the server-side DOM render.

While these JavaScript frameworks do run on the server-side for their purpose; they must depend on a web server application to manage the server-to-client connection. I’ve used NodeJS with ExpressJS for a web server locally. However, I wouldn’t be surprised if there are some interesting alternatives available.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

About K. Jerry Alleyne

Multimedia professional, military veteran and hobbyist athlete.