In this article, we will:
Imagine a user filling out a form on a website. The validation of the input files on any form required a full round trip to the server. The server does some processing, retrieving data to validate the form values before returning an HTML page to the client. While the server is doing its thing, the user is waiting. And at every page reload, the user waits some more. This was not only a painful exercise as the internet speed was very slow but also resulted in the loss of data if the form was not filled out correctly. It lacks the inherent responsiveness of desktop applications.
To make it happen, Netscape turned to Brendan Eich, a software engineer with lots of experience with developing programming languages. At around the same time, Netscape laid the groundwork for a deal with Sun Microsystems. The idea was to sign a deal with Sun Microsystems to license Java. The preliminary concept was to embed Java Virtual Machine (JVM) right in Navigator which would allow developers to build complex Java applications (later called applets) and run them on the web.
However, given the nature of the web community, which was a cobbled-together community of hobbyists and enthusiasts. Some had years of experience in the computer science field. Others had none at all. Netscape realized that what they really needed was a "companion language" because Java is a very difficult language to manage without a background in computer science. It's extremely powerful, but relies on complex principles like object-oriented programming. Therefore, any language made specifically for the web, needed to be both powerful and approachable to the average developer. Something that would allow developers to change text, move elements around, and generally experiment without errors flashing on screen every time they messed up something. A scripting language that could easily be embedded right into the HTML of a web page, that was still powerful enough to lay down a foundation for more adventurous programmers looking to build complex applications.
script tag, developers were able to create fairly complex applications.
AJAX and DHTML are two technologies that are used in order to create more interactive web pages compared to the plain boring HTML pages. The main difference between DHTML and AJAX is that DHTML changes the elements on the web pages depending on user's actions while AJAX allows the browser to request certain elements one at a time in order to reduce the strain on the server and the Internet connection.
A framework is a library that offers opinions about how software gets built. These opinions allow for predictability and homogeneity in an application. Predictability allows software to scale to an enormous size and still be maintainable.
Main features of JS frameworks
Each major JS framework has a different approach to updating the DOM, handling browser events, and providing enjoyable developer experiences. Below are some of the main features shared among different JS frameworks. Each framework may have its own implementation, but at the core, they all share these common features. A good understanding of these common features at a high level is very useful when it comes to deciding which framework to use for your application. So, let's dive in.🤿
- Domain-specific languages (DSLs)
A domain-specific language is a computer language that's targeted to solve a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem.
Examples of common DSLs are CSS, regular expressions, SQL, etc.
Most frameworks have some kind of component model. Regardless of their opinions on how components should be written, each framework's components offer a way to describe the external properties they may need, the internal state that the component should manage, and the events a user can trigger on the component's markup.
For example, React components can be written with JSX, Ember components with Handlebars, and Angular and Vue components with a templating syntax that lightly extends HTML.
- Properties (
props): external data that a component needs in order to render.
- State: Similar to props, state influences the output of render. However, the main difference between props and state is that props get passed to the component (similar to a function parameter) whereas state is managed within the component (similar to variables declared within a function) and represents information about the component's current situation.
- Events: In order to be interactive, components need ways to respond to browser events, so our applications can respond to our users. Each framework provides its own syntax for listening to browser events, which reference the names of the equivalent native browser events.
- Properties (
Each framework offers a way to define styles for components.
As with other features, each framework provides its own mechanism for handling dependencies - using components inside other components. Components tend to import components into other components using the standard JS module syntax or something similar.
Components in components:
One key benefit of component-based UI architecture is that components can be composed together. Just like you can nest HTML tags inside each other to build a website, you can use components inside other components to build a web application.
The problem of passing data through many layers of components is called prop drilling, which is not ideal for large applications. To overcome this problem, frameworks provide dependency injection - a way to get certain data directly to the components that need it, without passing it through intervening levels. Again, each framework has a slightly different implementation, but the effect is ultimately the same.
In the context of a framework, a component's lifecycle is a collection of phases a component goes through from the time it is appended to the DOM and then rendered by the browser (mounting) to the time that is removed from the DOM (unmounting).
Each framework names these lifecycles differently, and not all give developers access to the same phases. However, all frameworks follow the same general model: they allow developers to perform certain actions when the component mounts, when it renders, when it unmounts, and at many phases in between these.
Although each framework takes a slightly different approach in how components are rendered, all of them track the current rendered version of your browser's DOM, and make decisions about how the DOM should change as components in your application re-render.
Because frameworks make these decisions for you, you typically don't interact with the DOM yourself. This abstraction away from the DOM is more complex and more memory-intensive than updating the DOM yourself, but without it, it's impossible to program in the declarative ways that frameworks provide.
To avoid a broken experience in sufficiently complex apps with lots of views, each of the frameworks provides libraries that help developers implement client-side routing in their applications.
Although testing tools are not built into the frameworks themselves, the command-line interface tools used to generate framework apps provide access to the appropriate testing tools for unit and integration testing.
- [Background photo created by wirestock - www.freepik.com (https://www.freepik.com/photos/background)