#why we use react js instead of javascript

[javascript]

How we wrote our own Service Worker

As we continue the process of reinvigorating Tumblr's frontend web development, we're always on the lookout for modern web technologies, especially ones that make our mobile site feel faster and more native. You could have guessed that we are making the mobile dashboard into a progressive app when we open-sourced our webpack plugin to make web app manifests back in August. And you would've been right. But to make a high quality progressive web app, you need more than just a web app manifest—you also need a service worker.

What is a service worker?

A service worker is a helper script that a page registers with the browser. After it is registered (some people like to also call it "installed"), the browser periodically checks the script for changes. If any part of the script contents changes, the browser reinstalls the updated script.

Service workers are most commonly used to intercept browser fetches and do various things with them. https://serviceworke.rs has a lot of great ideas about what you can do with service workers, with code examples. We decided to use our service worker to cache some JS, CSS, and font assets when it is installed, and to respond with those assets when the browser fetches any of them.

Using a service worker to precache assets

You might be wondering "why would you want to pre-cache assets when the service worker is installed? Isn't that the same thing that the browser cache does?" While the browser cache does cache assets after they're requested, our service worker can cache assets before they're requested. This greatly speeds up parts of the page that we load in asynchronously, like the notes popover, or blogs that you tap into from the mobile dashboard.

While there are open-source projects that generate service workers to pre-cache your assets (like, for example, sw-precache), we chose to build our own service worker. When I started this project, I didn't have any idea what service workers were, and I wanted to learn all about them. And what better way to learn about service workers than building one?

How our service worker is built

Because the service worker needs to know about all of the JS, CSS, and font assets in order to pre-cache them, we build a piece of the service worker during our build phase. This part of the service worker changes whenever our assets are updated. During the build step, we take a list of all of the assets that are output, filter them down into just the ones we want to pre-cache, and write them out to an array in a JS file that we call sw.js.

That service worker file importScripts()'s a separate file that contains all of our service worker functionality. All of the service worker functionality is built separately and written in TypeScript, but the file that contains all of our assets is plain JavaScript.

We decided to serve our service worker directly from our node.js app. Our other assets are served using CDNs. Because our CDN servers are often geographically closer to our users, our assets load faster from there than they do from our app. Using CDNs also keeps simple, asset-transfer traffic away from our app, which gives us space us to do more complicated things (like rendering your dashboard with React).

To keep asset traffic that reaches our app to a minimum, we tell our CDNs not to check back for updates to our assets for a long time. This is sometimes referred to as caching with a long TTL (time to live). As we know, cache-invalidation is a tough computer science problem, so we generate unique filenames based on the asset contents each time we build our assets. That way, when we request the new asset, we know that we're going to get it because we use the new file name.

Because the browser wants to check back in with the service worker script to see if there are any changes, caching it in our CDNs is not a good fit. We would have to figure out how to do cache invalidation for that file, but none of the other assets. By serving that file directly from our node.js application, we get some additional asset-transfer traffic to our application but we think it's worth it because it avoids all of the issues with caching.

How does it pre-cache assets?

When the service worker is installed, it compares the asset list in sw.js to the list of assets that it has in its cache. If an asset is in the cache, but not listed in sw.js, the asset gets deleted from the cache. If an asset is in sw.js, but not in the service worker cache, we download and cache it. If an asset is in sw.js and in the cache, it hasn't changed, so we don't need to do anything.

// in sw.js

self.ASSETS = [

  'main.js',

  'notes-popover.js',

  'favorit.woff'

];

// in service-worker.ts

self.addEventListener('install', install);

const install = event => event.waitUntil(

  caches.open('tumblr-service-worker-cache')

    .then(cache => {

      const currentAssetList = self.ASSETS;

      const oldAssets = /* Instead of writing our own array diffing, we use lodash's */;

      const newAssets = /* differenceBy() to figure out which assets are old and new */;

      return Promise.all([ ...oldAssets.map(oldAsset => cache.delete(oldAsset)), cache.addAll(newAssets)]);

  });

);

We launched 🚀

Earlier this month, we launched the service worker to all users of our mobile web dashboard. Our performance instrumentation initially found a small performance regression, but we fixed it. Now our mobile web dashboard load time is about the same as before, but asynchronous bundles on the page load much faster.

