introduce
In 2017, JavaScript development can make the language usable for novices, paralyzing many veterans and leaving them unsure where to start or which path to take. People often delve into the newest and greatest without really understanding why it’s so great (or why it might not be). Knowing JavaScript’s history can help you understand its current state.
We discussed these problems together. All programming, in any language can solve the problem. This is true at the macro level (” How do we deliver solutions to users? ), one is mesoscopic (” How can we order this data as quickly and efficiently as possible?” ), and at the micro level (” How do I iterate through this array?” ). Programming languages are built to give users tools to solve these problems. For the Web or anything else, JavaScript code is no different from any other code that can be used to write programs. Mean people will also be happy to let you know how many problems JavaScript has, and I’m not denying that there are a lot, but so is any other language. I’ve never seen an experienced programmer who periodically curses some long-ago standards committee decision that may no longer make any sense.
This article does not attempt to delve deeply and comprehensively into all the problems that JavaScript solves, let alone how it can be used to solve this problem. Rather, it is a broad overview of the language itself and the history of its use to solve increasingly complex problems on the Web. It tries to answer big pictures like where we are and why we are here, and I have to keep it pretty high; A complete history of language could fill a whole book. That’s what I call a brief history.
Without knowing the fundamentals, it’s hard to understand questions like “What is A framework?” and “Why is jQuery A good way to solve problem A, but not problem B?” Answers to frequently asked questions. Knowing the answers to these questions can save developers a lot of time, effort, and spirit by allowing them to make smarter choices.
I have divided the article into four basic time periods. Early eras, including during the first decade, nascent languages were used in browsers; Around the time of jquery, frameworks like jquery began to have some basic and extremely frustrating problems with JavaScript development; In the single-page App era, developers are starting to encounter the limitations of jQuery, and frameworks like Backbone and AngularJS are emerging. Now we’ve seen smart technology, compact writing frameworks, app development that focuses on speed, ease of use and block splitting, and JavaScript that returns to “Vanilla”. For each period, some background on Web development will be provided, talking about the problems that people encountered, and explaining how the technologies of the era addressed those problems.
But we have outdone ourselves. Let’s take a time machine back to the days when dinosaurs roamed the earth, and one particular browser ruled: Netscape Navigator.
# # Early days
Schedule: approximately 1996-2004
Problem: Based on DOM manipulation, user interaction
Innovation: JavaScript itself, XHR and AJAX
Major browsers: Netscape Navigator, Microsoft Internet Explorer
JavaScript was created by Brendan Eich within ten days, and then an employee, Mozilla, was hired to wedge the Scheme programming language into Netscape. This project was abandoned in favor of a language whose syntax was more similar to Java. Eich created a language, LiveScript, that can be embedded directly into a browser that parses HTML documents, without the need for compilation. LiveScript was first used in Netscape Navigator in September 1995, and was renamed JavaScript Software Beta 3 in December 1995. [[1]] (# foot1)
Aside from the name, JavaScript shares common ground with Java, except for the C language, indentation-indifferent, object-oriented language, which actually have quite a bit in common, but contain nothing to share with the Java base code, and languages with important core aspects are completely different. The decision to call it JavaScript was a marketing move, and resulted in recruiters contacting developers who had been working with JavaScript for 21 years and breathlessly celebrating all the exciting Java programming opportunities. Thank you so much for Mozilla.
Netscape 3 and especially Netscape 4 were their Tyrannosaurus Rexes of the day, crushing all challengers between their massive jaw power.
In the first few years, JavaScript was battling with Microsoft’s various scripting languages, which was an important factor in any given time before the site could possibly work on Netscape or Internet Explorer (and then on its third version), but neither did.
Don’t get me wrong, Netscape didn’t crawl over the years. Netscape 3 and especially Netscape 4 were their Tyrannosaurus Rexes of the day, smashing all the challengers in between the sheer force of their enormous jaws. IE is also a run that can render HTML normally, not to mention once cascading style sheets become widely popular. Netscape seemed unstoppable.
But by the early twenties, Netscape’s growth had dwindled, and Internet Explorer’s first version 5, followed by 5.5, and then Killer of God, version 6 continued to improve, gaining greater market share. JavaScript’s current evolution is limited. Both Mozilla and Microsoft have adopted the “JScript” language, mainly to avoid copyright issues and to make a lot of attempts at standardization. However, browser capabilities vary widely.
Archive PlanetQuake version, on Netscape 4, C1999 \. We use JavaScript to scroll the headlines under the main image. This is abnormal L33T…
As a result, writing complex scripts that work in multiple browsers is tedious and sometimes completely impossible. Many scripts of the era were reduced to bells and whistles. As [reactive Arsenal] (reactarmory.com/) (and many excellent Jav… J. Nelson (jamesknelson.com/), said: “I got into JavaScript in this era because I wanted to add mouse-over images to the menu bar on the website I was building. I also used JavaScript to create user-unfriendly drop-down menus, create annoying pop-ups and do some simple animations.”
Annoying scrolling text is everywhere. So are alerts, confirmation boxes, and numerous security holes. Probably the single most common use of JavaScript in the early days was to create the aforementioned DHTML effects, such as image flipping, functionality that was eventually largely replaced by CSS.
Someone did a great job with JavaScript. As [Dori Smith] (www.dori.com/), [JavaScri… UTF8& Tag = Loserace-20 &camp = 1789& Creative = 9325&linkCode = AS2 &creativeASIN = 0321996704&linkId = 5 c8ae57787dc7b044156a0ac42a84bfb) and notes of the language of the early programmer/author, “there are a large number of JS frameworks and libraries in the late 90 s. Nick Heinle and Steve have a Champeon, just two examples. When it comes to dynamic interaction on the web, the scene is dominated by Java applets, ActiveX widgets, and Macromedia Flash.
It entered the 1930s, and there were some happy convergence developments that allowed JavaScript to really take off. One of these was the creation of various methods for asynchronous communication between a javasjavascript driven front end and an external back-end server, including the eventual adoption of XMLHttpRequest (XHR) by all major browsers. In addition, Prototype, MooTools and jQuery frameworks were developed later.
JQuery period
Time frame: 2004-2010
Problem: Increased site complexity, multi-browser support
Innovation: Powerful DOM manipulation, early single-page applications
Mainstream browsers: Microsoft Internet Explorer, Mozilla Firefox
In the early 2000s, DHTML took off. The D stands for Dynamic, which basically means “we work with the HTML you see on the screen without a browser refresh.” It seemed a bit ridiculous, but it was a huge deal at the time. Traditionally, websites require a page refresh when you want to do anything. JavaScript provides some toys, but standard websites are still very page-based. When the user clicks tabs, they go to a separate HTML document or give a full page refresh to adjust template variables before rerendering the HTML. This is still how the core features of many websites (including this one) work, but the power of DHTML support means more websites can be better and more dynamic.
There were only two major browsers during this period, Microsoft’s Internet Explorer 6, which was an incredible browser release but eventually turned into an unsupported zombie hovering around the neck of the Internet, Mozilla’s Firefox. However, there are others on the bezel, and multiple versions of IE are still in use. “Because Web standard condition and network, a lot of mistakes in The development of The network is very difficult,” [JavaScript: The Good Parts] (www.amazon.com/gp/product/… (and many other word-to-word languages) author [Douglas Crockford] (www.crockford.com/) told me. “Automatic updates had not been invented, so the release of [new] browser versions did not eliminate errors in the network. But it does add new ones.”
Trying to render a consistent experience across these browsers was a nightmare; Trying to make the dynamics of the experience worse. JQuery creator [John Resig] (johnresig.com/) on the origins of frameworks:
When I first created this library, I wanted to scratch two tickles: 1) provide a simple interface for DOM, and 2) reduce the number of cross-browser issues that exist during development [[2]] (# foot2)
Working with the DOM across multiple browsers was an important factor for Web developers in early 2000, but it wasn’t the only thing on their minds. The other big revolution in the industry is AJAX, which allows asynchronous exchange of data with the server, rather than just relying on it being available at page rendering time. “In 2005, [Jesse James Garrett] (twitter.com/jjg) discovered AJAX, a new name for DHTML,” Crockford says. “AJAX was more successful than DHTML because Netscape was dead, and because Microsoft abandoned the web after IE6, and because the W3C ineffectively decentralized the Semantic Web. Long periods of neglect have brought much-needed stability. AJAX was a big hit, inspiring a lot of new libraries to make one-page web applications.”
The early pioneers of big companies like Microsoft and Google have done a lot of convincing with AJAX over the years, but the launch of Gmail in 2004 really made the world of Web development a lot more interesting. This is a whole new way of handling email: by doing everything in a browser and storing it on Google’s servers, it means users can access their email from any Internet device, anywhere in the world, without having to install a local email program. This is not the first single-page application, but it is the best of its time of significant growth and being noticed by the world. Gmail uses DHTML and Ajax-like code in the same way that several other websites do, and other developers want to be able to use both quickly and easily, leading to the rise of frameworks, including broad categories: [jQuery] (jquery.com/). “It addresses browser compatibility issues, adds a bunch of useful utilities, and introduces selectors in addition to Document.getelementByID,” Nelson said. “The only problem with jQuery is its weight. If you are dialing, ~ 30KB is a lot. “
At Crispy Gamer, we use a lot of jQuery, extension boxes, title flips, swap tabs, and more.
But jQuery is not the first! The prototype, first developed to add AJAX support to Ruby on Rails, was also capable of DOM manipulation similar to the widely known jQuery, which was released in February 2005. This was followed by jQuery in 2006 and [MooTools] (mootools.net/) in 2007. Although each of these libraries provides many similar functions, they have their own approach. ProtoType rewrites and extends many of JavaScript’s native methods to the dismay of some developers who find them. MooTools changes JavaScript’s Element object, which means it allows more DOM manipulation.
JQuery has none of these things and focuses on providing a framework on top of basic JavaScript. This approach has proved most successful in just a few years, and jQuery has become the dominant framework. It still remains to this day. More websites are using jQuery in 2017 than JavaScript frameworks.
But what does the framework really offer? So let’s look at these code snippets. Here’s how to hide click elements in simple JavaScript:
var el = document.getElementById('myElement');
var el2 = document.getElementById('myOtherElement');
el.addEventListener('click', function (e) {
el2.style.display === 'none';
}
Copy the codeTo get the job done, assume that your browser supports these commands correctly, which is certainly not a safe assumption in many DHTML and AJAX use cases. Here is the same functionality in jQuery:
$('#myElement').click(function() {
$('#myOtherElement').hide();
});
Copy the codeNot only is it simple to understand, but it has another benefit: jQuery ensures that it works in all browsers, so engineers don’t have to worry about it. This also means that developers don’t have to spend much time recreating rounds. Why write your own show/hide/toggle functions when jQuery already provides these and dozens of others? “JQuery doesn’t really change what I build with JavaScript,” Nelson says, “but it does change how I build. It made JavaScript simpler and seemed magical at the time. “In short, jQuery and its competing frameworks are faster and easier to develop for everyone who uses them.
Slowly as the site became more active, companies without Google engineers began to try and build complex applications like Gmail (or Moreso), and they began to run into trouble. The code base, which consists of thousands of lines of jQuery code, is difficult to maintain and contains so many custom features that new development can be challenging. If your site has five clickable elements, there are five cases where $(” # myElement ‘).click () can be controlled. If there are 500 clickable elements, it becomes problematic. With 5,000 clickable elements, it becomes a nightmare.
Something more is needed. JavaScript frameworks began to evolve, with distinct back-end features and methods. The era of single-page applications has arrived.
The era of single-page applications
Time period: circa 2010-2014
Issues: DHTML overload, large scale data processing, speed
Innovation: MVC framework, two-way data flow, DOM automation
Mainstream browsers: Google Chrome, Microsoft Internet Explorer, Mozilla Firefox, Apple Safari
Other innovations help lead the way in the era of single-page applications. One is Google’s Chrome browser, which was released in early 2008. Among Chrome’s innovations is a set of development tools that are more powerful than ever seen before. Continuously improved and updated, Google tools allow developers to view and edit everything happening in HTML, CSS, and JavaScript in real time. It also provides a debugger that integrates JavaScript, which allows you to debug the language in a manner similar to traditional compiled languages (previously, developers relied on browser plug-ins or external programs to implement these features). Most major browsers offer similar native functionality.
Other major Chrome contributions? V8 JavaScript rendering engine (developers.google.com/v8/), allows independent JavaScript platform to create [Node. Js] (nodejs.org/). The history of this article has been focused on the front end of JavaScript, but we can’t fail to mention that Node.js has become a major factor in the evolution of websites. Hobbyists and big businesses alike have adopted Node’s fast, asynchronous approach to enabling application technology to evolve, proving popular with developers who now control many websites, including this one.
JavaScript frameworks need to become more like these existing back-end languages such as C++, PHP, Ruby, and others.
Not all Chrome, though. The single-page application era arguably has the most equal use of the browser divide in any cycle of Web life, but… It’s a fun to exploit. Browsers, even IE, adopt too many standards. First, there’s a good chance that the site you develop will look and function the same whether you open it in your browser, or at least only require minor tweaks. CSS frameworks such as Sass have emerged to make the visual aspects of Web development easier, and the limitations of the box model have been cataloged quite extensively (leading to a lot of discussion, some kind, some not, about how many “Web 2” sites are there?). . Chaos is coming: Flexbox is coming, and in 2010 Ethan Marcotte published his landmark article on responsive Web design, but for a brief period, things seem to be settling down a bit.
In the single-page application world, this is not the case. Tired of dealing with the inscrutable morass of tens of thousands of lines of jQuery code, developers are casting alternatives. A new framework was developed with a different focus from the previous major release. What is needed here is a set of tools to enable them to manage increasingly complex applications. JavaScript frameworks need to become more like these existing back-end languages, such as C++, PHP, Ruby, or others.
Enter Backbone.js. In 2010, developer Jeremy Ashkenas released a new toolset he wrote for single-page application developers. Backbone is lightweight, fast, and doesn’t rely on jQuery (although developers can include jQuery to unlock more Backbone features), but Backbone is designed to solve the “jQuery swamp” problem. This article is excerpted from its website:
“It’s easy to create JavaScript applications, but ultimately tangle with stacks of jQuery selectors and callbacks, all frantically synchronizing data to save HTML interfaces, your JavaScript logic, and your database on the server. For rich client applications, a structured approach is often more helpful.”
Backbone splits code into a data model that processes the set of operations on that data and displays a view of it. It also provides a lot of “automatic” handling of some behind-the-scenes operational meaning. By connecting their views to their data, developers no longer have to worry about updating their site when the data changes. Backbone has made it happen for them… Still. Backbone is an excellent product that is widely used in some very large and well-known Web applications.
Also in 2010, the first version of AngularJS hit the screen. Originally developed by Miško Hevery and Adam Abrons, Hevery became an employee when it ended at Google. It is supported by Google and a group of dedicated outside developers, although the most recent version has been rewritten and does belong in the next section. But AngularJS 1.X, which is still backed by developers and Google, is still widely used on the Internet.
I can’t legally certify To you my AngularJS task, here’s AngularJS promoting the to-do List for this era’s “Hello World” app.
AngularJS somehow gives a complete front-end architecture solution without even backbone.js. It provides powerful tools and a component-based architecture that is difficult or impossible to recreate with plain jQuery. As Nelson says, “I’ve been trying (or failing) to build useful single-page applications with jQuery and raw JavaScript for years now. Then I stumbled upon AngularJS, which told me that an application’s model doesn’t need to live in the DOM. This makes large applications viable.”
Using its concept of two-way data flow, AngularJS allows developers to create applications that reflect data changes on both the server and client side. For example, a person might create an AngularJS application where users fill out forms and see their data accumulated elsewhere on the live page, and know that the data is stored on a server at the same time. No one needs to write a lot of jQuery for this synchronization anymore — except for Happened.
AngularJS, like Backbone, also provides a lot of help with pretty DOM manipulation. Backbone, for example, makes good use of jQuery, but doesn’t need it to show any major functionality. This allows developers to familiarize themselves with the jQuery ecosystem and gradually move to AngularJS.
The framework has also helped popularize the use of components — separate functions as HTML tags, but potentially containing complex functions. This allows for extensive cleaning and separation of tags, where a component can be called a tag, such that:
<userlist ng-repeat="user in $user.list"></userlist>
Copy the codeAnd generate a complete list of users, including details and embedded HTML, such as a link to a user profile page. Also important is that if the data changes in the $users.list array, AngularJS will re-render the list with the newly updated data without the developer having to do anything further.
Backbone and AngularJS all of a sudden have two complete toolboxes filled with single-page application development tools that address many of the shortcomings of large-scale jQuery development, so that developers don’t often write their own similar features. If JavaScriptshi is a basic manual tool and jQuery is a powerful tool, then frameworks like Backbone and AngularJS are linear package-specialized collections of highly complex devices designed for a single purpose: creating single-page applications.
The problem is… They are not particularly small or fast (especially on mobile devices), it may be harder to assert their own rights, and the whole two-way data approach can be a real double-edged sword.
In 2013, Facebook released React, a small but extremely fast rendering front end framework. In 2014, they adopted an event-based approach to organizing and developing the application, Flux. These things, and the related technologies that grow around them, have once again changed JavaScript application development.
The Modern Era
Date: circa 2014 – present
Problem: Speed increases application complexity and reliability
Innovations: virtual DOM, one-way data flow, types, testing
Mainstream browsers: Google Chrome, Apple Safari
Over the past few years, we’ve seen a steady increase in diversity when visiting pages. Limited to the realm of home PCS, it currently makes perfect sense to use someone’s phone, tablet, laptop and desktop computer to browse a website on the same day. The bandwidth, processor power, and screen resolution available to these devices vary widely. Small downloads and fast rendering are very valuable… No, you know it from visiting a lot of websites that feel completely comfortable hammering users with massive image downloads, terabytes of AD code, and auto-play video content!
But content sites are not one-page applications, and their users expect different things. Single-page applications are intended to replace native applications, so that their speed and responsiveness will be replaced. A user can endure a five-second load to read the latest sports news, but they can’t endure a five-second load when they click a button on a banking app or analytics dashboard.
Facebook developed React to speed up or make it easier for their developers to use. A lot of smart people have spent a lot of time on it, which shows. It’s not perfect, and there are new and potentially better options always on the pipeline, but there’s a lot of it available to developers – so much so that it’s often used in projects that don’t really need it… But we will get there.
Also, if you’re reading this article, there’s a very good chance you may have heard or actively used React as your entire front-end solution. Why is that?
React has not replaced Backbone and AngularJS as the preferred JavaScript frameworks, although its usage has suffered a dent, in part because it is not a complete framework. React was conceived as a view language for the front-end MVC framework. It’s true that React was created to work with other existing technologies, but some of the other technologies were customized by Facebook development. That is, work from home, like the tech companies Facebook has never touched. It doesn’t handle data, it can’t handle events, it doesn’t handle XHR/Ajax… All it can do is render components.
Also, if you’re reading this article, there’s a very good chance you may have heard or actively used React as your entire front-end solution. Why is that? Because the ecosystem has grown around React, enabling bundling technologies like Webpack or Browserify allows “React” to become a quick and convenient way to “React plus a bunch of other stuff.” Roy Nelson sums it up succinctly: “In a sense, the modern era feels similar to the jQuery era, in that it makes it much easier to build single-page applications and impossible to make new types of applications possible. WebPACK and [NPM] (www.npmjs.com/) facilitate the sharing of these components and their assets. [Babel] (babeljs.io/) means we don’t need to create a new language just for JavaScript to use.”
React is not without its problems, however. Ecosystem-based packages mean that JavaScript file sizes can quickly spiral out of control, and unless a lot of attention is given, the overall landscape can be intimidating even to experienced developers, let alone novices. Quality documentation and a friendly community help mitigate this, but the learning curve is still steep.
Other frameworks are also springing up. As mentioned, AngularJS 2 has been basically rewritten to operate in a more reactive manner, rendering faster than AngularJS 1, which is an important factor when displaying large amounts of data. Meteor, at least a year older than React (and, in fact, can use React for its view layer), has a special example. Vue.js, first released in February 2014, is a small and fast front-end framework that fits well with other front-end frameworks, allowing incremental implementations. Its syntax is similar to React, and its structure, while not identical, follows a similar component-based approach. [Preact] (Preactjs.com/) is a very small, fast alternative to using ES6 built from the ground up with React, a more modern version of JavaScript that enjoys increased popularity. (React also works with ES6, but is initially built with ES5, This is more or less what we’ve known about JavaScript for about a decade). Others are following.
It’s important to notice what React, AngularJS, and others are doing, without really reinventing it. Other languages are doing this even in the JavaScript world for a decade. As Crockford points out, “We stopped calling it DHTML or AJAX and started calling it single-page applications, but it’s still the same thing as the new gallery.” This is basically true; The underlying code is still JavaScript, and it’s still doing the same basic things that people did in earlier languages. Now the difference is one way.
All of these frameworks tend to focus on solving the same problem: creating a diverse set of tools for developers to quickly build fast, single-page Web applications that work well on a variety of devices. They tend to focus on data flow and display: basically, reducing the amount of work developers have to do in order to get the data provided to them on the screen in a way that is useful to the end user and automatically update the screen as the data changes. When you’re dealing with huge amounts of data, you want to show users an app with a similar experience, and they’re lifeguards.
Which took us to Vanilla JS. At this point, you might be wondering if anyone developing a small website in 2017 should take advantage of their meager JavaScript needs. AngularJS and React do seem a bit excessive, don’t they?
They are. While great for single-page applications or websites with lots of moving parts, modern JS frameworks are unnecessarily complex if all you want to do is click a few buttons and swap between tabs. The answer is “What do I use?” Yes, depending on your specific needs, whether it’s jQuery 3 or Vanilla JS.
No, you don’t see Inception anymore. Yes, Inception uses Vanilla JS.
Vanilla JS is not a framework. It’s not a library. It’s nothing but, um, JavaScript. Recent additions to JavaScript make it easier to work with. Document. QuerySelector and document. QuerySelectorAll, for example, provide elements with similar CSS syntax similar to the jQuery selector (“. Exterior – link “, for example). ES5, ES6, and ES7 are basically fully supported by all modern browsers, reducing the cross-browser help of jQuery for those who are no longer catered to the rapidly declining needs of traditional browsers. Performance-wise, writing simple JavaScript code is almost always fast (unless your routines are suboptimal) even on older, slower mobile devices. Smith, like many developers, is excited about the new focus. “Vanilla JS returns, that’s huge for me. I really hate stack overflow for people, imo, misuse of jQuery and similar frameworks. Bring all the jQuery so you can write three lines of code instead of five? Taiwan.”
We don’t cover a lot of Vanilla JS at CloseBrace, but the network is full of good resources. In particular, friends of the website [Chris Ferdinandi] (twitter.com/chrisferdin… Produced a lot of good Vanilla JS content in Go Make Things, including the fact that you can use a lot of open source code in your own projects.
So, here we are. It’s 2017, and the JavaScript ecosystem is both thriving and confusing. No one seems sure where it will go, except that it will continue to grow and change. The web isn’t going anywhere, which means JS isn’t going anywhere, and I’m excited to see what the coming era brings to us. Hopefully you found this article interesting and informative, and we’ll have a better understanding of where we are, how we got here, and why we’re on this path. Thanks for reading.
If you enjoyed this article, consider voting for it on Reddit and Hacker News. Oh please, please leave a comment on all the great things I missed or didn’t properly explain!
About CloseBrace
CloseBrace for JavaScript is a tutorial and resource site for JavaScript developers. We focus on JavaScript full stack development and are currently creating tutorials on Tuesday and Thursday in our five-minute React series. Interested in the weekly updates? Sign up we have no junk, no advertising newsletters! Want to help develop, articles and tutorials for further support? Check out our CloseBrace pre-planning tutorial!
Thanks and notes
Thanks to James K. Nelson, Douglas Crockford, and Dori Smith for contributing their own thoughts to this article. I use their permission to extract their mail/DMS. Thanks also to Charlie Lindahl and Dillon Nichols for providing valuable feedback on the early draft.
[1] Much of this history comes from wikipedia’s JavaScript primer.
[2] Reference to John Resig’s blog on the 10th anniversary of jQuery.
Copyright: Kmiragaya / 123RF Stock Photo. Christopher Buecheler_ Modified