“Will WebAssembly replace JavaScript by 20XX?” This is one of those “sensationalizing” news of the moment, right? But still: if we were to run a WebAssembly vs JavaScript performance comparison, which one would be the winner?
And would we have the same winner for different implementations?
We're all looking forward to the future of web development now that WebAssembly has come around to “tempt” us with near-native performance to the browser.
Yet, most of us still write code in JavaScript, despite the predictions of its “imminent extinction”. And there still are use cases where JS outperforms WASM.
So, let's find out:
exactly when JavaScript performs better that WebAssembly
how WebAssembly works and what makes it such a great fit for the web
whether WASM is, indeed, faster than JavaScript and when precisely
1. The Rise of WebAssembly: The First Alternative to JS for Web Development
Just think about it:
We've been having JavaScript as the one and only programming language to be used natively in web browsers and then... WebAssembly stepped in.
“But what is WebAssembly more precisely?” Is it a really an assembly language, like its name suggests? Well, here's a hopefully clear enough definition for you to ponder on:
WASM is a new type of code — with a small-sized fast binary format — for modern browsers. A “compile target”, if you wish.
One that you get to use for compiling any programming language (JS here included).
And NO:
It is not an assembly language, it's not built for a specific machine.
And no, you don't write code in WebAssembly: you use it to compile any given language.
What it does is compile higher level languages and then run those web apps in the browser a lot faster than JavaScript (due to its lightweight, low-level binary format, remember?)
2. WebAssembly vs JavaScript: Essential Differences
Now that we've seen what WebAssembly is and what it is not, let me briefly outline the key features that set our 2 “contestants” apart:
JavaScript:
it's dynamically typed
it's highly flexible
it's delivered in human-readable code
WebAssembly:
it's just fast(er)
it's delivered via a small-sized binary format
it's strongly typed
3. How Does WebAssembly Work? What's Behind Its “Near-Native Performance”?
“Why is WebAssembly faster? How does it work?”
Here's WASM in action:
you, the developer, write the code for your web app (in any programming language)
next, you compile it into WebAssembly bytecode
then, this code is run in the web browser, where it turns into native machine code and... executed.
And it gets loaded, parsed, and executed way faster compared to JavaScript.
Why?
Because its binaries are lighter than the textual JS files and, therefore, faster to decode...
4. 3 Performance-Intensive Use Cases for WebAssembly
Before I run an “enlightening” WebAssembly vs JavaScript performance comparison, let me highlight the use cases where WASM “shines supreme” as a web performance “booster.
First of all, when you say “common uses cases for WebAssembly”, think about all those performance-critical cases:
video editing
3D rendering
video games
music streaming
encryption
image recognition
WebAssembly's built as a target for writing in-browser software.
In short: think of all those use cases where JavaScript would usually struggle to reach the needed level of performance.
And now, let's get specific:
porting a desktop app to the web: WebAssembly supports those scenarios that go beyond GUI delivered via HTML
high-performance code already existing in a targetable language: deploy it as a WebAssembly module; here, you could keep the less performance-critical elements in JavaScript
high-performance code to be written from the ground up: where, obviously, asm.js is not a suitable choice
In short:
with WebAssembly there's only one step to complete — the compilation step — for running your app in any browser; portability is one of its main strengths
if top performance's critical for your web app, you might want to consider WebAssembly as an alternative to JavaScript
5. WebAssembly vs JavaScript: Performance Comparison
Now that we've settled that WebAssembly is usually faster than JS, let's:
find out when precisely. When does WASM outperform JS?
dig some more into the load of features that enable WebAssembly to perform better
discover all those use cases where JS can't be “dethroned”
5.1. WebAssembly's binaries are faster to download and to execute
“Why?” Because they're smaller than JS's textual files.
By comparison, JavaScript would need to:
parse
compile
optimize
… the code before executing it in the browser.
Although it's:
easy to write
doesn't need to get compiled ahead (being a dynamically typed language)
… JavaScript still needs more time to do all the needed work before executing the code.
5.2. With WebAssembly, memory gets managed manually
In other words: there's no garbage pile-up to impact performance.
5.3. WebAssembly reduces the initial load time
Any WebAssembly vs JavaScript performance analysis would point out that WASM comes with some significant time-parsing improvements.
Here's why it decodes much faster than JavaScript:
it has a binary format
it's statically typed (it doesn't need to “guess” what types should be used)
it performs its optimization work in advance while compiling the source code
By comparison, JavaScript would need to:
first turn text into a data structure (or i.e “abstract syntax tree” or AST)
then, turn that AST into binary format
Just think of the JS-heavy web apps striving to parse all that data in due time.
WebAssembly is proven to score 3 times better at load time.
5.4. JavaScript performs better on smaller array sizes
In a WebAssembly vs JavaScript “duel” WASM would always perform better on larger array sizes, powering extremely fast web applications.
5.5. WebAssmebly files load faster once in cache
The moment they get stored in the cache of the browser, WASM files are easier to load, compared to JS's source code.
5.6. JavaScript often performs better during execution
Once fully optimized, WebAssembly is slower when executing code in the browser.
And this is partly (some) browsers' “fault”:
On Microsoft edge, for instance, WebAssembly executes terribly slowly.
5.7. WebAssembly doesn't really “outshine” JS in terms of run-time performance
6. What Next? Will WebAssembly Become More Than Just a Web-Based Solution?
Well, that's the goal, at least:
To go beyond its common use in web browsers.
To upgrade it from a web-based solution to the go-to option for:
desktop apps
mobile apps
other execution environments
Moreover, one of the “forecasts” is that we'll no longer talk about a “WebAssembly vs JavaScript” rivalry in the future, but about a cohabitation of the 2:
You'll still be able to write your code in JavaScript all while leveraging the speed that WebAsssembly brings to the table: improved frameworks and libraries.
“Will WebAssembly replace JavaScript by 20XX?”
I'm certain that it won't: JS is still a convenient and fast choice for too many tasks.
Yet, we will witness a successful collaboration of the 2.
Photo by Chris Liverani on Unsplash.
Silviu Serdaru / Dec 07'2018
It's a robust, flexible and admin feature-packed CMS, there's no point in denying it. And yet: Drupal (still) lacks a modern UI that would make building rich web content — such as landing pages — a breeze. But there is hope: the Gutenberg editor has been ported over, promising a better editing experience in Drupal 8.
The team behind this daring project? Frontkom, a Norwegian digital services agency that:
refused to just sit and wait (for a year or two) for the in-progress initiative of modernizing Drupal's admin UI to grow into a core solution
decided to capitalize on their experience in working with the Gutenberg page builder
… and on this content editor's open source nature, too
… to bring it over to Drupal 8
Now, if you're determined to improve the editorial UX on your Drupal site, to “spoil” your editors with a modern, intuitive and flexible admin UI, keep on reading...
1. The Drupal Gutenberg Project: Aiming for a Modern Admin UI in Drupal 8
And by “modern” I do mean the opposite of the Panels & Paragraphs & Layout combo solutions currently available for editing text in Drupal.
Solutions that only manage to make the entire workflow... discouragingly complex.
Especially if it's rich web content that editors need to create via the Drupal admin UI.
And this is precisely the context where the Drupal Gutenberg project was born: Drupal desperately needed/needs a modern, JavaScript-based admin UI.
With WordPress 5 users already enjoying this fancy content editor and the Frontkom team's having gained experience in using it, the idea of porting it to Drupal started to form:
"Why wouldn't we make it possible for Drupal users, too, to benefit from this content editor?"
And here are some of the original Gutenberg project's features that lead them into thinking that, once ported, the editor would significantly improve the editing experience in Drupal 8:
it's (highly) decoupled
it's open-source
it's React.js-based
it provides a simplified, smooth and cool functionality-packed admin UI
it's Medium and Squarespace's inspired
it turns the creation of complex landing pages into a breeze
Page editing in Drupal 8 wasn't going to be the same again!
Their initiative turned into a Drupal 8 module — Gutenberg Editor — currently still an experimental one.
Curious enough?
The first step to satisfy your curiosity is to take a look at their live demo: an interactive glimpse into the Gutenberg text editor implemented in Drupal 8.
2. The New Gutenberg for Drupal: Top Features Improving the Editing Experience in Drupal 8
2.1. All the Page Elements Are... Content Blocks
That's right, the team behind this project capitalized on the “everything is a block” Drupal 8 concept when adapting the Gutenberg UI to Drupal.
The result?
Both the Drupal core blocks and 20+ Gutenberg blocks are available in the resulting admin UI.
Basically, a Drupal 8 editor can insert into the web page that he/she's creating any of the core Drupal blocks and of the Gutenberg blocks of choice.
Speaking of which, let me point out just a few:
Heading
Image gallery
Auto embedded social posts
Buttons
Custom Drupal blocks
Layout blocks
Needless to add that you're free to enrich this list with your own custom blocks, too.
2.2. Easy Switch from Visual to Code Editor
That's right, the Gutenberg UI enables you/your editors to quickly switch to code editor — opening up a neat markup — and to apply any needed tweaks on the output.
2.3. Positioning Content Is Straightforwardly Intuitive
Editors get to select precisely where they want to position different types of content on a page.
And the very same results that they generate while in the Gutenberg admin UI get instantly reflected on the live web page, as well.
And there's more! More great admin features improving editing experience in Drupal. For instance:
Full control over font sizes and colors; tweaking them becomes a breeze with the new editor.
2.4. There's a Blocks Search Box
And not only that:
using this search box you can track down precisely those content blocks that you need to add to your page
but you can access them inline, as well, using “/”.
2.5. Full Control of the Layout
Another great thing about the content blocks available in the Gutenberg UI is that: they can have child blocks, too!
This way, it'll get unexpectedly easy for your editors to split their used blocks into columns on a grid.
2.6. Auto Embedded Social Posts/Videos
And all it takes is pasting their URL.
The Story of a Real Challenge: Making Gutenberg CMS-Agnostic
Open source, but not fully CMS-agnostic...
The team behind the Drupal Gutenberg project had to come up with a suitable solution for this challenge. And they did come up with a multi-step solution to make the fancy text editor work in Drupal 8, as well:
first, they created a fork and removed the WordPress specific features
they used the Gutenberg editor as a dependency
next, they set up a standalone NPM package
then they built the Gutenberg Editor module
In short: a fork of the initial Gutenberg project is still maintained while being used as a dependency of the new Drupal 8 module. Therefore, each time Gutenberg gets an update, the corresponding Drupal module, too, gets a new release.
Now, digging deeper into the project's architectural design, we discover 2 elements that the team had to re-write for Drupal:
the URL defining the editor routes (edit page route, new page route, preview page route)
the API-request, now configured to “talk to” Drupal (instead of the WordPress API)
How does the new module work?
as a text editor, which can be easily enabled for each content type
all it takes is a long text field for it to work: it replaces the node edit UI for that specific content type
Note: the Frontkom team also “promises” us to re-use many of the Drupal-specific stylings for the editor's UI elements in order to add a familiar Drupal feeling to it.
What Next? What's The Project Roadmap
Ok, so what we know for sure now, regarding this ambitious initiative turned into a Drupal module is that:
the Drupal Gutenberg module is downloadable, yet still experimental (for developer use only)
the team's still working on the project, implementing new features and functionalities aimed at making it feel more... Drupal native
the final version will be presented to the eager/intrigued/curious/skeptical Drupal users and developers in the coming months
The END! Can't hide that I'm more than curious what you think about this contrib solution for improving the editing experience in Drupal 8:
Are you looking forward to using it, hoping that this editor would make up for the inconvenience of working with Drupal's current admin UI?
Are you skeptical about the perspective of being tied up to a WordPress page builder?
Adriana Cacoveanu / Aug 17'2018
Thinking to convert your website to a progressive web app? And why shouldn't you?
Since the benefits are obvious:
you “end up” with a website behaving like a native web app
… one that works offline (and “offline” is the new black these days, right?), having its own home-screen icon
improved user experience: not only that your site goes mobile, but users don't even need to get your site-turned-into-an-app downloaded from an app store and then installed on their devices
Furthermore:
Putting together a PWA out of a regular website (or blog) is unexpectedly easy! Basically, any site/blog can be turned into a progressive web app...
No need to let yourself discouraged by terms such as:
service workers
web app manifest (or “manifest.json)
… for the whole process is actually far less complex than it sounds.
Here, see for yourself: go through the 3 essential steps it takes to convert your website to a progressive web app:
But First: All You Need to Know About PWAS— Benefits & Common Misconceptions
A succinct and clear enough definition of progressive web apps would be:
A PWA is a website that behaves like a native mobile app once visited on a mobile device.
Whereas a more detailed and comprehensive one would go something like this:
A PWA is a sum of modern web capabilities (and basic mobile capabilities) that enable users to save it on their own mobile devices (thus enjoying a native app-like experience) and access it offline, too.
And now, without getting into the old “native mobile app vs PWAs” debate, let me point out to you some of progressive web apps' most “luring” benefits:
as compared to native apps, the setup process, on users' end, is significantly simplified: PWAs get instantly installed on their home screens, with no need to visit an app store for that
they can get accessed offline, as well, via the home screen icon (a huge step forward from responsive web design)
installation is conveniently lightweight: a few hundred KB
essential files get cached locally (needless to say that this makes them faster than the standard web apps)
they feature modern web capabilities: push notifications, cameras, GPS
updates are run automatically, with no user interaction
not only that they work offline, too, but once the network connection is restored, they synchronize the data
And now, before we virtually convert your website to a progressive web app, let's go, briefly, through some of the most common misconceptions about PWAs:
a. A progressive web app is literally an... “application”.
Not necessarily:
A progressive web app can be a blog, an online shop, a collection of... dog memes, you name it.
Do not take the term “application” too literally when referring to PWAs. It's more of a concept, a code optimization technique which, once leveraged, "turbocharges” your app-like website or blog to deliver content faster.
b. Progressive Web Apps Are Developed Specifically for iOS or Android.
On the contrary! Probably one of PWAs' “hardest to resist to” advantage is that:
They're platform-independent.
So, you don't need to:
develop separate codebases
comply with platform-specific submission guidelines
c. Your Site Has to Be a JS-Based Single Page One So You Can Turn it Into a PWA.
Nothing of that sort!
If you're currently running... something on the web (be it a set of static HTML files), then you can easily make a PWA out of it!
And now, let's go straight to the 3-step set up process of a PWA out of your regular website:
Step 1: Go HTTPS to Convert Your Website to a Progressive Web App
There's no way around it: the HTTPs protocol is the ONLY way to go when it comes to progressive web apps!
All data exchanges need to be served on a secure domain: over an HTTPs connection!
And how do you switch from HTTP to HTTPs? You get yourself an SSL certificate from a trusted authority.
Now, there are 2 ways to get hold of it:
if your site runs on your own server (or at least you have root access to your server), consider setting up the LetsEncrypt certificate.
if your website runs on a shared hosting, then both the process and the cost of your SSL certificate (for yes, there will be a monthly or an annual fee) depends greatly on your provider.
Step 2: Create a Web App Manifest
“But what is a web app manifest?”, you might ask yourself.
A JSON text file that contains all the meta data of your PWA: description, scope, start_url, name, images, display, short_name...
It's this information that will let browsers know how precisely they should display your app once saved as a home-screen icon.
Now, before I go ahead and share a working example with you — one including the must-have entries of any web app manifest — I should also highlight that:
A link to this JSON text file should be placed in the <head> of all your PWA's pages:
<link rel="manifest" href="/manifest.json">
That, of course, after you've:
entered all the information about your PWA
copied the manifest.json
created a new “manifest.json” file in the root directory of your site
and pasted it there
It should be served with:
Content-Type: application/json HTTP header or
a Content-Type: application/manifest+json
And here's a “sample” piece of code:
{
"name": "My PWA Sample App",
"short_name" : "PWA",
"start_url": "index.html?utm_source=homescreen",
"scope" : "./",
"icons": [
{
"src": "./android-chrome-192x192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "./android-chrome-512x512.png",
"sizes": "512x512",
"type": "image/png"
}
],
"theme_color": "#ffee00",
"background_color": "#ffee00",
"display": "standalone"
}
Once the “Manifest” section of the Chrome's Development Tools Application tab has validated your JSON file, it will generate an “Add to home screen” link to be accessed on all desktop devices.
Tip: as you convert your website to a progressive web app you don't necessarily need to configure the manifest.json file yourself — with all its different images sizes, meta tags etc. Instead, if you want to make it quick, you can just make a 500x500 sized image of your PWA and then rely on Real Favicon Generator to create all the needed icon sizes and a manifest file for you!
And this is just one of the generators you could use!
Step 3: Set Up Your Service Worker
This is where the “true power” of your PWA lies:
A service worker is a JavaScript file, placed in your app's root, that plays the role of a “middleman” between the browser and the host. The one which, once installed in the supported browsers, intercepts and responds to the network request in different ways.
Note: in most cases, it's for caching all the static files, so that our PWAs can function offline, too, that we use service workers.
Now that we've seen what a service worker is, here's how you create one as you convert your website to a progressive web app:
a. You get it registered first things first.
For this, just run this code in the JS file on your site:
if ('serviceWorker' in navigator) { // register service worker navigator.serviceWorker.register('/service-worker.js'); }
Practically, it will check whether the browser does support Service Workers and, if it does, it registers your Service Worker file.
Note: NEVER call this file, inside your website, like this:
<script src="./service-worker.js"></script>
b. If you do not need your PWA to work offline, too, just set up an empty /service-worker.js file.
Users will just be notified to install it on their devices!
c. Once you've registered your Service Worker, generate your Service Worker file, too.
For this, just run this command in your terminal:
$ npm install --global sw-precache
Next, go ahead and run it on your website directory:
$ sw-precache
Et voila! You will have generated a service-worker.js including the service worker contents.
Test It Out!
At this stage of the "convert your website to a progressive web app" process, you should:
check whether your service worker got properly registered and installed on Chrome
run a performance audit on your PWA, using Chrome's Lighthouse Extension
For the first operation, go through these 3 basic steps here:
press F12 to open your Chrome Dev Tools
click on the “Application” tab
next, on the sidebar, select “Service Workers”
Then, check whether your service worker has been properly activated and is running normally:
Just tick the “Offline” checkbox and try reloading. Does your PWA-site still display its content, even when there's no internet connection?
Now let's run an audit using Chrome's dedicated testing tool, Lighthouse:
press F12 again to visualize the Chrome Dev Tools
select the “Audits” tab
then select “Perform an audit”
check all the suggested checkboxes
and finally, run the audit
And here's how the generated report would look like:
The END! This is how you convert your website to a progressive web app in 3 steps:
enabling HTTPS
configuring your web app manifest
creating your service worker
See? Any website can be turned into a PWA and you don't need to be a senior developer to do it.
Check out our development services for Magento websites in Vancouver.
Silviu Serdaru / Jul 24'2018
Sorry to disappoint you, but: there's no such thing! No such thing as “the best way to style React components”. Or “the most effective approach” or “the currently best option” for styling reusable components within your application.
What you do have, instead, is:
“The most popular or commonly-used ways of styling components!”
4 of them, actually.
And rating one of these approaches as “the best” is totally up to you:
to your personal preferences
to your React app's level of complexity
to what precisely it is that you need to style in your React project
and to your feature needs
Is it just a few style properties that you need to add? Then the inline styling approach suits your “component styling scenario” perfectly.
Or maybe it's a more complex React app that you're working on? In this case, you might want to go for the classic approach: using CSS classes and stylesheets and tying them all together with webpack.
But let's just put each of the 4 popular ways of styling React components into the spotlight and clear the picture for you a bit more!
I'll be highlighting each option's main advantages and drawbacks, so you can knowingly decide which one's the best option for you.
1. The Classic Approach: Using Regular CSS Stylesheets
You always have classes and stylesheets to rely on when it comes to styling. Simply tie them all with webpack after you've imported CSS file:
import './DottedBox.css'
… ensuring, this way, that you have a separate CSS file for each one of the components to be styled.
The main advantages of this common approach?
it'll then be easier for you to move between your CSS and the browser
it will streamline overriding or MVT in case you'll need to go in that direction
Yet, there's also a bit discouraging drawback to this approach to styling React components:
Do expect to face all the “standard” CSS problems: potential conflicts between definitions and mutual classes, attribute inheritance (both good and... bad)...
2. CSS Modules
And before we delve into the:
“why” you might rate using CSS modules as “the best way to style React components”
“how” to leverage their styling capabilities
... let us try to define them:
They're CSS files where all animation and all class names get automatically scoped.
Moroever, CSS modules help you “keep things clean” when it comes to all the previously mentioned problems that CSS stylesheets can challenge you with.
They make the most efficient approach to styling React components when you're dealing with complex applications.
And now, here are the steps to take for styling your reusable components using CSS modules:
import CSS file: import styles './DashedBox.css'
next, access className as you access to the object
And here you have 2 options at hand:
:local(.className) if/when you opt for create-react-app due to webpack configurations
.className in case it's your own React boilerplate that you're using
“OK, but how do I make my CSS modules work with Webpack now?”
A legitimate question that you might be asking yourself right now.
Here's how:
you simply include the modules early mentioned
next add the loader here below to your webpack.config.js file:
. . .
{
test: /\.css$/,
loader: 'style!css-loader?modules&importLoaders=1&localIdentName=[name]__[local]___[hash:base64:5]'
}
. . .
3. Styled Components: Is This the Best Way to Style React Components?
“It is if working with class names to compose stylesheets is not really... your thing.”
Take it as a more “non-traditional” way of styling components, where you:
Create encapsulated styles and integrate them with the props of your components. In other words: instead of using className, you'd be using style attribute.
And styled-components — a JavaScript and CSS “combo — are no more than a library enabling you to use component-level styles within your React app.
Or, you can also see them as a “wrapper component”: mapped to HTML tags in order to style itself and its child elements.
This way, you can easily write regular CSS in your JS file.
The main advantages?
you get to store all the styling within the component
… to have separate and reusable UI for your React stateful/stateless components
… to build “isolated” components
And now, let me take you through all the steps required for leveraging this library's styling capabilities:
fist, just install the library itself: npm install styled-components –save
next, set up a variable by selecting a specific HTML element, to store your style keys const Div = styled.htmlElemnet`color: pink`
and finally, use that variable's name as a wrapper <Div></Div> type of React component
4. Inline Styling
This might just be the best way to style React components for you if it's only a few style properties that you need to add.
Don't expect for inline styles to be specified as a string in React:
They're not! Instead, they're mentioned with an object:
whose key is the style name's camelCased version
whose value is usually a string, the style's own value, actually
And you have 2 options at hand for “triggering” the styling capabilities with this approach:
you create a variable storing style property and get it sent through to the element like style={nameOfvariable}
you pass the styling — style={{color: 'pink'}} — directly
Still, don't get overly “enthusiastic” about using this approach to styling! At least not until you've taken note of all the challenges that it presents, as well (and there are quite a few):
you won't be able to use pseudo-classes, one of the core features of CSS (:active, :hover, :focus etc.)
expect duplication in markup each time you'll use a specific component: you won't be having your styles in your JS only, meaning that doing server-side rendering will lead to duplication, to using repetitive rules and the same style code for multiple components
you won't get any media queries: you're left with the solution of using a JS approach for “juggling with” different screen variations
and you can't use vendor prefixes, nor override a rule on the very same selector
In a few words: using inline styling might just not be the best way to style React components if:
... It's a UI-heavy, complex application that you're working on and this is due to the approach's highly restrictive usage.
Nevertheless, if you still consider that this option suits your preferences and your app's feature needs best, go for it! You could always use a library such as React JSS, Readium, React style to deal with the above-mentioned inline styling limitations.
The END! These are 4 most widely-used ways of styling components in React, along with their key benefits and their most discouraging drawbacks.
Which one would you rate as “the best way to style React components” according to your personal preferences and to your current app's “needs” in terms of styling capabilities?
Adrian Ababei / Jun 14'2018
“Learn from your mistakes” should be every developer's life mantra. But that doesn't mean that they should be all your mistakes, right? With a list including the most common Angular mistakes at hand, you'd get to narrow down the number of possible pitfalls that you risk falling into to the... uncommon, the less predictable ones.
So, what are the traps that Angular developers fall into most often as they build their applications?
We've run our own "investigations" for you:
gone through the code examples on the web
ran an inventory of the most frequent questions on StackOverflow
looked over some of the issues that we've knocked our heads against while working on our own Angular projects
… and trimmed down our list to 5 most frequent mistakes that Angular developers make:
1. ngOnChanges vs ngDoCheck: Misunderstanding When the ngDoCheck Gets Triggered
"I have used OnPush strategy for my component and no bindings have changed, but the ngDoChecklifecycle hook is still triggered. Is the strategy not working?"
I bet that you've stumbled across this question (maybe put into different words) on various developer forums. It could easily win any “popularity” test there since it keeps coming up again and again.
But, before we give it a straight answer and settle this matter for good, let's focus on these 2 “change detecting” lifecycle hooks in Angular. And see where the problem stems from:
As you well know it, AngularJs has the watch feature, which “alerts” you whenever a value changes. Angular, on the other hand, has replaced the watch and scop feature with component inputs as properties. Moreover, it has added the ngOnChanges lifecycle hook, as well.
And here's where things get “tricky” and risk to turn into the trap that many Angular developers fall into:
The OnChanges event doesn't emit if/when a deep field of the input property changes. Hence, the value of the input is the reference of the object.
How do you approach this problem? You have several methods at hand, in fact, but I'm going to focus on the most common one:
Using the ngDoCheck lifecycle hook once you run the change detection process!
Now here's the answer that I've promised, to the above-mentioned common developer question:
The onPush strategy for detecting changes in Angular does work: the hook is triggered by the design itself!
Note: another ridiculously frequent mistake that developers make is to take "Angular" for "AngularJS"! Be better than that: the term "AngularJS" should be used only when you refer to the old Angular and to Angular 1, while Angular 2/2+ 4 and 5 is just... "Angular". Mind you don't delve deep into this confusion yourself, too!
2. Forgetting to Unsubscribe: One of the Most Common Angular Mistakes
“Forgetting” or simply ignoring this issue.
And you have no “excuse”, you know, for overlooking to clean up your subscriptions in Angular. Considering that there are methods and libraries developed precisely for handling these unsubscriptions once you've finished using an event or an observable in JavaScript.
Why does this “clumsiness” risk to grow into a major issue? Because lingering subscriptions cause memory leaks in your system.
And when it comes to the unsubscription process, there are 2 scenarios:
you trigger the OnDestroy lifecycle hook if it's in a component that you've subscribed in
you initiate the lifecycle hook yourself if it's a service that you've subscribed in (since, in this case, there's no available hook for you to fire)
To recap: Remember to unsubscribe when you no longer use a service/component!
3. The Wrong Use of Providers
One of Angular's (compared to AngularJS) key improvements is its Hierarchical Dependency Injection, agree?
This means that now you're free to instantiate a service several times (services used to be singletons back in the AngularJS's “glory days”, remember?).
Now that being said, let's have a look at a more than likely scenario:
Imagine yourself fetching your heroes using a heroes service:
@Injectable()
export class HeroesService {
heroes: Hero[] = [];
constructor(private http: Http) {
this.http.get('http://give-me-heroes.com').map(res => {
return res.json();
}).subscribe((heroes: Hero[]) => {
this.heroes = heroes;
});
}
getHeroes() {
return this.heroes;
}
}
Nothing unexpectedly wrong till here:
the data is being fetched in the constructor
there's also a getHeroes method for retrieving the heroes
Now, let's take a look at the hero component, too:
@Component({
selector: 'hero',
template: '...',
providers: [HeroesService]
})
export class HeroComponent {
constructor(private heroesService: HeroesService) {}
}
@NgModule({
declarations: [HeroComponent]
}
export class HeroesModule { ... }
As you can see, first the HeroComponent declares the HeroesService provider in the @Component.providers array, next it incorporates it in the constructor.
All well and good till you realize that each HeroComponent instance instantiates a new instance of the HeroesService.
To put it more simply:
Your HeroesService will be fetching the data (by HTTP request) several times, for each and every HeroComponent instance!
And this is due to the Hierarchical DI in Angular.
The solution for avoiding this issue — no doubt one of the most common Angular mistakes?
Declaring the service in the @NgModule.providers instead:
@Component({
selector: 'hero',
template: '...'
})
export class HeroComponent {
constructor(private heroesService: HeroesService) {}
}
@NgModule({
declarations: [HeroComponent],
providers: [HeroesService]
}
export class HeroesModule { ... }
There! The provider will now be instantiated once and for all. “For all” the HeroComponent instances I mean.
“How come?” You might ask yourself.
Because the provider (declared in the NGModule now) is a singleton now. Therefore all the other modules can use it.
4. Manipulating the DOM Directly
Although I've already said this about another mistake from this list, I now tend to consider this one here instead as being one of the most common Angular mistakes:
Manipulating the DOM directly; oftentimes from the controller itself!
And this is one of those top 10 Angular mistakes that any developer stands a high risk of making. Since manipulating the DOM is such a common task when using this platform:
you might need to render SVG
you might need to refresh a page's title based on a context change
you might need to set the focus on a control after a validation error
… and the list of possible situations goes on
Then... you fall right into it: you take the easy way out and hack the DOM directly!
Now what I feel like pointing out it here is that:
Angular's grown from a web framework into a platform!
And this can only mean that you're now free to decouple your Angular application's codebase from the renderer and:
have your app executed in on the server
… in the browser
… as a native app
And decoupling opens the door to other possibilities for you to explore and to tap into, such as using web workers or AOT (ahead of time compilation).
Speaking of the latter:
AOT enables you to compile your app's templates in the build time of your server. Moreover, you won't need to use the oversized @angular/compiler package in your bundle, which leads to a lower size and load time.
Yet, for future-proofing these “facilities” that Angular provides, you'll need to abide by... some sort of rules at least. And one of them is:
Restraining yourself from manipulating the DOM directly, using jQuery, the global document object or the ElementRef.nativeElement.
Instead, use the Renderer2 service (or Renderer for Angular 2):
It's 2 things that this wrapper to the view mutation layer will enable:
for the default layer to be used in the browser
for the renderer to get replaced with a more suitable one whenever your Agular app runs on another platform (e.g. a phone)
In short: Resist “temptation” and never ever touch the DOM directly!
5. Declaring The Same Component in More than Just One NgModule
And declaring a component in multiple NGModule-s is one of those most common Angular mistakes that end up throwing an error “at” you.
“Why, so?”
Because you need to declare each component in its own NgModule — and to list it in the @Ngmodule.declarations array — in order for it to be available for the views.
If you do need to declare the very same component in multiple modules, you'll need to consider the relationship between those modules:
Is it a parent-child one, maybe?
If this is the case, then:
use the child's NGModule.declaration to declare the HeroComponent in the child module
use the chid's NGModule.exports array to... export the HeroComponent
use the parent's NGModule.imports array to import the child module
If not (if we can't be talking about a parent-child module relationship), then you'll need to declare another NgModule as the module of the shared data.
Final Word
It's only by knocking your head against unexpected issues while building your projects on this platform, that you'll get to grow as an Angular developer.
And still, instead of embracing the “fail fast, fail often” concept, wouldn't it be best if you:
learned from other developers' mistakes, thus knowing what the most common Angular mistakes are
ensured that you failed "rarely" instead?
RADU SIMILEANU / Jun 05'2018
Building a web app using React for the first time? Then it must be a simple "Hello World" type of app that you're planning to set up. One that would guarantee you a smooth first-hand experience with React.js...
So, you're wondering:
"What's the fastest way to build a basic app in React?"
A question then followed by a... myriad of other questions:
"What dependencies should I use?"
"What React stack should I go for if it's just a simple web app that I want to create?"
Now it's about time that you moved from questioning yourself to code writing, don't you think? Here's a simple and easy-to-follow tutorial on how to create a React app from scratch.
1. Create a New React Project Folder
The very first step to take is to start a new React project. Obviously!
Note: Make sure you have NPM and Node installed in your environment first things first!
For this, just run the command here below:
npm install -g create-react-app
Tada! Your React boilerplate app creator has just bee installed!
Now the second code that you'll run is going to create your "Hello World" React app itself:
create-react-app hello-world
Running an imaginary magnifying glass across your app's structure you can't help not noticing the 3 major file types there:
public/index.html files
src/index.js files
src/App.js files
And scanning your app's backbone a little deeper you'll spot:
a div with the id root
this piece code here below in the index.js.file:
ReactDOM.render(, document.getElementById(‘root’));
If we were to translate this code segment into plain language it would go something like this:
React injects your app component into the div by using the root id.
2. Write the Simplest React Component
"But what is an app component more precisely?"
Take it as React's convention to use the same names both for JavaScript files and the component.
And now the code for your more-than-basic component would look something like this:
import React, { Component } from 'react';
class App extends Component {
render() {
return (
<div className="greeting">
<h1> Hello World! </h1>
</div>
);
}
}
Feel free to create a JavaScript class for it and to extend it from the Component class.
Next, implement the render () method, which will return a whole suite of elements (unlike prior to React 16, when one had to return a single element per each render method that was being implemented).
Then, running the npm start command in your app's directory, you'll see the "Hello World" text message displayed at http://localhost:3000.
Hello World!
3. Building a Web App Using React and JSX
And I feel that I should start by defining JSX, right? Before I go ahead and delve into details on how to use it with React:
An extension to the JavaScript language — therefore a template language — with a structure similar to HTML. One that makes a great team with React.
Its true "power" is that it... empowers you to write your HTML components and React components in an HTML-like tag:
<HelloWorld />
And here's JSX "in action", right in this "Hello World" app that we're building here:
The following code:
const element =
(
<h1 className="greeting">
Hello, world!
</h1>
);
... gets compiled to the familiar JavaScript code here below:
const element = React.createElement(
'h1',
{className: 'greeting'},
'Hello, world!'
);
See? A familiar HTML-tag language that makes structuring an app's code a whole lot easier for any developer!
And this is JSX's main role and the very reason why it works perfectly with React.
4. How to Use State vs Props in React.js
How about creating another component as we're building a web app using React?
Let's name it "Mary":
import React, { Component } from 'react';
class Mary extends Component {
render() {
return (
<div>
<h2> Hi, I am Mary </h2>
</div>
);
}
}
export default Mary;
Bravo! Next, we can include it, as a child component, into our existing React App component:
import React, { Component } from 'react';
import Mary from './Mary';
class App extends Component {
render() {
return (
<div className="greeting">
<h1> Hello World! </h1>
<Mary/>
</div>
);
}
}
export default App;
Note: Noticed the import statement for our "Mary" component? It plays a key role since without it our React app wouldn't work. And this because React wouldn't be able to identify, all by itself, the component that corresponds to the Mary tag.
Curious now how you could manipulate your "Mary" component? How you can control its behavior?
By manipulating its... state object, that's how!
Note: each React component comes with its own state object.
import React, { Component } from 'react';
import Mary from './Mary';
class App extends Component {
constructor() {
super();
this.state = {
greeting: "Hello World!"
}
}
render() {
return (
<div className="greeting">
<h1> {this.state.greeting} </h1>
<Mary/>
</div>
);
}
}
export default App;
See the "greetings" property — having the "Hello World" value — that corresponds to the state object? Remember that you're free to add as many properties as needed.
Next, how about trying to pass data from our App component into its child one, Mary:
import React, { Component } from 'react';
import Mary from './Mary';
class App extends Component {
constructor() {
super();
this.state = {
greeting: "Hello World!",
parentMessage: "Hello Mary!"
}
}
render() {
return (
<div className="greeting">
<h1> {this.state.greeting} </h1>
<Mary newMsg={this.state.parentMessage} />
</div>
);
}
}
export default App;
Noticed the "newMsg" key there? It's precisely this key that's responsible with the data transfer.
Now, as for the child component "Mary":
import React, { Component } from 'react';
class Mary extends Component {
constructor(props) {
super(props)
this.state = {
greeting: props.newMsg
}
}
render() {
return (
<div>
<h2> {this.state.greeting} </h2>
</div>
);
}
}
export default Mary;
If you're willing to give this piece of code a deep scan, you'll notice that there's a "props" method argument in there.
Keep in mind that it's precisely this object that stores all the data transferred from the parent component to the child React component.
Also, another "detail" that you should be able to detect is the "newMsg" property (transferred from the parent/App component); we've used it to initialize the state of the Mary component.
5. How to Use The React (Component) Lifecycle Hooks
I won't get into too many details, since React's documentation is already more than "enlightening" when it comes to:
the different lifecycle methods (or hooks) to be invoked for each state of a React component
the precise times in the development process for triggering each hook
Nevertheless, I'll briefly add that all these methods to be used across your React components' lifecycles fall into 3 main categories:
mounting hooks: use them at the very start, when your React component is being rendered in the browser page
updating hooks: fire them when your component gets re-rendered on the web page. And this happens if/when changes are made to the state/props objects
unmounting hook: invoke the componentWillUnmount() hook shortly after your component gets removed from the DOM
Note: Since React 16, the collection of hooks has enriched with a brand new one: componentDidCatch()! Fire it whenever you're dealing with an exception during the other lifecycle methods of your component.
In other words: invoke it whenever a component fails to function as it should when you're building a web app using React!
As for the specific way that React manipulates DOM via the Virtual DOM that it creates, feel free to have a look at our post precisely on this topic: How React Virtual DOM Works!
The END!
Your turn now: go through all the steps included here and, step by step, set up your first basic React application!
RADU SIMILEANU / May 31'2018
About to build your very first Angular app? Then you must be planning to create an Angular project with Angular CLI, right? The much-acclaimed tool that the Angular team built precisely to jumpstart the whole development process.
… to have a simple app scaffolded, generated and deployed in no time, by entering just a few commands (so they say, at least).
And since I'm sure that you don't want to waste these bundles of convenience by letting yourself tangled up in overly complex explanations instead, I've kept things simple with this guide.
So, here's how you create and run your first Angular project via the Angular command-line interface:
1. But How Precisely Can Angular CLI Jumpstart Your App's Development Process?
Take this command-line interface as a starter kit “present” that the Angular team has nicely wrapped for you:
it's practically geared at empowering you to get up and start developing a new Angular app in no time
it takes just one short command to generate a default Angular project that would include all the needed dependencies (in the node_modules folder), as well as testing files for each component
Now, this is what I call a major kickstart! It's got you covered from the stage of setting everything up, to creating the Angular project itself, to testing it and finally deploying it.
Other key usages of the Angular CLI that we're not going to focus on in this tutorial here are:
real-time server maintenance and support
building applications for production
adding new features to your existing app
running tests on your application units
2. Setting It Up: Install Angular CLI Globally
Before you jump to the part where you create an Angular app using Angular CLI, you need to install the command-line interface itself. Globally!
And this is the “power” command to enter in your terminal with the npm installed:
npm install -g @angular/cli
Notes:
if you already have the CLI installed, make sure it's the latest version
if you need to update it, these are the commands to enter:
npm uninstall -g angular-cli
npm uninstall --save-dev angular-cli
And there's more! A few more must-have dependencies that you need to make sure that are already installed and upgraded to their latest versions:
Node.js: v6.9.x +
npm: 3.x.x +
3. Create an Angular Project With Angular CLI
With your command line interface ON, use it to enter THE one and only command that will generate a new Angular project for you. One incorporating, by default, all the needed dependencies:
ng new ng-yourproject
Tada! A “yourproject” named directory has just been generated. That's where your new Angular project — along with all the requested dependencies — gets stored.
Eager to test it out? Just run the following command in your terminal:
ng serve
Your Angular app will then get built and served up to localhost:4200. Feel free to open this URL in your browser and it's the here-below screen that you should be able to see:
Basically, it's the default application shell itself rendered by the CLI.
4. “Deconstructing” Your New Angular Project: What Does It Include?
Now, before you go ahead and do your “tweaking” on your newly created app, let's see what you've got in there! What are the elements that the CLI has generated for you to help you jump to development right out of the box?
For this quick “scan”, open your Angular project in your IDE of choice and start “exploring” your src/folder:
src/*
styles.css
any styles that you'll plan to apply globally, it's this file that you can add them to; and it's here, as well, that you can import new .css files (Bootstrap or any other styling frameworks of your choice)
index.html
where your Angular app gets started
src/app/*
app.component.ts
this is where your app's one and only (for now at least) component gets stored
app.module.ts
the modules Angular needs for managing your app's components
note: @NgModule marks the class file as a module and this is what makes it similar to @Component
5. Create a New Component
Remember your “one and only component” that I mentioned during the previous “inventory” of all the “bunch of stuff” that CLI has generated in your project?
Well, how about creating a new one now? One that would load under that root component?
Just run the following command to generate it:
ng generate component the-quote
Next, time to “show it off” in your browser:
<h3>{{myQuote.quote}}</h3>
<small>- {{myQuote.by}}</small>
Add the app-the-quote selector to the root component that the CLI generated in your Angular project:
<h1>
{{title}}
</h1>
<app-the-quote></app-the-quote>
6. Apply External Styling
Now you do agree that when you create an Angular project with Angular CLI applying styling is a key step.
So, let's add your favorite CSS framework to your new application!
Me, it's Bulma that I'll be using in this tutorial here:
npm install bulma --save
With our CSS framework installed, we'll need to enable it to load the CSS file into our Angular app. For this, just place the relative path within the .angular-cli.json file., to the file in the styles array more precisely.
...
"styles": [
"../node_modules/bulma/css/bulma.css",
"styles.css"
],
...
“Tempted” to display some icons now, as well? Then go ahead and add the font-awesome library as cdn link.
For this, just include the stylesheet right into your index.html:
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css">
Et voila! This is how you create an Angular project with Angular CLI!
What do you think? Is the Angular command-line interface an extremely useful tool to jumpstart your project with or did you expected your “starter kit” to include, right out-of-the-box, more elements to get you started?
RADU SIMILEANU / May 25'2018
It's undebatable: Node.js has practically laid the foundation of the real-time web! The real-time, two-way connection web apps have revolutionized the old web response paradigm. The one where it was just the client who could initiate communication, never the server, as well. Even so, there are certain cases when using Node.js is not the best decision you could make.
Specific use cases for which the otherwise flexible and revolutionary web server technology turns out not to be... unsuitable. So:
“When shouldn't I use Node.js?”
You might legitimately ask yourself.
Here are the 3 bad use cases for this JavaScript runtime environment. Scan them through, take note all the factors that I'll be outlining and think them through before rushing to use Node.js to power your next project with.
1. A CPU-Heavy Application: Using Node.js Is Simply a Bad Idea
Face it, deal with it and... adjust your decisions to it:
There are plenty of better solutions (other than Node.js) for powering your CPU-intensive app. It's just not the best technology at hand when it comes to heavy computation.
Now here's why, by using Node.js, you'll only end up “sabotaging” its very advantages, instead of turning it into a true “horsepower” for your app, as you might expect:
Node.js leverages an event-based, non-blocking I/O model, using a single CPU
hence, all that intense CPU-processing activity will actually block the incoming requests
… since the thread will get “held up” with number-crunching
The direct effect of “exploiting” Node.js in the context of heavy server-side computation?
The very benefits of its event-driven, non-clocking I/O model would get practically... nullified in the context of CPU-intensive operations.
Given this, why would you stubbornly stick to Node.js, when there are other technologies more suitable for building your CPU-heavy software with? With better results?
2. A Simple CRUD (or HTML) Application
No need to get your hopes high when using Node.js with a basic CRUD or HTML application:
It might turn out to be just “slightly” more scalable, yet don't expect a traffic flood just because it's Node.js-powered.
In short: use cases like this one, where data's provided, straightforwardly, by the server and where there's no need for a separate API, render Node.js superfluous.
There are other frameworks suited specifically for this type of projects (take Ruby for instance).
Using Node.js in this case would be like driving a Formula 1 car while... stuck in rush hour traffic.
3. A Relational Database-Backed Server-Side App
Why isn't Node.js your best choice for a relational data access type of project?
Because its relational database tools aren't as reliable, robust and easy to work with as other frameworks' toolboxes (take Rails for instance!).
Rails, for example, would “spoil” you with:
already matured Data Mapper and Active Record data access layer implementations
out-of-the-box data access setup
DB schema migrations support tools
… and the list goes on
In short: if there already are frameworks perfectly “equipped” for this type of project “scenarios”, why would you stick to using Node.js? Since its relational DB toolbox is not (yet) as advanced?
In Other Words...
With these 3 “bad” use cases for Node.js “exposed”, allow me to put together a short “inventory” here, one including all the “gotchas”, aspects to consider before kicking off your Node.js project and limitations to be aware of:
Node.js hasn't been built with the “solving the compute scaling” issue in mind
… but it has been created to solve the I/O scaling issue instead
excepting contexts of CPU-heavy operations, Node.js still is the best technology at hand for powering your real-time, scalable web apps with
do reconsider your decision of using Node.js if for developing your piece of software you depend on some kind of threading model
there are also poor quality packages available in npm, free to use in your Node.js application; do keep this in mind as you dig deep into the “load” of Node.js packages
Node.js will never be “the best choice” for event loop-blocking use cases (take asynchronous parsing XML, for instance)
… nor for powering apps relying on intense computation
Node'js “worker” is geared at solving HTTP server calling issues (rather than intense computing issues)
The END!
RADU SIMILEANU / May 17'2018
Not exactly the “jumping on the latest trend" type? Therefore, you're still a bit hesitant to get on the Node.js bandwagon? And this because you still haven't got some crystal-clear answers to your “What is Node.js used for?” question?
You're legitimately hesitant then! For everyone's gone crazy over it these days, but you know that there must be certain factors to consider.
Specific use cases for Node.js, as well as cases when... well... it just isn't the best idea.
You're well aware that there are some particular applications that call precisely for this JavaScript runtime environment. And you need to be 101% sure that your project fits the “profile”. One of the “best use cases of Node.js”.
But let's not meander any longer and get you some clear answers to your questions instead:
Why should you even consider Node.js one of the possible technologies to choose from for your next project?
Which are the ideal use cases for Node.js?
1. Why Would You (Even) Consider Node.js for Your Project?
Why should Node.js be on your list of... options, in the first place? On your shortlist of technologies that might power your next project?
There must be some “bundles of convenience”, some major benefits that you can “reap” from using it, right? Benefits that make it worth building your project using this specific environment.
Well, let us shed some light on these clear advantages of developing your application in Node.js:
it's a Google JavaScript engine (a runtime environment) which, translated into clear benefits, means that: it's fast and scalable web apps that you'll build using it
speaking of its scalability: Node.js's built to scale on individual process basis and to leverage multi-core processing on modern servers (via its Cluster module)
it's JavaScript-based... so the “pool” of developers with some kind of JS knowledge/expertise is conveniently large: 99,9% of them know at least “some” JavaScript
… no to say that this turns Node.js into the perfect choice if there are beginner developers in your team (even junior developers are at least familiarized with JS)
any developer will be able to gain a quick understanding of your Node.js app's codebase
it speeds up developers' work with a collection of modules (Grunt, NPM, etc.)
it provides your development team with a great package manager, npm, with a widely available and increasingly heavy “load” of open-source tools
it's backed and actively maintained by an ever-growing community ready to... support you; the knowledge base that your development team needs to get a grip on Node.js is accessible and... free
it's open-source: you'll benefit from a single, free codebase
it's just... fast, there's no point in debating over this: the event loop and Google's innovative technologies are “turbocharging” it
it cuts down costs, as simple as that: Node.js enables your team to use the same language on the front-end and on the back-end, which translates into boosted efficiency, cross-functionality and implicitly... reduced costs
you're “tempted” with a whole range of hosting options to select from
it supports native JSON: it's in this specific format that you'll get to keep your data stored in your
database
Now if I was to trim this list to just 3 answers to your “what is Node.js used for?” dilemma, it's these 3 key benefits that I'd stubbornly stick to:
performance: Node.js is simply... fast, faster than other JS languages; moreover, as a runtime language it has enhanced JavaScript with new capabilities
versatility: from backend to front-end apps, to clips to... pretty much everything in between, Node.js enables you to build any kind of project that you have in mind; as long as it's written in JavaScript, of course
agility: regardless of your/your team's level of JavaScript expertise, Node.js empowers you to kick-start your project, to get it up and running in no time; it's developer productivity-oriented (just think same language for both back-end and front-end!!!), with a low learning curve
2. What is Node.js Used for? 7 Great Use Cases
Now back to the very question that started this post:
“What exactly is Node.js good/used for?”
There are specific app projects that this server-side JavaScript technology makes the best choice for:
2.1. Chat servers
And generally speaking any type of fast-upload system challenged to respond, in real-time, to an “avalanche” of incoming requests.
2.2. Real-time apps
This is the use case that Node.js “rocks at”. Where you get to make the most of its capabilities.
Apps geared at processing high volumes of short messages, where low latency becomes critical, make the best possible answer to your “what is Node.js used for?” question.
Here's why:
it enables sharing and reusing Node.js packages that store library code
it processes ideally fast: quick data sync between the client and server
it's perfectly “equipped” to cope with multiple client requests
In short: if scalability and real-time data processing are 2 critical factors to consider when choosing the best technology for your project, think Node.js!
It's built to suit specifically those situations that are “overly demanding” of our servers.
2.3. Video conference apps
...applications using VoIP or specific hardware.
Projects involving intense data streaming — audio and video files — make the best use cases for Node.js.
2.4. Instant-messaging, live-chat apps
2.5. Highly scalable apps
Think Trello or Uber-alike apps, that depend on a server-side server technology enabling them to scale out on multi-CPU servers.
Node.js, thanks to its cluster-based architecture, will always make the best choice for apps depending on a technology that would spread out the load across a multi-core server.
Note: speaking of scalability requirements, should I also mention that Node.js is... conveniently lightweight, too?
2.6. eCommerce transaction software and online gaming apps
“What is Node.js used for?”
For powering apps for which online data is of critical importance. Like these 2 examples here!
2.7. Server-side applications
Being an event-driven model of programming, the flow is determined by messages, user actions, and other specific events of this kind.
3. Afterword
Does this clear the picture for you a bit more?
As a conclusion or “final” answer to your “what is Node.js used for?” type of dilemma, the key takeaway from this post here is that:
Node.js is used primarily for web applications, but it's starting to get used more and more often for developing enterprise apps, too, thanks to its versatility.
What does the future have in store for this increasingly (still) popular technology:
rising potential for Node.js to be used for building IoT solutions
…. for “experimenting” with enterprise data
more and more big names (adding to Netflix, IBM, Amazon, Uber, LinkedIn, etc.) choosing it over legacy languages such as Java or PHP
RADU SIMILEANU / May 10'2018