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
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.
Silviu Serdaru / Jul 24'2018