We fixed the performance regression by improving performance of the service worker cache. Initially, we naively opened the service worker cache for every request. But now we only open the cache once, when the service worker starts running. Once the cache is opened, we attach listeners for fetch requests, and those closures capture the open cache in their scope.

// before

self.addEventListener('fetch', handleFetch);

const handleFetch = event =>

  event.respondWith(

    caches.open('tumblr-service-worker-cache')

      .then(cache => cache.match(request)

      .then(cacheMatch => cacheMatch

        ? Promise.resolve(cacheMatch)

        : fetch(event.request)

      )

    )

  );

// now

caches.open('tumblr-service-worker-cache')

  .then(cache =>

    self.addEventListener('fetch', handleFetch(cache));

const handleFetch = openCache => event =>

  event.respondWith(

    openCache.match(request)

      .then(cacheMatch => cacheMatch

        ? Promise.resolve(cacheMatch)

        : fetch(event.request)

      )

  );

Future plans

We have lots of future plans to make the service worker even better than it is now. In addition to pre-emptive caching, we would also like to do reactive caching, like the browser cache does. Every time an asset is requested that we do not already have in our cache, we could cache it. That will help keep the service worker cache fresh between installations.

We would also like to try building an API cache in our service worker, so that users can view some stale content while they're waiting for new content to load. We could also leverage this cache if we built a service-worker-based offline mode. If you have any interest in service workers or ideas about how Tumblr could use them in the future, we would love to have you on our team.

- Paul / @blistering-pree

[npmjs]

JavaScript Usage by Industry

We’re continuing our analysis of the results of last winter’s JavaScript Ecosystem Survey, a survey of over 16,000 developers conducted by npm in collaboration with the Node.JS Foundation and the JS Foundation. Our second topic is How JavaScript is used across industries — and, more specifically, how different industries use certain JavaScript tools, frameworks, and practices. To read more about the methodology behind this survey, click here.

We asked about what industry our respondents worked in. 45% of users answered “tech”, revealing an underlying ambiguity in our question. For instance, if you work at Google, do you work at a tech company or an advertising company? What about at Microsoft, which many consider a tech company, but also has advertising and even hardware manufacturing arms? Next time, we’ll ask for more detailed information about industry concentrations.

“We asked about what industry our respondents worked in. The most common answer was “tech” at 45%”

Despite this, we still gathered some good data about how use of JavaScript varies by industry. The top industries were:

finance: 7%

advertising and marketing: 5%

education: 5%

entertainment: 5%

business support and logistics: 4%

healthcare: 4%

retail: 3%

government: 2%

manufacturing: 2%

There were meaningful differences across industries in how and why people use JavaScript. There were also some clear commonalities, not all of which we’re going to mention. But from a statistician’s point of view, the questions where all the industries answered very similarly are useful because it indicates the differences in other questions are “real” and not just random variation.

With 16,000 responses, even the single-digit groups per industry constituted enough data to make meaningful conclusions. We discarded answers from industries with less than 2% responses (i.e. less than 300 individual responses).

JavaScript tools

First, we asked about common tools: bundlers, linters, testing frameworks, transpilers, CSS preprocessors, and more.

Manufacturing across the board uses less of everything — only 51% of manufacturing respondents say they use a testing framework, compared to 75% in finance.

The explanation for this may lie in the answer to another question; “Where does the JavaScript you write run?” 15% of manufacturing developers say their code runs on embedded devices which is twice as much as any other industry. Embedded platforms often have intrinsic transpilers for JS, so you do not need to use your own and have no need for browser-specific optimizations that most of these tools provide.

“Manufacturing across the board uses less of everything — only 51% of manufacturing respondents say they use a testing framework, compared to 75% in finance.”

Put another way: hardware isn’t a browser. This view of manufacturing respondents is backed up by another question, in which 31% of manufacturing respondents say their code is put to use in IoT (Internet of Things). No other industry gets above double digits for that answer. This makes manufacturing an interesting set of answers across the board, as we’ll see.

Finance, on the other hand, uses everything the most. They are the most likely to use a bundler, second-most likely to use a linter (after healthcare), most likely to test, second-most likely to use a web framework (after retail), most likely to use a transpiler, and second-most likely to use a CSS preprocessor (after advertising). Finance just does all the things.

JavaScript frameworks

We’ve examined the popularity of JavaScript frameworks in the past. Our survey data provides another view into these preferences, and the results are enlightening.

Angular was a fairly popular choice across all industries, but strongest in finance. Developers in entertainment were the least likely to use Angular, their strongest preference being for React (65%).

React was the most popular framework in the survey overall, though with strong variations by industry. As mentioned, 65% of developers in entertainment chose it, but that fell to 46% in government and 38% in manufacturing. Manufacturing’s strongest choice for a framework was jQuery (52%), suggesting the industry is a late adopter. Government also had jQuery as its top pick at 52%.

Around 20% of developers in most industries reported using Vue, though it was notably more popular in advertising, with 34% of developers reporting it there.

“We also asked developers how they made decisions about choosing frameworks. Big majorities (60-90%) in every industry reported things like support, features, and stability being important, with little variation.”

Ember did not get a lot of mention from our respondents, with an average of 4% of developers reporting that they used it. Also in this range were Preact (5%), Hapi (5%), Next.js (5%), and Meteor (5%).

A surprisingly popular choice was Electron, which is obviously not a web framework at all but we included in our options. More than 20% of developers in every industry reported using Electron for some projects.

We also asked developers how they made decisions about choosing frameworks. Big majorities (60-90%) in every industry reported things like support, features, and stability being important, with little variation. Security was the lowest ranked concern for frameworks, averaging only 25%, though finance was most concerned at 30%. We’ll go more into attitudes to security later in this post.

Language choices

Obviously everybody in the survey uses JavaScript, but lots of respondents use another primary language as their back-end choice and there were noticeable variations by category.

Python was the choice of the unemployed. This sounds unflattering, but thanks to a poorly-phrased question on our part, the “unemployed” category includes people in full time education. Their questions (such as what level of schooling the respondent had completed) lend weight to the idea that the unemployed category was full of people who are still in school, so we believe Python is popular in education.

Java was the choice of the finance industry by quite a margin—41% versus 27% for the second most popular language in finance, .NET.

PHP was the choice of the advertising industry, again by a huge margin — 49% to 26% for Python, the second most popular. Why advertising companies choose PHP is unclear to us, but PHP is popular with advertising agencies putting together micro-sites. Furthermore, a question about company size showed that over 50% of advertising respondents worked at small companies (less than 50 people), so this category is probably dominated by small shops putting together these sorts of sites.

Our poorly-chosen “.NET” category (not really a language) was no industry’s first choice. Its strongest showing was in the manufacturing category at 33%, a very close second to Python at 34%. However, because we didn’t pick out C# and F# separately, it’s possible these results are skewed by people who use those languages, but don’t use .NET.

Ruby is a relatively unpopular option across all our respondents, chosen by less than 13% in all cases. Its weakest showing was in manufacturing, where only 3% chose it, and its strongest in education, where 13% did.

C and C++ were unsurprisingly most popular in the hardware-dominated manufacturing industry, at 9% and 18% of respondents respectively. C++ was more popular than C across the board. The retail industry is the least fond of C++, with only 4% of respondents reporting using it.

We also polled on Go, Swift, and Rust. Go was about 10% usage across the board, Swift was 3-5%, and Rust about 3% except in manufacturing, where it hit 7%.

Why do you choose JavaScript?

In general, people are pretty clear why they choose JavaScript: the huge ecosystem of libraries. An academic study of the same topic in 2013, An Empirical Analysis of Programming Language Choices (Meyerovich and Rabkin, 2013) exhaustively researched what makes developers choose programming languages and it reached the same conclusion. It’s not controversial to conclude that the modules in the npm registry are a major reason people choose JavaScript. However, people cited a number of other reasons and there were notable variations by industry.

Respondents who say they work in government were the least likely to report that they chose JavaScript for productivity gains, with only 51% saying so versus 60% in the finance industry, where this belief is strongest. Instead, government was most likely to believe that using JavaScript gave them performance gains: 31% of government respondents cite this, while in most other industries only 20-21% said this.

The advertising industry is the one most likely to say that developer satisfaction is a reason they choose to use JavaScript, with 50% of respondents saying so. This is notable since the advertising industry has a lot of PHP developers, and as we’ll see in a future analysis based on programming language choices, high satisfaction with JavaScript is a characteristic shared by most PHP developers.

“Across every industry, solid majorities (more than 90% in every case) expected to use JavaScript more or about the same amount as they had previously in the next 12 months.”

Cost savings as a reason for choosing JavaScript were most cited by respondents who work in finance (41%). This seems pretty logical, as finance is an industry that presumably can be relied upon to think of the costs of things.

The entertainment industry was the most likely to cite the size of the developer pool (41%) while the retail industry was most likely to say the ease of on-boarding new developers (40%) was their reason for choosing JavaScript. While JavaScript has a big pool of developers and we think on-boarding developers in JavaScript is pretty easy, it’s unclear why these industries in particular would note those advantages.

Finally, some people don’t get to choose what programming language they work in. This number was highest in government, at 21%.

Across every industry, solid majorities (more than 90% in every case) expected to use JavaScript more or about the same amount as they had previously in the next 12 months.

Attitudes to security

npm is making a big push to improve the security of the modules in the registry in 2018, so we asked our users about their attitudes toward security. You can see our previous post for a deeper analysis of attitudes to security, but there are some interesting variations by industry.

Firstly, everyone is concerned about the security of the code they write (87-90%) and of the open source code they use (73-79%). Developers who work in tech were the most likely to be concerned, but there wasn’t a lot of variation.

Majorities in every industry reported that they were dissatisfied with current methods of evaluating the security of code (51-60%). Advertising and entertainment were the most likely to say they were dissatisfied with available methods.

“Firstly, everyone is concerned about the security of the code they write (87-90%) and of the open source code they use (73-79%). Developers who work in tech were the most likely to be concerned, but there wasn’t a lot of variation.”

A whopping 90% of people working in education (non-students) were likely to be concerned about the quality of the code they wrote themselves. This was an interesting result as they were also the industry most likely to say they were doing nothing at all to assess security (33%):

The industry most likely to be actively doing something about security is the finance industry. They were the group most likely to participate in code reviews (81%), most likely to have external audits of their code (30%), and the most likely to be using automated scans of their code (52%). The tech industry was a close second to finance in all of these answers.

Private code

We explored the ways developers use and store private code.

Everybody reports having private code and GitHub is an extremely popular place to store it — 93% of the advertising industry report using it, with most industries in the high 80’s. Manufacturing was an outlier here, with only 75% of developers saying they used GitHub. We thought this was a strange result, but it was consistent; when asked how they discovered packages, developers in manufacturing were also the least likely to report using GitHub (14% versus 20% for other groups).

Developers also store private npm packages. Across all industries, about a third of developers said they had created private npm packages. However, their reasons for doing so varied.

“However, by far the most popular reason for everyone using private packages was the most obvious: the packages contain private IP. Majorities from 65% in education to 91% in manufacturing reported this as a reason for creating private npm packages.”

Developers sometimes use private modules to hold test projects which aren’t ready for release. This practice varies widely across industries, with 23% of developers in education saying they do this but only 8% in retail.

More common was keeping code private for release as open source later. Education was likely to do this, with 27% saying so, and government employees following close behind at 25%. Healthcare developers, who reported less engagement with open source, were the least likely to report this as a reason, at 9%.

A big reason for everyone to keep private packages was re-use by their co-workers — including majorities from 53% in finance and 67% in retail.

However, by far the biggest reason for everyone using private packages was the most obvious: the packages contain private IP. Majorities from 65% in education to 91% in manufacturing reported this as a reason for creating private npm packages.

Testing

Finally, we explored attitudes toward testing across the industries.

In keeping with its answers in every other category, finance was the most likely to report that they use a testing framework (88%). Government and manufacturing developers on the other hand were the least likely to use a testing framework, with only 68% of developers in both industries saying so.

Across every industry, the most popular testing framework choice was Mocha (50%), followed by Jasmine (33%) and Jest (19%). Unlike web framework choices, there was less variation between the popularity of testing frameworks across industries.

Conclusions

There were some fascinating differences across the industries. The advertising and entertainment industries often found themselves paired together in terms of practices. Finance was cautious and security-focused. Government and manufacturing were mostly on the opposite end of that scale, with lower reported use of best practices and modern tooling. Whether you’re in these industries or building products for developers in these industries, we hope these results help you get a better sense of the broader universe of JavaScript developers.

Thanks to everyone who took the survey. We’ll be providing more analysis in the near future, so stay tuned!

[webhawkstechnology-blog]

Why to upgrade to Angular 2

Introduction of Angular 2

Angular 2 is one of the most popular platforms which are a successor to Google Angular 1 framework. With its help, Angular JS developers can build complex applications in browsers and beyond. Angular 2 is not only the next or advanced version of Angular 1, it is fully redesigned and rewritten. Thus, the architecture of Angular 2 is completely different from Angular 1. This tutorial looks at the various aspects of Angular 2 framework which includes the basics of the framework, the setup of Angular and how to work with the various aspects of the framework. Unlike its predecessor, Angular 2 is a TypeScript-based, web application development platform that makes the switch from MVC (model-view-controller) to a components-based approach to web development.

Benefits of Angular 2

Mobile Support: Though the Ionic framework has always worked well with Angular, the platform offers better mobile support with the version 2. The 1.x version compromised heavily on user experience and application performance in general. With its built-in mobile-orientation, Angular 2.0 is more geared for cross-platform mobile application development.

Faster and Modern Browsers: Faster and modern browsers are demanded by developers today. Developers want Angular 2 stress more on browsers like IE10/11, Chrome, Firefox, Opera & Safari on the desktop and Chrome on Android, Windows Phone 8+, iOS6 & Firefox mobile. Developers believe that this would allow AngularJS codebase to be short and compact and AngularJS would support the latest and greatest features without worrying about backward compatibility and polyfills. This would simplify the AngularJS app development process.

High Performance: Angular2 uses superset of JavaScript which is highly optimized which makes the app and web to load faster. Angular2 loads quickly with component router. It helps in automatic code splitting so user only load code required to vendor the view. Many modules are removed from angular’s core, resulting in better performance means you will be able to pick and choose the part you need.

Changing World of Web: The web has changed noticeably and no doubt it will continue changing in the future as well. The current version of AngularJS cannot work with the new web components like custom elements, HTML imports; shadow DOM etc. which allow developers to create fully encapsulated custom elements. Developers anticipate with all hopes that Angular 2 must fully support all web components.

Component Based Development:  A component is an independent software unit that can be composed with the other components to create a software system. Component based web development is pretty much future of web development. Angular2 is focused on component base development. Angularjs require entire stack to be written using angular but angular2 emphasis separation of components /allow segmentation within the app to be written independently. Developers can concentrate on business logic only. These things are not just features but the requirement of any thick-client web framework.

Why to upgrade to Angular 2 ?

Angular 2 is entirely component-based and even the final application is a component of the platform. Components and directives have replaced controllers and scopes. Even the specification for directives has been simplified and will probably further improve. They are the communication channels for components and run in the browser with elements and events. Angular 2 components have their own injector so you no longer have to work with a single injector for the entire application. With an improved dependency injection model, there are more opportunities for component or object-based work.

Optimized for Mobile- Angular 2 has been carefully optimized for boasting improved memory efficiency, enhanced mobile performance, and fewer CPU cycles. It’s as clear of an indication as any that Angular 2 is going to serve as a mobile-first framework in order to encourage the mobile app development process. This version also supports sophisticated touch and gesture events across modern tablet and mobile devices.

Typescript Support- Angular 2 uses Typescript and variety of concepts common in back-end. That is why it is more back-end developer-friendly. It's worth noting that dependency injection container makes use of metadata generated by Typescript. Another important facet is IDE integration is that it makes easier to scale large projects through refactoring your whole code base at the same time. If you are interested in Typescript, the docs are a great place to begin with. Moreover, Typescript usage improves developer experience thanks to good support from text editors and IDE's. With libraries like React already using Typescript, web/mobile app developers can implement the library in their Angular 2 project seamlessly.

Modular Development- Angular 1 created a fair share of headaches when it came to loading modules or deciding between Require.js and Web Pack. Fortunately, these decisions are removed entirely from Angular 2 as the new release shies away from ineffective modules to make room for performance improvements. Angular 2 also integrates System.js, a universal dynamic modular loader, which provides an environment for loading ES6, Common, and AMD modules.

$scope Out, Components in- Angular 2 gets rid of controllers and $scope. You may wonder how you’re going to stitch your homepage together! Well, don’t worry too much − Angular 2 introduces Components as an easier way to build complex web apps and pages. Angular 2 utilizes directives (DOMs) and components (templates). In simple terms, you can build individual component classes that act as isolated parts of your pages. Components then are highly functional and customizable directives that can be configured to build and specify classes, selectors, and views for companion templates. Angular 2 components make it possible to write code that won’t interfere with other pieces of code within the component itself.

Native Mobile Development- The best part about Angular 2 is “it’s more framework-oriented”. This means the code you write for mobile/tablet devices will need to be converted using a framework like Ionic or Native Script. One single skillset and code base can be used to scale and build large architectures of code and with the integration of a framework (like, you guessed it, NativeScript or Ionic); you get a plethora of room to be flexible with the way your native applications function.

Code Syntax Changes- One more notable feature of Angular 2 is that it adds more than a few bells and whistles to the syntax usage. This comprises (but is not limited to) improving data-binding with properties inputs, changing the way routing works, changing an appearance of directives syntax, and, finally, improving the way local variables that are being used widely. One more notable feature of Angular 2 is that it adds more than a few bells and whistles to the syntax usage. This comprises improving data-binding with properties inputs, changing the way routing works, changing an appearance of directives syntax, and, finally, improving the way local variables that are being used widely.

Comparison between Angular 1 and Angular 2

Angular 1

In order to create service use provider, factory, service, constant and value

In order to automatically detection changed use $scope, $watch, $scope,  $apply, $timeout.

Syntax event for example ng-click

Syntax properties for example ng-hid, ng-checked

It use Filter

Angular 2

In order to create service use only class

In order to automatically detection changed use Zone.js.

Syntax event for example (click) or (dbl-click)

Syntax properties for example [class: hidden] [checked]

It use pipe

How to migrate Angular 1 to Angular 2

It is a very simple and easy task to upgrade Angular 1 to Angular 2, but this has to be done only if the applications demand it. In this article, I will suggest a number of ways which could be taken into consideration in order to migrate existing applications from Angular 1.x to 2. Therefore, depending on the organizational need, the appropriate migration approach should be used.

Upgrading to Angular 2 is quite an easy step to take, but one that should be made carefully. There are two major ways to feel the taste of Angular 2 in your project. Which you use depends on whatever requirements your project has. The angular team have provided two paths to this:

ngForward

ngForward is not a real upgrade framework for Angular 2 but instead we can use it to create Angular 1 apps that look like Angular 2.

If you still feel uncomfortable upgrading your existing application to Angular 2, you can fall to ngForward to feel the taste and sweetness of the good tidings Angular 2 brings but still remain in your comfort zone.

You can either re-write your angular app gradually to look as if it was written in Angular 2 or add features in an Angular 2 manner leaving the existing project untouched. Another benefit that comes with this is that it prepares you and your team for the future even when you choose to hold onto the past for a little bit longer. I will guide you through a basic setup to use ngForward but in order to be on track, have a look at the Quick Start for Angular 2.

If you took time to review the Quick Start as I suggested, you won't be lost with the configuration. SystemJS is used to load the Angular application after it has been bootstrapped as we will soon see. Finally in our app.ts, we can code like its Angular 2.

ngUpgrade

Writing an Angular 1.x app that looks like Angular 2 is not good enough. We need the real stuff. The challenge then becomes that with a large existing Angular 1.x project, it becomes really difficult to re-write our entire app to Angular 2, and even using ngForward would not be ideal. This is where ngUpgrade comes to our aid. ngUpgrade is the real stuff.

Unlike ngForward, ngUpgrade was covered clearly in the Angular 2 docs. If you fall in the category of developers that will take this path, then spare few minutes and digest this.

We'll also be writing more articles on upgrading to Angular 2 and we'll focus more on ngUpgrade in a future article.