Silviu Serdaru

Silviu Serdaru

SILVIU SERDARU, Front-End & Drupal Developer

Constantly seeking to enrich the "arsenal" of technologies that I already have a hands-on experience in working with (HTML5 to CSS3, JavaScript, jQuery, PHP...) and on a permanent lookout for front-end development challenges with a Drupal-specific flavour.

Back to Blog Posts
What Are Some Compelling Use Cases for WebAssembly? Top 6
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 ... Read more
Silviu Serdaru / Apr 02'2019
Writing HTML Code for Screen Readers: 6 Best Practices 
And developing a website with accessibility in mind means precisely that: to write your HTML code for screen readers. For those website visitors who depend on assistive technologies to fully enjoy the user experience delivered there. Therefore, the way you'll configure your HTML elements will have a sure impact on your website's overall accessibility: good or bad. In this respect, here's a checklist of the most effective (and handiest) ways to make your HTML elements fully visible and comprehensible to screen readers:   1.  Provide Alternate Text for Every Image on Your Website By far the handiest way to write HTML code for screen readers: just grow a habit of adding a succinct, yet perfectly comprehensive “Alt text” description to every new and old image on your website. Make it descriptive enough, but do look out for overly specific (and long) descriptions. Keep in mind to provide context... You'd thus prevent awkward situations where the assistive technology would just let that website visitor know that... there's an image on that page.   2. Writing HTML Code for Screen Readers: Use ARIA Attributes One of the best HTML accessibility best practices is to add ARIA (Accessible Rich Internet Applications) to your HTML elements. Why bother? Because this way you're providing visually-impaired users with more information about specific elements on a web page Take this example: the “role” attribute gives more context; it makes it easier for the screen reader (and the assisted user implicitly) to see what that element's “role” is in the context of that specific web page. Just add the “navigation” value to that “role” attribute and the screen reader can then interpret the HTML element as being a... menu. And then present the user with all the options listed there. Something intuitive for a user, but not so much for a visually-impaired one. And this is but one of the many functions for ARIA attributes that you could add to your HTML code to enhance its accessibility.   3. Declare A Page's Language in HTML You can and should do that via HTML. This way, if your website's accessed: from a different country by a visitor with different language settings … the screen reader “detecting” its default language will be quick to translate it. Note: if you have snippets of text in a language different from the default one on your website, remember to add a new language tag to each snippet. This way, you'll be signaling to screen readers that those specific parts should be translated accordingly.   4. Keep Your Links Short, but Not Too Short Try to find that ideal balance between confusingly long and ineffectively short text for your links. It's one of the “trickiest” parts of writing HTML code for screen readers: if you use too many words, since the link will get read out loud by the screen reader, it might just confuse the visitor in question if you make it too short, those users who rely on screen readers but still use their mouses to navigate websites might just... miss it   5. Use Semantic Tags: Make Your Content Readable and Understandable What do you think of when you say “semantic tags”? Tags like <b>, for bold text (and, therefore important information) or <i> for italicized text (which might indicate a quote) might be the first the come to your mind, right? But still, these are indicators for how the text should be displayed. And that's irrelevant for visually-impaired users... By comparison, 100% semantic tags, like <strong> and <em> indicate to the screen readers how that text should be interpreted. They're valuable “stage directions” on how it should be read to enhance the users' understanding.   6. Structure Your Pages so They... Make Sense to Screen Reader Users Writing HTML code for screen readers means also structuring your web pages with accessibility in mind. So, ask yourself common questions like: when a visitors tells his/her screen reader to jump to the main context section on a page, are the links there short enough not to confuse him/her and long enough not to... miss them? does that main context make sense to someone who can't interpret visual details like color scheme, layout, route of navigation? Would he/she still be able to make sense of your web page's structure? The END! Needless to add that the list of ways that you could tweak your HTML code for screen readers, for enhancing accessibility, is a... never-ending one. Start by focusing on these 6 aspects that will help you develop the right mindset for accessibility then... keep adding on more techniques. ... Read more
Silviu Serdaru / Mar 23'2019
Headless CMS vs Traditional CMS: Which One Is the Best Fit for Your Needs?
“Should I stay or should I go?” Should you stick to an all-too-familiar traditional CMS and “reap” the benefit of getting loads of much-needed functionality out-of-the-box? Or should you bid on flexibility, top speed, and versatility instead? In a headless CMS vs traditional CMS “debate”, which system best suits your specific needs? Now, let me try and “guess” some of the CMS requirements on your wishlist:   to have all the needed functionality “under the same hood” (a predefined theme, robust database, a user-friendly admin dashboard...) to be developer friendly to integrate easily and seamlessly with any modern JS front-end of your choice to “fuel” your website/app with high speed   Needless to add that: You can't have them all in one CMS, either traditional or headless. What you can actually do is:   set up a hierarchy with all your feature needs and requirements set it against each of these two types of CMSs' advantages and limitations    Just see which one of them “checks off” the most requirements on your list. Then, you'd have yourself a “winner”. So, let's do precisely that: A headless CMS vs traditional CMS comparison to help you determine which one's... a better fit for you.   1. Traditional CMS: Benefits and Challenges Everything in one place... That would be a concise, yet fully comprehensive definition for the traditional CMS. Just imagine a content management system that provides you with all the critical features and functionality, all the needed elements straight from the box:   a generic theme a dashboard for easily managing your own content a predefined database PHP code for retrieving the requested content from your database and serving it to the theme layout   The back-end and front-end, meaning the code, database, and the layout/design, are “under the same hood”, strongly coupled.  It's all there, pre-built, at hand... “Convenience” must be another word for “traditional CMS”.   Security & Performance: A Few Challenges to Consider  Getting all that critical functionality out-of-the-box does translate into... code. Lots and lots of code, lots and lots of files. Which also means lots and lots of potential vulnerabilities to be exploited. There could be an error in any of the files in that heavy load of files that you get. Or a query string parameter that could be turned into “free access” into your database... Therefore, the convenience of built-in functionality does come with its own security risks.  Also, whenever you make a “headless CMS vs traditional CMS” comparison, always be mindful of the maintenance aspect: Of the upgrading that you'll need to perform with every new security patch that gets released. Now, as regards the performance “pumped” into your traditional CMS-based website/application, just think: compiling files. That's right! Consider all those custom files, in addition to the pre-defined ones that you'll be provided with, that you'll pile up for... customizing your website.  All these files, all the new libraries that you'll want to integrate, will need to get compiled. Which can only mean:   more stress put on your server memory  copying code of functionalities that you might not even use a poor page loading time, with an impact on the user experience provided on your website   2. A Traditional CMS Is the Best Choice for You If... Now, you must be asking yourself: “How do I know if a traditional CMS is the best fit for my own use case?” My answer is: You go through the here listed “scenarios” and see if any of them matches your own.   you already have a team of PHP experts with hands-on experience working with a particular CMS (Drupal, WordPress...) it's a stand-alone website that you need; no other applications and tech stack that might depend on a CMS's provided functionality you're not opinionated on the technology that your website will get built on   3. Headless CMS: What Is an API-Based Website, More Precisely? “It's a CMS that gives you the flexibility and freedom to build your own front-end — Angular, Rails, Node.js-based, you name it — and integrate it with content management tools via an API." In short: your headless CMS can then serve raw content —  images, text values —  via an API, to a whole “ecosystem” of internet-connected devices: wearables, websites, mobile apps.  And it'll be those content-consuming devices' responsibility to provide the layout and design of the content delivered to the end-users. What's in it for you?   it dramatically streamlines the development cycle of your API-based website; you can get a new project up and running in no time there's no need to pile up lots and lots of files and the code of out-of-the-box functionalities that you might not even need if there's a particular service that you need — store form submissions or a weather forecast —  there's always a specific service with an API that you could integrate to have that particular content served on your website   A headless approach gives you the freedom to integrate exclusively the functionalities that you need into your website. Moreover, you still get a dashboard for easily managing your content. Your headless CMS will have got you covered on this. With no code being “forced” into your website/mobile app or need to perform a performance “routine” for this. You get it by default.   Security and Performance: Main Considerations In terms of security, a short sentence could sum all the advantages that you can “reap” from having an API-based website: There's no database... Therefore, there are no database vulnerabilities, no unknown gateway that a hacker could exploit.  Furthermore, in a “headless CMS vs traditional CMS” debate, it's important to outline that the first one doesn't call for an administration service.  Meaning that you get to configure all those components delivering content to your website as you're building it. Except for that, the rest of the dynamic content gets safely stored and managed in your headless CMS. “But can't anyone just query the service endpoints delivering content on my API-based website?” True. And yet, there are ways that you can secure those channels:   use double-authentication for sensitive content  be extra cautious when handling sensitive data; be mindful of the fact that anyone can query the JS implementation    Now, when it comes to performance, keep in mind that: It's just assets that your web server will provide. As for the content coming from all those third-party services that your headless CMS is connected with, it will get delivered... asynchronously. Now, considering that:   most of those endpoints are hosted in the cloud and highly flexible  the first response — the first static HTML file that gets served  — is instant you could go with a headless CMS that leverages a CDN for delivery in a traditional CMS scenario the website visitor has to wait until the server has finished ALL the transactions (so, there is a bit of waiting involved in there)   … you can't but conclude that in a “headless CMS vs traditional CMS” debate, the first one's way faster.   4. Use a Headless Approach If...   you already have your existing website built on a specific modern tech stack (Django, React, Node.js, Ruby on Rails) and you need to integrate it with a content management system, quick and easy you don't want your team to spend too much time “force-fitting” your existing tech stack into the traditional CMS's technology (React with... WordPress, for instance) you need your content to load quickly, but you don't want a heavy codebase, specific to traditional CMSs, as well you want full control over where and how your content gets displayed across the whole ecosystem of devices (tablets, phones, any device connected to the IoT...) you don't want to deal with all the hassle that traditional CMS-based websites involve: scaling, hosting, continuous maintenance    5. Headless CMS vs Traditional CMS: Final Countdown Now, if we are to sum it up, the two types of CMSs' pros and cons, here's what we'd get:   Traditional CMS It comes with a repository for your content, as well as a UI for editing it and a theme/app for displaying it to your website visitors. While being more resource-demanding than a headless CMS, it provides you with more built-in functionality.   Headless CMS It, too, provides you with a way to store content and an admin dashboard for managing it, but no front-end. No presentation layer for displaying it to the end user. Its main “luring” points?   it's faster it's more secure more cost-effective (no hosting costs) it helps you deliver a better user experience (you get to choose whatever modern JS framework you want for your website's/app's “storefront”)   It's true, though, that you don't get all that functionality, right out-of-the-box, as you do when you opt for a traditional CMS and that you still need to invest in building your front-end. In the end, in a “headless CMS vs traditional CMS” debate, it's:   your own functionality/feature needs your versatility requirements  the level of control that you wish to have over your CMS your development's team familiarity with a particular technology   … that will influence your final choice. Photo from Unsplash ... Read more
Silviu Serdaru / Mar 06'2019
Progressively Decoupled Drupal: Moving Towards a Standard Workflow
Progressively decoupled Drupal has gone from concept to buzzword. Until recently, when we've started to witness sustained efforts being made to set up a standard workflow for implementing this architecture. New dedicated modules have been developed to fit those use cases where just a few particular blocks, affecting the website's overall performance, need to be decoupled. All while preserving Drupal's standard robust features. Features too famous among content editors and site builders to be sacrificed in the name of high speed and rich UX.  We've gradually shifted focus from “Why would I choose progressive decoupling over a headless CMS?” to: “How precisely do I implement the progressive approach into my own decoupled Drupal project? Is there a standardized process, based on a set of dedicated modules, that I can leverage?” And this is what I'll be focusing on in this post here. More precisely, on the efforts for standardizing the whole workflow: see Decoupled Blocks and the SPALP module!   1. Progressively Decoupled Drupal: Compromise or Viable Alternative to an All-In Transition? Is this approach nothing but a compromise between:   content editors — and all Drupal users working in the site assembly —  who depend on key features like content workflow, layout management, site preview, seamless administrative experience and front-end developers, who're “dying” to “inject” application-like interactivity and high-speed front-end technologies into certain portions of the Drupal web pages?   Progressively decoupling blocks in Drupal is, indeed, the best compromise you could get between:   your editorial team's “fear” of losing familiar Drupal features critical for their workflow front-end developers willing to experiment with new technologies promising top speed and richer user experiences   Developers get to leverage the JavaScript framework of their choice without interfering with the site assemblers' workflow. Flexibility at its best! But does being a viable compromise makes it also a worthy alternative to the fully decoupling option? It does. Specifically because:   it caters to all those who haven't been won over by the “headless CM movement”  it removes the risk of trading vital Drupal functionality for the benefits of a powerful front-end framework   In other words: For all those Drupal projects requiring that only certain components should be decoupled, an all-in transition would be simply... redundant and unnecessarily risky. For all those projects there's the progressively decoupled Drupal alternative.   2. Why Has this Approach to Decoupling Drupal Been So Unpopular? How come the progressively decoupled Drupal strategy gained so little traction? It seems that despite its drawbacks — the need to reinvent some of the lost “Drupal wheels” and its higher costs — the fully decoupled approach has been more popular. And there are 3 main causes for this, that Dries Buytaert identified and exposed in his blog post on “How to Decouple Drupal in 2018”:   progressive decoupling doesn't leverage server-side rendering via Node.js modern JavaScript cohabits with old-school PHP JavaScript's ascension is not going to stop any time soon; therefore, the risk of sacrificing some of Drupal's popular capabilities might still seem insignificant compared to the JS advantages at a front-end level   3. The SPALP Module: Towards a Standard Workflow for Implementing Progressive Decoupling Now, back to this blog post's main topic: Clear pieces of evidence that we're finally heading towards a standardized process for implementing this type of decoupled system.   And one such evidence is the SPALP module: Single Page Application Landing Page.  Here's a specific use case, so you can get an idea of its role in the entire workflow of a progressively decoupled Drupal project: Let's say that you need to integrate a couple of JavaScript-based one-page apps into your Drupal website. The CMS will continue to be “in charge” of the page rendering, access control routing and navigation, while the JS apps would be developed independently, outside of Drupal. How would you configure these JS apps as Drupal web pages? You'd use the SPALP module to configure each one of them so that:   you stay consistent and “joggle with” the same configuration every time you need to add a new app to your Drupal website you make its easy for your content team to manage this entire ecosystem of single-page JavaScript apps   “And how does this module work?” Here's the whole “back-stage” mechanism:   the SPALP module helps you to set up a new “app landing page" content type, the one providing the URL for the app about to be integrated each one of these applications must have its own module that would declare a dependency on SPALP, include its JSON configuration and define its library once a module meeting all these requirements is enabled, SPALP will create a landing page node for it, which will store the initial configuration the SPALP module will add the pre-defined library and a link to an endpoint serving JSON each time that node is viewed   Note: speaking of the efforts made to create a “Drupal way” of implementing this decoupled architecture, you might want to check out Decoupled Blocks, as well. It's designed to empower front-end developers to use the JS framework of their choice to develop individual custom blocks that would be later on integrated into Drupal. No Drupal API knowledge required! The END! What do you think: will the community continue their efforts to build a standard workflow for the progressively decoupled Drupal approach? Or will it remain a conceptual alternative to headless Drupal? ... Read more
Silviu Serdaru / Jan 23'2019
WebAssembly vs JavaScript: Is WASM Faster than JS? When Does JavaScript Perform Better?
“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. ... Read more
Silviu Serdaru / Dec 07'2018
Media Handling in Drupal 8.6.0: 4 New Features that Will Enhance Your Media Management Experience in Drupal
The media management experience had been one of the well-known sources of frustration for Drupal content editors for a long time. For, let's face it: Drupal's out-of-the-box media support was just... basic. But not anymore: there are new exciting features for media handling in Drupal 8.6.0 that will dramatically change the way you manage your media assets on your Drupal website! Now, let's take a sneak peek at these most-anticipated media handling features that Drupal 8.6.0 comes equipped with:   adding media from a remote source adding various types of media embedding Youtube and Vimeo videos in the content (via URL) easily accessing and reusing the existing media uploading new media types right out of the box   And this is almost... overwhelming: From almost no built-in media support in Drupal, for so many years, to a whole set of modern, powerful media management options now in Drupal 8.6.0. But let's not ramble about this topic anymore and dive right in! Into the pile of new features meant to enhance the whole media management experience in Drupal:   But First: An Update on The Progress of the Media in Drupal 8 Initiative The main goal of this media initiative was to: Add a rich media support to Drupal 8. One that would empower the content editors to easily reuse existing media assets, add new media entities and to overall gain more control (and meta information) over their media. And there are 3 core milestones that we can trace while tracking the progress of this initiative for Drupal 8:   adding the experimental Media module to Drupal 8.4 in late 2017 leveling up this module from experimental to stable phase in Drupal 8.5.0 turning it into the standard way of storing media in Drupal    Moreover, starting with Drupal 8.6.0 a new key module for handling media has been added to core — Media Library — along with a few more exciting options:   quick access to the existing media assets oEmbed support a new media type: remote video content   Quite a “leap” forward, to a great media management experience in Drupal, I would say...   2. Welcome a New Media Type in Drupal 8: Remote Video Let us list the 4 media types that you could add to your site's content up to Drupal 8.6.0:   file image video audio   OK, now it's time you welcomed a new media type to the group: remote video! Basically, as a content editor you're now able to add videos from remote sources, as well — Vimeo and Youtube — via their URLs.   In short: you're no longer constrained to settle for the default media types in Drupal 8. No sir, now you get to create new custom ones mentioning their media sources. Summing up: embedding new media to your website content is nothing but a two-step process: Content-Add Media. 3. Reusing Media Is Now Possible: Media Library One of the much-awaited features for media handling in Drupal 8.6.0 had been reusable media. Well, here it is now: Media Library! It's where you can save and store all your media assets to be further reused whenever needed. Note: do keep in mind that this an experimental module and that you'll also need to enable the Media module first things first. “And how does it work more precisely?”   while in your content edit screen just browse through all the media assets stored in your Media Library select the one you need and simply “inject” it into your page   Note: it's the “Media library” widget, added to the Media field, that enables you to scan through all your media entities straight from the content edit screen. 4. The New “Media” Field: A Quick Way to Embed Media in Your Content Handling media in Drupal 8.6.0 is as simple as... adding a new field — “Media” —  to the content type in question (be it news, blog post, article and so on). Once the new field is added on, just go through the 5 media types available in Drupal 8.6.0 and select the one you need to embed. Next, you can simply integrate it into your content, while in your edit screen, positioning it to your liking.   5. New Media Handling in Drupal 8.6.0: Youtube & Vimeo Embeds A new media management tool that significantly improves the whole content editing experience in Drupal. You're able to embed remote videos from Youtube and Vimeo via URL, thanks to the now added oEmbed media support. “How precisely?” Basically, you simply:   add that new “Media” field to your content type, as previously stated select the “Remote Video” option from the “Media Type” drop-down menu enter your video's URL in the “Video URL” field, while in your “Add Remote Video” screen and click “Save”   And voila: you'll have your remote video integrated into your content! The END! As Steve Burge from OSTraining would say: “Finally we're getting somewhere with media in Drupal!”   What do you think about the new features for media handling in Drupal 8.6.0? What other options and tools are there on your wishlist? To be able to embed remote videos right from the node create page, maybe? Or to have other video platforms, as well, supported in Drupal? ... Read more
Silviu Serdaru / Sep 21'2018
What Is the Best Magento 2 Product Reviews Extension? Top 5
Let's just say that the default product review system in Magento 2 is... well... not 100% satisfactory for you. It does have its limitations; there might be some particular product reviewing and rating features that it can't provide you with. So, you start looking for an extension to compensate for this... inconvenience. But which one to go with? What is the most suitable Magento 2 product reviews extension for your own eCommerce store's needs? And it takes just a brief scanning of the large “pile” of Magento 2 extensions to start experiencing choice overload: How do you know which one's the best for your eStore? Which one suits your own idea of an “ideal” reviews system? But what if we narrowed them down to 5 choices only? The 5 best Magento 2 review extensions to start your searches with:   But First: The “Ideal” Magento 2 Reviews System —  Main Characteristics What features should the reviews system on your eStore have to meet all your expectations? Let me guess:   reviews should be accompanied by the customers' real names, photos and maybe even a link to their social media accounts, as well customers should be able to rate products on a “pros & cons” scale the reviews section should be easily noticeable on page the reviews system should empower you with the proper tools to use for encouraging customers to insert informative, relevant reviews only … needless to add that the UI of the add review screen should be highly intuitive the reviews should show product photos, as well the reviews system would enable you, the admin, to easily sort product reviews by relevance/helpfulness   The Default Magento Product Reviews Feature: How Does It Work? Before we delve right into the mini pile of Magento 2 product reviews extensions that I've prepared for you here, let's see: How does the default reviews functionality work in Magento 2? On the user's side, he/she writes down his review in the text description field popping up once he's rated the product from 1 to 5. Whereas on the admin's side, you get to configure those ratings at Stores > Attributes > Rating, right in your Magento 2 admin dashboard.                                        Images: Potatocommerce.com   The Advanced Review for Magento 2 Extension  You cannot run your evaluation of the best rated Magento 2 product reviews extensions and skip this module here. Why? Here are the top reasons for considering it:   it provides a detailed product reviews system, with pros and cons it makes it possible for the published reviews to be rated as helpful/unhelpful … and to be shared across social media networks, as well it features review captcha and report reviews, helping you minimize the risk of fraud and spam it boosts the product reviews system with custom rating values (quality, price and so on)   The Import/Export Product Reviews Extension  A handy Magento 2 extension if you're “juggling with” multiple online stores. Basically, it enables you to import/export product reviews from one eStore to another via CSV file.  Note: while importing them, you, the admin, get to set their status using the CSV file The extension's most valuable features:   it makes it possible for reviews to get transferred along with their titles and descriptions via CSV file it supports a multi-store environment it empowers you, the admin to approve/disapprove the submitted reviews   Magento 2 Review Booster: The Best Magento 2 Product Reviews Extension?  Another product reviews and rating extension for Magento 2 that you shouldn't overlook while determining your best option. And here are some of its main functionalities:    pros and cons  reviewing the written feedback's helpfulness uploading images to product reviews the possibility to “lure” customers with different discounts/coupons for reviewing the products they buy review reminders adding comments to product reviews sorting product reviews by rating   The Magento 2 Product Reviews Extension  Another extension that has the potential to get you closer to that “ideal” Magento 2 reviews system of yours. Here's how precisely:   it enables customers to upload images of the product review form (no registration required) it's ideally easy to install & manage you get to integrate the product review functionality through a widget you, the admin, get to review the uploaded images' widths & heights   The Magento 2 Review Reminder Extension   Now, could you imagine the reviews system on your Magento 2 website without a powerful review reminder type of tool plugged in? I didn't think so... They make such handy tools to help you encourage customers, via email reminders, to post reviews for the products they've bought. Now, here are the key features of this specific tool here, an essential Magento 2 product reviews extension:   targeting specific groups of customers that you'd send your email reminders to sending automated reminder emails using coupons to entice customers to share their first product reviews and even choosing its template cleaning log records automatically, after a specific no. of days setting up the right time for sending the first reminder email   The END! These are the 5 best Magento 2 review extensions to add to your shortlist and start your “research” with.    feature-rich powerful easy to set up and customize on your side easy to use on your customers' side   … each module, taken separately, injects those product reviews functionalities into your store to help you enhance the built-in reviews system that the platform provides you with. ... Read more
Silviu Serdaru / Sep 13'2018
3 Essential Steps to Convert Your Website to a Progressive Web App
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. ... Read more
Silviu Serdaru / Jul 24'2018
How to Speed up Your Magento 2 Store on Mobile Devices: 5 Tweaks That You Can Make
What can you do to speed up your Magento 2 store on mobile devices? For let's face it: Magento 2's “ecosystem” of third-party extensions and overall its modular architecture is convenience at its best for any developer! For any eStore owner. It empowers them both to start small and then scale it up to their most daring goals. Yet, all this power placed in your hand does come at a cost: reduced speed. And top speed is crucial if you're determined to deliver a great mobile user experience. So, what are the tweaks that you can make to boost your eStore's performance? Luckily, there are plenty, ranging from:   well-known (and too frequently underrated) best practices, like optimizing your product images to slightly more in-depth “tweaks”, like inlining critical CSS   But, let's dive right in! Here's your “emergency kit“ of 5 solutions to apply to your Magento 2 store for improving its performance on mobile:   1. Reduce Page Size to Increase Page Loading Speed  And it's still those “too obvious to be truly effective” type of techniques that have the biggest impact on an eStore's performance on mobile devices: Lower your web page size and it will make a drastic difference for your mobile users' experience with your online store; especially for those accessing your site from mobile devices with low bandwidth. Now here are a few simple, yet effective tweaks that you can make to reduce page size:   1.1. Use GZIP  to Compress Your Pages A handy “trick” that you can perform is to enable GZIP (if it's not already enabled) and let it “work its magic” on your web page's size. It will compress:   fonts CSS files external scripts JS   … cutting your pages' “weight” down by almost 70%. Note: put any of your front-end pages to the Google PageSpeed Insights “test”; take note of the GZIP-related warnings popping up and ensure that the CSS/JS compression feature is enabled.   1.2. Enable JavaScript/CSS Files Minification Here's another built-in Magento 2 feature that all you need to do is... trigger to speed up your Magento 2 store on mobile devices: CSS/JS files minification. Note: do keep in mind, though, that it works in production mode only (so not in default or developer mode, as well)! Here's how you enable it:   Navigate to the backend menu Stores > Configuration > Advanced > Developer Set your app/site's production mode:   php bin/magento deploy:mode:set production Note: not sure what mode your eCommerce site's running on now? Enter the following command to identify its current mode: php bin/magento deploy:mode:show 1.3. Optimize Your Product Pages  And the more crowded your product catalog is, the more important this solution becomes! “Are you implying that I should take each and every one of my product images and optimize them... one by one?” you might ask yourself. Definitely not! Since there are at least 2 easy solutions that you could go for:   you can use a content delivery network (CDN) as it will take the image optimization “burden” off your back you can leverage the Google PageSpeed (GPS) server extension; it will compress your images in no time, among other “tricks” that it performs to speed up your Magento 2 store on mobile   2. Reduce The Server Response Time to Speed up Your Magento 2 Store  Optimizing your server's response time (or “time to first byte”) is another critical tweak that you can do to boost your Magento 2 store's speed.  Set your “target” to 0.5s, the time a browser would need to wait for your website's server response. “But why bother, since Magento provides me with full-page cache functionality right out of the box”, you might wonder. That's true, but just consider particular pages, such as checkout, customer pages, cart, that this pre-built functionality can't “work its magic” on.   2.1. Run a Throughout Audit on Your Third-Party Extension "Load"  Start reducing your server response time with a basic, yet so very effective step: Audit your entire modules infrastructure! identify any issues with your current plugins and (if any) look for a patch or replace them with more performant ones turn them on and off just to detect any negative impacts on your Magento 2 site's performance    Note: as a rule of thumb, try keeping your Magento 2 third-party extensions to a minimum! Trim down your collection of modules keeping only the must-have ones; otherwise, its weight will affect your eCommerce site's performance!   2.2. Use Magento 2 Profiler to Detect Any Server Performance Issues “What's a profile?” you ask.  A program geared at identifying just how much time a code block needs to execute. Using a profile you'll be actually drilling deep(er) into your Magento 2 store's internals to detect the very root cause of your bad server response time!   2.3. Consider Upgrading Your Hosting Plan Is it time you upgraded your hosting server? More RAM and CPU will always have a huge impact on your eCommerce website's performance, you know. So, how do you know whether it's time to upgrade? Just install a brand new Magento 2 website on your current server. If it's speedier than your live website, there's no need to change your current hosting plan. In this case, you'll only need to focus on the other tweaks included in this list here to speed up your Magento 2 store on mobile.   2.4. Use Varnish as a Full-Page Cache (FPC) Solution Another trick for improving Magento 2's performance is to leverage Varnish, the software that caches and serves content. The good news is that Magento 2 supports it natively. And here's how you trigger its “power”:   navigate to the backend menu Stores > Configuration > Advanced > System > Full Page Cache   Note: you'll need to enter a hostname, port and Varnish export configuration; if in doubt, ask your system admin for a hand to set everything up properly. 3. Load and Render Above-the-Fold Content First  Prioritize the content that appears before scrolling down! It will make all the difference when it comes to your Magento 2 eStore's page loading time! And now, here are the techniques at hand for loading and displaying this content first:   3.1. Defer Loading JavaScript  Moving all your JS code to the bottom of the page (“beneath the fold”) will implicitly make your AF (above-the-fold) content load quicker. You'll basically postpone the time-consuming parsing of JS code and thus speed up your Magento 2 store on all mobile devices! The good news is that there already are Magento 2 extensions that do the job for you. They'll move all your non-critical JS scripts beneath the fold!   3.2. Inline Critical Above-the-Fold CSS “But what about the above-the-fold CSS?” you might legitimately ask yourself.  How do you approach these critical files? For you definitely can't place ALL your CSS at the bottom of the page, now can you? Well, first you:   extract/isolate precisely this “critical” CSS then you inline it straight to the HTML; right between <head> and </head> tags   This way, it will get loaded and rendered first (before the non-critical CSS), along with the rest of the above-the-fold content.  Note: you might be tempted to go for one of those tools “promising” you to extract this CSS for you. Unfortunately for you, manually setting the critical CSS for each one of your pages (homepage, checkout, category etc.) is the right way to do it.   4. Leverage the Power of HTTP/2  By moving your Magento 2 website over to HTTP/2 you'll grant your eStore users a secure and faster-browsing experience. Not to mention the impact that it will have particularly on the experiences of those customers using a slow mobile network to access your online store. The tremendous news is that Magento 2 co-exist with HTTP/2 by default. Yet, there are 2 conditions that you need to make sure your online store meets:   your hosting server should already support HTTP/2 your eCommerce web pages should be served via SSL   Note: run your own "investigation" and look for some suitable extensions providing server pushes.   5. Magento 2 Performance Optimization: Disable JS Bundling But why would you want to disable a Magento 2 feature that actually lowers the HTTP requests made by your browser for loading and rendering a web page? Because it comes with its own side-effects, the main one being the oversized JS file that this feature generates, of about 5-10 Mb. Moreover, it's proven that downloading this huge external file takes more time than the time you'd actually be saving by reducing the no. of HTTP requests. Now that we've tackled the “Why”, let's focus on the “How”, as well. Here's how you disable JS bundling:   go to your website's backend menu Stores > Configuration > Advanced > Developer and apply the following configuration:   Note: there's no need to disable this JS files grouping feature if you're already using HTTP/2! The END! These are but 5 of the handiest solutions that you could use to speed up your Magento 2 store on mobile. As you can see, the list includes nothing more than predictable “tweaks” and well-known best practices that you should stick to.   ... Read more
Silviu Serdaru / May 23'2018