So, you’d like to build an app with React. And, while weighing your back-end options, you ask yourself: “Why use Node.js with React?”
Why would you go with Node for hosting and running your web server?
Why not… Ruby on Rails? Or maybe Python/Django?
This is precisely what you’ll find in this post: the 11 main reasons why you’d want to choose Node.js as a backend for your React web app:
1. But First: What Is the Difference Between ReactJS and Node.js?
We already have a blog post focused precisely on the React vs Node dilemma, so in today’s post I’ll only pinpoint, briefly, the main differences between the 2 technologies:
While ReactJS is a front-end library, Node.js is a highly popular choice for back-end development (thanks to its event-driven nature and to being asynchronous and highly scalable)
While React provides you with a language to describe the user interface of your web application, Node.js helps you with all sorts of (back-end) things like setting up your server, building CLI tools, scripting; a key difference to help you solve your “React vs Node.js” dilemma
While ReacJS helps you build your UI components, Node.js stores your app’s data in the backend
While React is web app developers’ top choice to address challenges like low performance and slow user interface, Node.js is the go-to technology for creating enterprise-level solutions based on WebSockets, event quests, and microservice architecture.
2. Does ReactJS (Really) Require Node?
In other words, do you need to have a Node.js backend to run React?
No, you don’t.
Node.js is not required for running Reactjs.
So, why use Node.js with React?
There are certain use cases and reasons why you’d want to pair the 2 technologies for building your app:
you cut down on your web app development time (which always has a major business impact)
the Node.js and React duo is your ticket to scalable and efficient code
…
But more on the strongest reasons why you’d use Reactjs with Node down below...
3. Why Use Node.js with React? 11 Top Reasons
Now, going back to your initial question — “Why do you need Node.js for React?” — here are the key reasons why you’d go with this “duo”:
3.1. Because they’re both JavaScript: you can execute them server-side and client-side
The benefits you get from having a JS-based technology in the back-end, as well, are obvious:
you only need to be familiar with JavaScript (no Ruby or Python expertise needed)
same language means… same packages
same language means that you get to speed up your app’s development process
3.2. Because you get to inject V8 engine performance into your React app
In other words, your React app will be perfectly equipped to handle bulk requests with no compromise on quality.
The V8 engine that Node.js uses grants your app the best page load times.
3.3. Because you get a collection of NPM packages to choose from
With the NPM CLI at your disposal, you get to install any of the packages available in the registry quick and easy.
3.4. Why use Node.js with React? Because the “duo” helps you address high server load issues
They work perfectly together to help your app handle multiple client requests while striking a server load balance.
3.5. Because Node.js bundles your app into a single, easy-to-compile file
Using various modules along with Webpack, Node Js bundles your app into one file. One that can get compiled much easier...
3.6. Because it’s a real-time, data-intensive React app that you’re building.
Does your React application depend on Data Streaming or Data-Intensive, Real-Time management?
Is interactivity a major requirement for your web app? Is it a real time application that you have in mind?
Then Nodejs makes the best choice for continued server connection in a context of intensive computation.
3.7. Because you get to run React.js code straight in the Nodejs environment
3.8. Because you get to scale your React & Node.js app to much higher loads
A Node.js back-end will help your app accommodate many more users and many more future calls.
It's your best option for building scalable applications.
The 2 giants are using Node.js precisely for its great scalability potential.
3.9. Because you get to build JSON APIs for your app much easier when using Node and React together
How come?
You get to share and reuse code in React.js quick and easy when you pair it with Node.js in the back-end.
3.10. Because rendering server-side becomes a more streamlined process
Since React DOM comes with components built to work with Nodejs out of the box, you get to cut down on the lines of code.
Which translates into streamlined server-side rendering.
3.11. Because it’s a single-page React app that you’re building
The “React with Node.js” duo makes the best choice for building a SPA.
The lightweight Node backend will be in charge of handling asynchronous data loading via callback functions.
4. In Short, You’d Want to Use React and Node.js Together Because...
“Why use Node.js with React?”
As a conclusion, we could narrow down the entire list to just 2 key reasons:
Convenience: same language in the back-end and the front-end; Node.js makes the go-to option for running and hosting a web server for your React app
ReactJS depends on Node and npm (Node Package Manager) to notify the native side (iOS/Android) of the packages that you need to use in your app; then, it can add all the needed dependencies.
The END!
Now that you know why and when you’d want to use React with Node.js: how do you build that high-performance, conveniently scalable React & Node.js app?
We’re here to help you get the most of these 2 technologies.
Just drop us a line to have a team of React and Node Js developers handle your project.
Image by Anemone123 from Pixabay
Adriana Cacoveanu / Sep 16'2020
You're about to start working on a new app project and you're confused: Create React App vs Next.js - what's the difference?
Which option's best for you? Considering your SEO, SSR, API, and performance needs.
And they're frustratingly similar:
they both enable you to build React apps without the need to use Webpack for bundling it (or the need to do any code splitting)
they both make it possible for you to have your React app up and running in no time
Still, each framework comes with its own pros and cons and specific use cases.
So, in this post, you'll find your answers to the following questions:
What are the key differences between CRA and Next.js?
What are the main benefits of using Next.js?
What are the main benefits of using Create React App?
What are the downsides of Next.js?
What are the downsides of Create React App?
When would you want to use one over the other?
1. What's the Key Difference Between CRA and Next.js?
SSR vs CSR...
It's where all their differences stem from.
Next.js apps are rendered on the client-side (CSR), but the framework supports server-side rendering (SSR), as well. By comparison, Create React App apps are rendered only on the client-side.
In other words:
CRA generates HTML code in the client browser, whereas Next.js generates it in the server, based on the URL.
So, your "Create react App vs Next.js" dilemma comes down to whether a static page meets your needs or not entirely.
2. What Are the Main Benefits of Using Next.js?
Now that you know what's the fundamental difference between the 2 systems for building React apps, let's put the spotlight on Next.js.
Why would you choose it?
because it's so simple to set up, build, and even host a Next.js app: you have packages for almost all the key additions that call for Webpack configuration (SaSS, CSS, TS...)
because rendering React apps becomes much easier, regardless of where the data comes from
because you can benefit from automatic server rendering and code splitting (that will increase performance)
because SSR (server-side rendering) will give your app a major performance boost
because it's a lightweight framework for both static and server-rendered universal JS apps
because it's good for SEO (with everything being generated from the server...)
3. Create React App vs Next.js: What Are the Main Benefits of Using CRA?
In a "Next.js vs create-react-app" debate, what are the strongest reasons for opting for CRA to build your React app?
it's easier to deploy
you get to build a single page React app with... zero configuration (no time-consuming setup needed)
you don't need to deal with Webpack or Babel
it's plain simple (an empty div and just a few js files) and provides all the needed HTML code to render your app on the client-side
the development process is much smoother
better developer experience
In short, with Create React App you basically run just one command and the framework sets up all the tools you need to start developing your app on the spot.
4. What Are the Downsides of Next.js?
What could make you think twice before choosing Next.js for building your next app?
the fact that it's opinionated: there's a Next.js way of doing things and you're constrained to... adjust to it
if you later want to use a router different from its own filled-based one (or add Redux maybe), you'll discover that it's not that flexible
5. What Are the Downsides of Create React App?
In a "Create React App vs Next.js" debate, why would you rule out CRA?
because it only supports client-side rendering, which is not enough if it's a high-performing app that you want to build
because no code splitting translates into lower performance
because it's not good for SEO (since it doesn't render pages on the server)
6. When Would You Want to Use Next.js?
As a rule of thumb, use Next.js:
if you need to build a fast, production-ready app (SSR injects top speed into your React application)
if public SEO is a crucial factor for your app project
if it's a dynamic page that you need to create (wihout having to write your own bundling)
if it's an eCommerce app that you're building (Next.js is more suited for the cart, the stock inventory, and other highly dynamic pages)
7. When Would You Want to Use Create React App?
When would you choose it over Next.js?
when you need to build a React app really fast; with CRA you can skip the configuration and the setting up part
when you need to create a landing page for a product: Create React App makes it so much simpler to put it together
when it's a SPA that you need to build
8. In Conclusion...
CRA is easy, while Next.js "seduces" you with better performance and SEO.
Is it a single page React app that you need to get up and running fast and you don't need SSR? Create React App might just be the best choice for you.
Is it a fast-loading app that you're building? Is performance business-critical for you and SEO much more than just a nice-to-have?
You might want to consider Next.js then for your next app.
Need a team of experienced app developers to build it for you?
Just send us your feature list and... let's build it!
Image by Pexels from Pixabay
Silviu Serdaru / Aug 07'2020
You're building a React website/application. You have your bulky list of functionalities all set, you know how you want it to look, but can't decide on the React framework to build it on: What's the main difference between Gatsby and Next.js, after all?
And what's the difference between server-side rendering and static site rendering?
Since both frameworks seem to be serving your main goals:
not to get tangled up in config or routing
to generate a fast, fully accessible and SEO-friendly website
to provide you with boilerplate application
So, what's the fundamental differentiator between Gatsby and Next?
The one(s) that'll help you identify the framework that best covers your specific use case.
Or, are there several of them (differentiators)? Just keep on reading:
1. But First: What Do Gatsby and Next.js Have in Common?
How are they similar?
they're both React frameworks
they're both great options for SEO purposes
they're both great options if you need a high performance React app/website
they both provide entirely formed HTML pages
they both provide boilerplate application
they both simplify and speed up the React app/website development cycle
they both generate SPA out-of-the-box
they both provide great developer experience
In short: both Next.js and Gatsby score well in categories like speed and SEO; they're both awesome solutions to streamline app/website development in React.
But the way they go about it... that's where these frameworks are fundamentally different.
2. How Does GatsbyJS Work?
It builds HTML code on build time.
That would be the short(est) answer to your question. But if we were to elaborate upon it:
GatsbyJS is a static site generator that... generates (static) HTML code during the “build” process. How? It fetches data from external sources — APIs, Contentful, WordPress, markdown files — and uses GraphQL to render it.
Example: say you have a blog. In this case, you could use Gatsby to fetch your blog posts from... Contentful. Or any other repository where you might be storing your content (e.g. WordPress or Drupal).
3. What's Next.js?
A tool for rendering pages on the server-side.
And a more detailed answer would be:
It's a React framework that supports server-side rendering. Meaning that it generates the needed HTML code dynamically, from the server, each time a request is being sent through.
In short: your browser's provided with pre-rendered HTML code instead of empty “div”.
Now, how does its distinctive way of going about building a React app/website suit you?
It enables you to develop multi-page applications using static rendering and serving dynamic data from a back-end.
4. What Are They Used For? Specific Use Cases for Gatbsy and for Next.js
What's the difference between Gatsby and Next.js in terms of use case?
In other words: when should you choose one over the other?
4.1. Specific Use Cases for GatsbyJS
1. Blogs and small-scaled websites
And I'm talking here about a particular scenario:
When you have no comments section on your blog or, at least, not a very “busy” one. So, a use case where you don't need to render content every 5-10 minutes.
Since blogs are static and their content doesn't change that frequently, Gatbsy's ecosystem makes the perfect fit for them.
And you have 2 options for your blog post creation and publishing process:
you write a blog post and the npm build will generate a corresponding HTML page
you write a blog post in Contentful (or a CMS of your choice), publish it and recompile your blog in Netfly
2. Landing pages
Again, since they use static content, landing pages make an ideal use case for GatsbyJS.
Where do you add that Gatsby “spoils” you with such a wide collection of plugins to choose from and to boost your landing page with: PWA, inline critical CSS, AMP...
4.2. Specific Use Cases for Next.js
1. Content-packed websites
Dealing with lots of content? Or are you expecting your site's content load to grow, over time?
Then Next.js should be your first choice.
The reason is simple:
Just imagine your Gatsby framework overstrained to rebuild all that content over and over again. Not precisely the most time-effective solution to go with, don't you think?
2. When you need more freedom for accessing your data
Do you want to empower your content team to publish content on their own? Then you might want to consider Next.js.
3. To-Do Apps
They make the perfect use case for server-side rendering:
Next.js retrieves the content for your list, from the server, and displays the to-do's upfront.
5. The Fundamental Difference Between Gatsby and Next.js Is...
… that Gatsby's a statically generator, while Next.js generates HTML dynamically.
Image by Colin Behrens from Pixabay
The first creates JS/HTML/CSS at build time, while the second generates it at run time.
Or, if you wish to put it this way:
Gatsby doesn't depend on a server, while Next can't function without one.
6.4 Other Main Areas Where They Differ
For the “Gatsby vs Next” debate doesn't end at the “static vs dynamic” comparison.
There are other factors, as well, that set these 2 React frameworks apart. And we'll outline the 4 most obvious ones:
6.1. Data Handling
In case of Gatsby, the framework's the one “deciding” how you should handle data in your app.
It needs to know where your data, your images and other types of content will be handled.
What's in it your for? Why would you accept this... “compromise”: to be told how to handle data in your own app?
Because:
Gatsby, through its rich collection of plugins, enables you to hook up your site to various data sources. This way, you gain external control over your data...
By comparison, Next's totally unopinionated.
Is gives you the freedom to decide your own data architecture.
In short: it doesn't “tie” you to a specific technology. You're free to handle data your own way.
6.2. Deployment
You can deploy Gatsby anywhere you need to, with no special configurations, since it's no more than compiled CSS, JS, and HTML.
And things are equally straightforward with Next.js, as well. Since it's a Node application, you can host it anywhere you want to...
6.3. Routing
With Gatsby, you have a pages directory where you're free to create all the HTML pages needed for your app/website.
Moreover, they provide you an API, as well, for creating routes dynamically.
With Next.js you get a “pages” folder, as well, where you can set up your new pages and get your app running, with no routing to config.
6.4. Plugins
“What's the main difference between Gatsby and Next.js?” Plugins sure are a powerful differentiator.
Gatsby comes “loaded” with an entire ecosystem of plugins.
So, do you need to have your JS minified, you CSS compiled, your...? There must be a Gatsby plugin for it.
Image by Michael Schwarzenberger from Pixabay
Next.js, on the other hand, doesn't “tempt” you with plugins, since its smaller scope doesn't justify the usage of plugins...
The END!
These are the key differences between Next.js and Gatsby, along with their common points and specific use cases.
Have you had your “Aha!” moment(s) reading through our post? Have you managed to identify the right framework for your own use case?
Photo by Charles ?ﾟﾇﾭ on Unsplash
Silviu Serdaru / Nov 12'2019
They're both open-source and some highly popular options for cross-platform app development. They're both backed by huge tech communities... so your struggle is real: "React Native vs Flutter: which one should I go with?"
On one hand, you have Flutter, which has gained momentum incredibly fast this year, putting the same question on most developers' lips:
Will Flutter replace React Native?
On the other hand, you have React Native, which has been around for +4 years now and uses "good old" JavaScript.
Should you place your bid on "familiarity" and reliability or should you take the leap and go with a newer, but so promising platform instead?
Speaking of which:
What are Flutter's selling points more precisely? Those that have instantly propelled it in developers' radar so quickly?
Why would you choose Flutter over React Native? And when is the latter the best option?
1. Why Choose Cross-Platform App Development in the First Place?
Why would you go with this approach to mobile app development instead of taking the "native" path?
Here are the most powerful reasons:
you get to write (most of) your code once and use it on multiple platforms
you get to tap into the features of your cross-platform framework of choice to develop various types of mobile apps: social apps, eCommerce apps, interactive apps
you get to build a native-like app without getting tangled up in Android, iOS or Java development
Notes:
optimizing your cross-platform app might get discouraging if you're not prepared for it
expect it to be less performant than its native counterpart
your platform of choice might not ship with all the functionalities that you need (Bluetooth, GPS...), so consider creating new plugins or opting for 3rd party ones to compensate for the lack of certain native features
2. React Native Is an...
... open-source JavaScript framework — or a new version of React, if you wish — launched by Facebook, used for building Android and iOS mobile apps.
Source: Facebook.Github.io
How does it work? What kind of "witchcraft" does happen under its hood that enables you to build a hybrid app? One that works both on iOS and Android?
React Native uses a JavaScript bridge which... bridges your UI code to native components.
3. Reasons Why You Would Choose React Native over Flutter: Top 3
Source: Google Trends
So, going back to our "React Native vs Flutter" dilemma: why would you go with Facebook's "prodigy"?
because it's written in JavaScript (entirely) and so it's much easier to find experienced JS developers for your app project
because it's more... mature: it's been around for +4 years, which translates into reliability and a high level of popularity among developers
because it streamlines the app's development cycle: it's faster (just think "ready-to-use components") to build app-like experiences with React Native than with Flutter
4. Flutter Is...
... Google's open-source SDK, written in Dart, used for building cross-platform apps.
How does it work?
It leverages the skia rendering engine to render Dart-based UI in both Android and iOS.
Source: Flutter.dev
4 Key Features of Flutter:
design-specific features
entirely customized environment
platform-specific SDKs
native-like performance
5. Flutter: Biggest Selling Points and Main Weaknesses
What makes this "new kid on the block" so tempting among developers?
Source: Stack Overflow
What does it bring to the table that React Native can't provide?
it's easier to install it: when using React Native, many developers choose to use Expo precisely for this purpose; there's no way of automating the whole process and you bump into errors pretty often
it's easier to test it compared to the complicated setup that you need to do for testing a React Native app
it uses proprietary UI widget sets (by comparison, React Native uses native components), which give you more freedom to customize your UI block components
it benefits from first-party support for its iOS-style and material design widgets
it uses object-oriented design (due to Dart)
it performs better: Flutter's slightly faster since it depends on a JavaScript bridge, like React Native, for interacting with native components
it speeds up the UI designing process (React Native uses native components, while Flutter uses owner widgets)
And this last one is Flutter's most "seductive" feature:
It allows you to create a new custom layout in no time.
"And why would I be hesitant to choose Flutter over React Native?" you might also ask yourself.
Here are some of the aspects that might discourage you from using Flutter for building your cross-platform app:
there aren't so many developers working in Dart, the language used for writing Flutter, compared to the deep pool of JS professionals
the development process is a bit lengthier
it's still relatively a young platform: you might not have a library for every functionality that you want to implement; not just yet...
6. React Native vs Flutter: You'd Be Better Off With...
... Flutter if:
you need to have your app running on both Android and iOS
you're already an experienced C++/Java developer (or developers in your team are), since it'll then be easier for you to learn Dart
high performance is on top of your priority list
you want a visually-appealing UI for your cross-platform app
And opt for React Native if:
you're already an experienced JavaScript developer
you put a high value on the support of a giant, mature tech community
The END!
How do the scores look like on your evaluation list?
Which of the 2 cross-platform solutions would you go with and why? Let us know in the comments below:
Photo by Coffee Geek on Unsplash
Silviu Serdaru / Nov 06'2019
It sure is “the thing” these days. But does that make it “the perfect... thing” for your project, as well? For your specific project needs and priorities? What is Next.js used for more precisely?
Can it handle both portfolio sites, let's say, and... particularly large web projects?
Is it the best fit for both rarely and frequently updating websites? For both websites depending on a rich third-party ecosystem and those that don't use so many libraries?
Let's dig up some answers on:
when (and when not to)
why
… to use Next.js.
1. But First: What Is Next.js?
It's a lightweight React framework used for server-rendered and static web applications.
Now, if we were to highlight some of its main features, any shortlist would have to include:
(default) server-side rendering
ecosystem compatibility
prefetching
HMR and Error reporting
automatic code-splitting
Note: since it resembles PHP development so much, many developers find it easy to “jump on the Next.js bandwagon”.
2. And How Does It Work?
Next.js renders your React app/website on a server (as opposed to being rendered on the client-side).
Source: GoogleDevelopers
So, do keep in mind that you'll need to have a server... somewhere.
The main gain here is that it supports scenarios where data has to be updated in real-time.
As for the drawbacks of server-rendering:
higher level of complexity: expect to write more code to get everything working properly
it's a bit more challenging when dealing with third-party services
a bit more difficult to deploy (compared to client-side rendering and HTML)
3. What Is Next.js Used for? What Types of Projects Would You Use It For?
Now, back to the question that generated this blog post in the first place:
When should you consider Next.js?
When is it the best choice? Does it serve your... specific use case, for instance?
In this respect, we've identified 3 types of projects that Next.js makes the best fit for:
3.1. When SEO is your top priority
Do you need SSR (server-side rendering) to ensure SEO-friendly pages on your website? Then Next.js is your only option.
It's built to serve precisely this type of project, where good SEO is a crucial objective.
3.2. When content gets updated particularly often
Let's say that new and new data gets uploaded on your website and that the content on your web pages needs to get updated within... 3 minutes, maximum.
Source: When Should You Use Gatsby?
And I'm thinking here:
news sites
large eCommerce websites
property listing websites where new comments get added and descriptions updated on a regular basis
In short: if you expect content on your future website to get updated often, then it writes Next.js all over your project.
4. Final Word
Now, would you care for a piece of advice? When trying to answer questions such as:
“What is Next.js used for?”
“Should I use it on my project or should I go with static?”
… make sure you evaluate both your short-term and long-term needs.
In other words: your website might not need to update its content frequently right NOW, but maybe you're considering scaling it up in the future...
For in that case, build performance and SEO will become some key requirements and your client-side or static architecture won't serve your goals anymore.
Just make sure you coordinate your final choice with your future goals, as well.
Image by Lynn Neo from Pixabay
Silviu Serdaru / Nov 04'2019
It's fast, it's secure, it boosts SEO and it provides a great developer experience, but does it fit your use case? For it all comes down to one key question: “When to use GatsbyJS?”
Is it suitable for both a portfolio or documentation site and an app with a large content base? Or a large-scale enterprise website, for instance?
Should you use GatsbyJS irrespective of your/your team's JavaScript experience?
What are the obvious and some of the... less expected use cases for GatsbyJS? Key benefits that would make you want to choose it over a framework like... NextJS, for instance?
Now, let me break down the strongest use cases of Gatsby for you.
See for yourself whether your own use case has made it to the list or not:
1. When to Use GatsbyJS? When You Need a Static Site... Obviously
GatsbyJS's is optimized for this particular use case, after all: generating static websites.
Say you have a static web page (a landing page), that serves plain HTML, some JS, and CSS. As for your more specific types of content, you plan to use Youtube and a platform like Medium to host it on.
Gatsby would make the perfect choice for your use case since:
it provides server-side-rendering out of the box
it ships with a heavy load of plugins to delve into (extract data from your CRM of choice: Contentful, Drupal...)
it has a robust data layer built-in
Use it to create pages dynamically from almost any data source.
2. Use It for Your Documentation/Personal Portfolio Website or Blog
Use GatsbyJS for your blog, eCommerce website or any other general static site that's under 500 pages, where you don't expect to serve any kind of dynamic content.
Note: there are the obvious use cases of GatsbyJS and the more... project-specific ones.
The volume of content served on your website and the amount of traffic aren't always clear indicators of whether you should or should not use Gatsby.
It's all a matter of infrastructure and of whether:
you do afford a build process for your React-based web app
your team's experienced enough to get the most of a micro-service architecture and of serverless functions
you depend on a database that should reflect, instantly, any changes made
GatsbyJS's built to go beyond small/medium scale static sites if used to its full potential.
3. Use It When You “Crave” High Performance
Not only that it's fast by nature, but GatsbyJS even stands out from the crowd of static site generators...
If page load time is your main concern, you might want to consider Gatsby as your first choice.
4. Use It When Your Project Demands a High Level of Security
“When to use GatsbyJS?” you ask yourself.
When you need to add an extra layer of security to your website.
Since it serves plain HTLM files and there's no database or sensitive customer data stored on the server... there's not much to hack there, is it?
The only thing left to “contaminate” if they do manage to get in is... your HTML files.
5. Use It to Build Your Progressive Web App
For GatsbyJS is far more than just another static site generator:
It's designed, from the ground up, to be a PWA website framework.
Quote source: The New Stack
In this respect, it:
ships with robust progressive web app features
is built to be fast and highly accessible across all devices and in all hardware and network contexts
6. Use It If Developer Experience Is One of Your Top Priorities
Luckily enough for your development team, GatsbyJS provides a modern development environment: simple, robust tooling and powerful built-in features.
To give you just a few specific examples:
it automatically generates static assets like CSS and images from the “static” directory
it builds routes between pages automatically
it minifies everything “behind closed doors” before it serves it up to the client
7. Use It If You Have Enough JS/React Experience
One of the few constraints when it comes to using GatsbyJS is the above-the-average JS/React experience required.
There's no two ways about it...
Also, another answer to your “When to use GatsbyJS?” question is:
When you already have some React components or codebase available to reuse on your static web pages.
8. Use It if You Fancy a Huge Ecosystem of Plugins
Why use GatsbyJS?
Source: Reddit.com
Because it ships with an impressive collection of plugins.
Basically, it enables you to enhance your otherwise simple, static website with all kinds of powerful plugins:
you could just plug in Google Analytics into your site
you could “inject” a gatsby-source-medium plugin and have previews of your articles automatically served up on your website
9. Use It if SEO Is Crucial for You
When to use GatbsyJS?
When the SEO factor is of critical importance to you.
The web performance boost that you'll get from powering your website with Gatsby — since it'll render static HTML only — won't go unnoticed by your users and... by Google itself.
Just make sure:
a static architecture is, indeed, the right fit for your project
you've configured your SEO settings properly
10. Use It with a Headless CMS
It's another one of those primary use cases for GatsbyJS:
Pair your Gatsby site with a CMS data source of choice (a “headless” CMS): Contentful, Drupal, Netfly, WordPress.
This way, you pass all the “worries” regarding hosting and serving your data over to your CMS.
GatsybyJS integrates seamlessly with any data repository, so you can focus on implementing your front-end instead.
The END!
These are the top 10 use cases for GatsbyJS, ranging from the most common to specific ones.
Which of its benefits — security, high performance, plugin system, developer experience, CMS integration — is more important for your own use case?
Image by nugroho dwi hartawan from Pixabay
Silviu Serdaru / Oct 25'2019
With the Twig templates replacing the old PHP templates, Drupal has been brought to a whole new “era”. We can now leverage the advantages of a component-based development in Drupal 8. But what does that mean, more precisely?
How does this (not so) new approach in software development benefit you? Your own team of developers...
And everyone's talking about tones of flexibility being unlocked and about the Twig templates' extensibility. About how front-end developers, even those with little knowledge of Drupal, specialized in various languages, can now... “come right on board”. Since they're already familiar with the Twig engine...
Also, we can't ignore all the hype around the advantage of the streamlined development cycles in Drupal and of the consistent user experience across a whole portfolio of Drupal apps/websites.
But let's take all these tempting advantages of component-based UI development in Drupal 8 and point out how they benefit your team precisely.
1. But First: What Is a Component?
It's a standalone piece of software that can appear in multiple places across your Drupal website/application.
One of the most relevant examples is that of a content hub. One displaying teasers of the latest blog posts, events... You could set up a component that would determine how each item in that content hub should look like.
In short:
one single component can be used by several types of content
any update to its template/style would automatically reflect on all those content types, as well
Accessible via an API, this independent piece of software explicitly defines all its application dependencies.|
Your team could then easily architect a new interface by just scanning through and selecting from the library of components.
2. What Is Component-Driven Development? What Problems Does It Solve?
A succinct definition of component-based software engineering would be:
A software development technique where you'd select off-the-shelf, reusable components and put them together according to a pre-defined software architecture.
“And what challenges does it address?”
It streamlines and lowers the level of complexity of otherwise intricate, time-consuming development and design processes. As the author of given components, your role is to get them implemented.
No need to worry about how they'll get “assembled”; this is what the well-defined external structure is there for.
Word of caution: mind you don't get too... engrossed in putting together the right components, in architecting the best component-based structure, for you then risk investing too little time in... building them properly.
3. Component-Based Development in Drupal 8
Now, if we are to focus our attention on the component-based UI approach in relation to Drupal 8 software development, here are the key aspects worth outlining:
with the Twig engine in Drupal 8, you're free to “joggle with” extensible templates; once you've defined a Twig template in one place, we get to reuse it across the whole Drupal website/app
the Component Libraries module allows you to set up template files (storing all their needed JS and CS), assign a namespace for them and place them pretty much anywhere on your Drupal filespace (not just in your themes' “templates” directory)
you then get to use the KSS Node library and define a living style guide; it's where you'll store all the component templates built for your Drupal website (styles, markup, JS behaviors, etc.)
By filling in your toolboxes with all these tools — the results of a joint effort of the Drupal and the front-end communities — you're empowered to design themes that are more modular. And, therefore, more efficient...
4. The Top 6 Benefits of the Component-Based UI Approach
4.1. It Ensures UX Consistency Across All Your Drupal 8 Websites
Take your library of components as the “headquarters” for all the teams involved in your Drupal project: QA, business, development, design teams...
It's there that they can find the pre-defined standards they need to keep the consistency of the features they implement or of other tasks they carry out across multiple projects.
A consistency that will bubble up to the user experience itself, across your whole portfolio of Drupal 8 websites/applications...
4.2. It Accelerates the Process of Turning Your Visual Design into a UI
Embracing the component-based development in Drupal 8 you'd avoid those unwanted, yet so frequent scenarios where the front-end developer gets tangled up in the wireframe he receives and:
he/she translates parts of it the... wrong way
he digs up all types of “surprise” issues
By using a component-driven UI approach translating a visual design into a user interface gets much more... event-less.
With:
a pre-defined component architecture to rely on
well-established standards to follow
a whole library of component templates at hand
… there are fewer chances of discrepancies between the UX defined in the visual design and the one delivered via the resulting user interface.
Not to mention the reduced delivery timelines...
4.3. It Streamlines the Whole Development Process
“Sustainability” is the best word to define this approach to Drupal software development.
Just think about it:
whether it's a particular grid, navigation or layout that your front-end developer needs when working on a new project, he/she can pull it right from the component library at hand
… and “inject” it into the app/website that he's working on
in case that element needs further updating, the developer will already have the baseline to start with
… there's no need for new components to be designed, from the ground up, with every single project: the already existing ones can always get further extended
And that can only translate into significant savings of both time and money.
4.4. It Reduces the Time Spent on Setting Up the Functionality & Defining the UX
And this is one of the key benefits of using component-based development in Drupal 8. Your various teams would no longer need to define the UX requirements and the functionality every single time during the design process.
With an easily accessible library of components, they can always pull a component standing for a specific requirement (display of complex data, filtering, pagination in grids, etc.) and just define its extensions. And the business logic, as well.
4.5. It Enables You to Systematically Reuse Your Components
And “reusability” goes hand in hand with “sustainability”. I would even say that it's a synonym for “future-proofing”, as well...
Just think about it: by having a Drupal 8 website in a component-based format you can always rearrange components as technologies grow outdated and new ones emerge...
In short, embracing a component-based development in Drupal 8 enables you to remove the need of rebuilding your website every time its underlying technologies “grow out of fashion”.
With your component library at hand, you'll be able to swap your guidelines, design patterns and various content templates in and out, keeping your Drupal app or website up to date.
4.6. It Integrates Seamlessly into the Development Process
By leveraging a component-based development in Drupal 8, you'd also gain better control over the whole development cycle. The update process here included...
Since you'd then build your components and manage your production quality user interface code in a repository like GitHub, every update that you'd make will be displayed in there. And be easily accessible to everyone in your team.
In short, your developers get to pull pieces of code from the repository to further extend them, then re-submit them to GitHub (or to another source code repository) for review.
With the ability to version your component library, your team can keep a close track of all your Drupal applications with their corresponding versions of the approved UX.
The END!
This is how the component-based development in Drupal 8 would benefit you and your team. Have we left out other key advantages of using this approach?
Image by Arek Socha from Pixabay
Silviu Serdaru / Apr 11'2019
Isn't it ironic? On one hand, you've kept hearing/reading have all this talk about WebAssembly and what a game changer for the web it is. Yet, on the other hand, few developers are actually leveraging it in their projects? There's all this hype around the new way of assembling code in any language and running it right in the web browser, yet everyone's still a bit hesitant about using it. Are there any truly compelling use cases for WebAssembly?
Why would you use it? What are its primary use cases?
For now, what you do know are its “selling points”, that everyone's blowing the trumpet about:
it enables you to build reliable, dynamic, faster websites
it's now shipping in all major browsers
it enables you to write your piece of software once and then have it run on... every platform with a browser
it's a “revival” of the smart client software development
On the other hand: it's still a “steamy fresh” technology and people are half-hearted about using it.
And where do you add that it requires a huge shift in mentality, as well: using the browser for tasks that developers are used to performing in the back-end.
Now, let's shed some light here and bring forward the most compelling use cases for WebAssembly:
1. Writing Faster Code
And writing “almost fast as native code for web browsers” has been one of developers' ever-present goal.
Well, yes: WebAssembly does enable you to write faster code.
And yes, it is faster than JavaScript, “showing off” its performance-oriented side particularly when it comes to performing highly computational tasks. Those kinds of operations where lots of numbers and memory strain are involved.
Notes:
Do keep in mind that being able to write faster code to be run with ES6 doesn't mean that WebAssembly will replace JavaScript. It's designed to cohabit with it, not to be the “cause of its death”.
benchmarks have shown WebAssembly to be 10% slower than C code. Still, many consider it as a too little compromise for all the flexibility and portability they get in return.
2. Client-Side Compression: One of the Primary Use Cases for WebAssembly
Just think of the tones of convenience that such a use case comes bundled with.
Let's take this hypothetical user who takes a photo on his/her phone and then uploads it on a website. In that case, it's the server that normally handles the compression part: the user uploads the image at a default maximum resolution, then the server compresses it.
When using WebAssembly all this compression happens in the... browser. The result: fewer server resources and data/bandwidth used...
You get to run your web apps using the client's CPU instead. Compared to the “old way”, where you would access the server first, then send the result to the client.
3. Writing Code for the Web in Other Languages than JavaScript
By far one of WebAssembly's biggest “selling points” is the flexibility that it provides. You get to write your code for the web in a... non-JavaScript language.
And that's huge! Just think that till recently you were constrained to write your code for the web browsers in JavaScript. There was no alternative...
Again, that doesn't mean that we'll witness a migration of developers from JavaScript to other specialized languages. Instead, scenarios where you'd use JS for the app's logic and UI alongside WebAssembly, used for the core functionality, are more likely to happen. As well as those scenarios where performance bottlenecks in your existing JS apps will get rewritten in a more... specialized language. One that's more fitted to tackle those specific issues...
4. Compiling Existing Applications for the Browser
Another one of the compelling use cases for WebAssembly is this: compiling your current apps so that they run on the browser.
A possible way to do this is by writing your existing apps in a managed language that has a large runtime. Take for instance a scenario where you'd compile Photoshop for the web browser.
That, of course, if you don't have anything against sending an oversized file over each user's network.
5. Compiling & Accessing C/C++ Libraries
… and compiling Rust, I must add.
“What is WebAssembly good for?” To access C/C++ libraries for a wide range of operations:
digital media processing
graphics
compression
physics simulation
And, of course, to compile C/C++ and Rust (or other statically typed languages) to a new format, to be easily run in the web browser. All that with a low runtime, so that you can reap the benefits of predictable performance.
6. Moving from Desktop-Only to Browser-Based Applications
WebAssembly marks the “extinction” of the last desktop-only apps.
From VR/AR apps to apps with heavy data usage, to photo and video editors, to games with complex system requirements, they can all be run in the web browser now.
Final Word
Just imagine all the possibilities that WebAsembly unlocks: it enables you to take code from any language and run it in the web browser. Moreover, since it's a compile target, it “plays nicely” with other languages on the web: C++, Rust, C...
And this leads us to the required shift in mentality mentioned at the beginning of this post: using technology for operations that would normally be performed in the back-end, but which, in this case, involve the web browser...
Image by Rani Suarni from Pixabay
Silviu Serdaru / Apr 02'2019
“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