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
Docker Image vs Container: Closely Related, But Distinct. What's The Difference?
Welcome to... Dockerland, a place of never-ending confusions! The most frustrating one of them all — for every novice planning to explore Docker — being the “Docker Image vs Container” dilemma. “What, aren't they one and the same concept?” But you know that this is a rhetorical question: you just sense that they're 2 distinct concepts... Yet, you can't really identify the differences: How are Docker containers and images different after all? Now let's clear up the Docker Image vs Container confusion once and for all: First Things First: What's a Docker Image? A file (or file-like... thing) that gets built from a Dockerfile, by running a "build" command.  Moreover — and this is particularly important in defining a Docker image and setting it apart from containers — it's an inert, immutable type of file. A template-like file (you could also imagine it as a snapshot of a container). It's only when started, with the docker command, that a docker image starts producing a container. And since images in Docker tend to grow quite large, they're built on a layered structure (multiple players of other images). This way, only a small “load” of data gets sent when loading images over the network. Wrapping Up:   you can take the docker image as an application that you'd like to run a docker image can't be “running” or be “started”; once the “docker run” command is... run (obviously!), the image grows into a docker container, so... mind the inevitable confusion   Which Leads Us to The Question: “What's a Docker Container Then?” The not 100% accurate, yet generally accepted (even if halfheartedly) definition is:  “A container is a running instance of an image” Now, let me detail... Practically, the very act of running a Docker image produces a Docker container. You won't find a more straightforward explanation than this one! And containers are (or they should be) the very reason why “learning Docker” turned into one of your top resolutions for 2018 in the first place. For they're:   lightweight using fewer resources portable easy-to-be-deployed   … ways of running and managing your applications. If you're fond of analogies, here's one that will undoubtedly help you come up with a clear answer to your “Docker container vs image” dilemma: If a Docker image was a class, then a Docker container would be an instance of a class (a runtime object).  Wrapping up now:   once you start an image in Docker (so once you use the “docker run” command) you basically have a running container of this image in question   a container is created by adding a top writable layer to a Docker image and thus by initializing multiple settings (container name, ID, network ports etc.)   and it's due to that very writable layer, storing all the changes applied, that you can have multiple containers running off the same image; each and every one of them preserving its own distinct data state   Docker Image vs Container: Key Difference Revealed The most significant difference clearing up the confusion is the following: There is a top writable layer setting Docker images and Docker containers apart It's that very layer, storing all write operation corresponding to the containers in question, which:   gets deleted along once/if the container, itself, gets deleted, while the underlying image remains intact   enables multiple containers to share the very same underlying image   Now to better explain the key differences founding this dichotomy, let's reduce everything to a simple, clear-enough (hopefully) formula: a docker image + a docker run command = a docker container (meaning a running instance of the docker image) … a container equipped with its own writable layer and which can get listed via a "docker ps" command Is everything any clearer and simpler to you now?   Or Maybe a Metaphor Example Suits You Best? In addition to my “class vs instance of a class” analogy, let me try now explaining this tricky Docker dichotomy by using a metaphor... or two:   Let's say you have a film and a VHS of (which stands for our “image” in Docker). Then, imagine you'd place that VHS into your “virtual” VCR. In this case, the VCR stands for your Docker container. Better?   Or you could see the Docker image as an executable file on a disk (an app's file); once you run your application, it promptly creates an instance running in its memory. Now that very instance is our metaphorical Docker container.   Have I managed to clear up your confusion or just... deepen it instead?   Docker Image vs Dockerfile: How Do You Set Them Apart in “Dockerland”? Now, let me rewind to the stage where we can't even be talking about containers (not just yet). Where not even Docker images are yet built: the Dockerfile stage. You can take a Dockerfile as a... recipe for creating Docker images. And here's how the “cooking of an image” takes place:   a Docker command is run in that Dockerfile and so an image gets built   Clear as daylight: a Dockerfile is a... file that you create which, in return, creates a Docker image when you run a separate build command.   The END! Do be honest now: have I managed to clear up your “Docker Image vs Container” confusion? If so, then “solving the puzzle” around this dichotomy will make a huge jump start on your Docker learning plan for 2018. Happy learning!             ... Read more
Silviu Serdaru / Jan 23'2018
Progressive Web Apps vs Native Apps: Which Type of App Best Serves Your Needs? Part 2
Native Apps: They're Not Going Anywhere... Not Anytime Soon In other words, in the "progressive web apps vs native apps" competition PWAs make an alternative, not a replacement for native apps. For native apps are here to stay and still offer plenty of advantages themselves, too, (while progressive web apps do have their own limitations to consider, as well) for companies and developers not to give them up anytime soon. And here are just some of the key reasons why they continue to steal the spotlight. Reasons that might help you find your own answer to the “PWA or native app?” question:   big brands, already having their own native apps running on their preferred platforms, don't feel the same pressure as low-budgeted companies to switch to PWAs; it's some sort of “inertia-driven stubbornness”   app developers with a wide experience with IOS or Android don't feel like replacing their familiar work routines with a PWA-specific one, even if the latter is less complex   let's admit it: the web-based app development does come with its own limitations that still need to be addressed    Progressive Web Apps vs Native Apps: 6 Reasons to Go With a Native App As PWAs exploit some of the native apps' drawbacks, so do the latter turn some of their “rivals'” limitations into their own strong points. For instance:   PWAS might be widely adopted thanks to their universal compatibility, hassle-free user experience and short development time, yet they're not capable to interact with the devices that they run on   native apps can do that; moreover, they're perfectly adapted to leverage a mobile device's smart functionalities   also, PWAs run in web browsers, which, might turn into a disadvantage: it could slow them down    … whereas native apps, being installed on the given devices, first things first, will inevitably load a lot faster; there's no longer a browser intermediating the process    Now, let's dig out other strong reasons for... going native:   1. No Ifs and Buts: They're Faster As previously mentioned: with the web browser acting as an intermediary, progressive web apps can't compete with their native “rivals” in terms of performance. As opposed to PWAs, native apps are installed on the devices that they run on. Therefore, not only that their code practically “lives” there, but it's platform-bound. Written with the requirements of that specific mobile operating system in mind.   2. They Come With Built-In NFC Support  The “Near Field Communication” support is vital for certain businesses. So, do consider this native apps' advantage (or this PWAS' shortcoming, depending on how you want to put it) before you give a final answer to your “progressive web apps vs native apps” dilemma. If it's of critical importance for you that your customers should be able to pay for your services with their phones, then you need to go native. There's no way around this! PWAS can't yet interact with the NFC chip enabling this type of payment.   3. They Provide a Quality Control Guarantee  All the app stores' “bureaucracy” might be discouraging enough, yet there are good intentions — resulting in a quality guarantee —  behind all those steps to take: filling out forms, reading specific forums, following strict app development guidelines, waiting for your app's review process to be carried out etc., etc. Instead of seeing them strictly as... highly restrictive, take them as multiple filters that clear your app of any malicious code. As for PWAS, just think about it: The easier it is for anyone to access your app by just visiting the web page hosting it, the easier it is for a hacker, as well, to exploit the vulnerabilities of that connection.   4. GEO-fencing: A Superpower Placed in Your Hands And this is no exaggeration, especially if it's a retail app that you're planning to develop. Just give it a moment of thought: GEO-fencing will enable you (your marketing team) to define virtual “boundaries” in the real world; once a customer's mobile device enters or exits that defined area, a push notification gets triggered. A powerful functionality to ponder on when you're facing a “progressive web apps vs native apps” decision-making challenge. A smart functionality that native apps can easily exploit, while PWAs can't.   5. They Can Leverage a Device's “Smart” Capabilities And this is one of the major advantages of native apps over progressive web apps! They interact with the mobile devices that they're installed on, meaning that they use their smart features to their full potential. Features such as:   proximity sensor wave lock: you don't want your users' phone screens to go black right in the middle of a video you've inserted in your app, now do you? ambient light   6. They Easily Interact With Other Apps Take for instance this highly frequent scenario: A user tries to set up his/her account within your app and he's given the option to enter his Facebook login details It's the perfect example of native apps interacting with one another. And this is but just one example of inter-app communication that helps users save valuable time.   So, What Kind of App Should You Develop After All? “ The one that best serves your needs.” So, get them clearly defined first things first:   Do you need to develop a basic customer service/retail app? And, moreover, you're both budget and time-limited, as well? Then a progressive web app might just be the perfect fit for your project's needs.    Is it a mobile app exploiting smartphones' advanced functionalities to the fullest that you need to build? Then you should consider opting for a native app: it's fast —  which will definitely impact the overall user experience — it integrates with multiple payment gateways and it harnesses the power of “smart” features (Geo-fencing, NFS, wave lock etc.)   Also, when trying to pick your winner in the “progressive web apps vs native apps” contest, consider the expected future advancements, as well:   mobile devices will get injected with more and more advanced technologies, tilting the balance in native apps' favor    progressive web apps will continue to be constantly supercharged with new and new functionalities, that go beyond a web browser's standard ones (integration with Bluetooth, with NFC, with smart devices' hardware features)   That being said: the choice is yours to make! I've only pointed out the main criteria and the key benefits/limitations for you to weigh and to compare, so you can make a fully informed decision. ... Read more
Silviu Serdaru / Jan 12'2018
Progressive Web Apps vs Native Apps: Which Type of App Best Serves Your Needs? Part 1
The paradox of choice, right? Didn't it use to be so much easier back in the old days, when you had just one option at hand? "You wanted to go mobile, you just knew this meant “pumping” money into a native app." Clear as a day! But what do you now, when you're facing a "progressive web apps vs native apps" situation? Which app development approach is the perfect fit for you? For the nature of your business and for your app project's specific needs? PWAS seem to be “stealing the show” these days: first they intrigue, next they “seduce” with the hard-to-resist-to promise that they deliver: Empowering small businesses to compete against the "giants" in the mobile app development arena! And still: native apps won't be going anywhere anytime soon! Moreover, they'll get even more robust and faster, as the devices that they run on get more and more advanced. And as they'll continue to leverage their great advantage over progressive web apps:  Leveraging mobile devices' smart features and capabilities and thus delivering an enriched user experience. Now, to put an end to your “turmoil”, I've come up with a sort of “inventory” listing the set of benefits that you can reap from choosing one type of app over the other. Here it goes:   But First: What's a PWA? And How Is It Different from a Native App? “An app running inside the user's web browser, that he/she doesn't need to download and install beforehand. And which, moreover, is injected with native app-like functionalities and wrapped in a seamless user interface.” This should be a clarifying enough answer to your “What's a PWA?” question. Bottom line, the key difference between PWAs and native apps is: The first ones run inside web browsers, while the latter run on the mobile devices that they're installed on. The concept behind this revolutionary approach to app development is both daring and ambitious: Cutting down the overhead and the discouraging complexities usually associated with a native app's development process. And thus:   reducing time and costs eliminating the step where your users download it from an app store    Progressive Web Apps vs Native Apps: Top 7 Benefits From Choosing a PWA For it all comes down to benefits, right? What's in it for you if you choose one app development approach over the other? The level popularity that one type of app has gained falls shortly behind the very set of benefits that you get. Now here are the most valuable ones to consider when you're having a “PWA vs native app” dilemma:   1. You'll Reach Out to A Significantly Wider Audience, With Fewer Resources As compared to developing an Android-focused or an IOS-focused native app, a PWA will practically grant you access to all platforms. It's a “develop once, run everywhere”, type of situation: A PWA is a “platform-agnostic” type of app. Needless to add that your progressive web app's extreme versatility will help you reach the widest audience way quicker and with minimal costs.   2. You'll Reduce The App Development Cycle Times  And this is, undoubtedly, that heavy-weighting advantage tilting the “progressive web apps vs native apps” balance in PWAs' favor. The very reason why progressive web apps gained so much attention in the first place. With native apps' development process “famous” for:   all the headaches it causes all the complexities specific to any platform-bound solution all the time-consuming steps to take: crafting some eye-catching screenshots, writing down the description, identifying the right keywords and strategically sprinkle them across the description...   ... PWAs emerged in a highly favorable context and they “exploited” precisely the overhead associated with a native app development cycle. So, they managed to “lure” developers unsurprisingly easily by:   eliminating most of those complexities from the app development process eliminating the need to build multiple platform-bound versions of the same app   Also, it goes without saying that reduced development times translate into reduced costs.   3. It's a Unified User Experience That Your App Will Deliver  The advantage of being platform-agnostic bubbles up to the user experience itself. Having a unique version of your PWA running on all platforms, accessible to all customers, it'll be easier for you to deliver the same user experience to your entire user-base.   4. A Hassle-Free User Experience Requiring the Minimum of Effort Compare the 2 following scenarios: a. a hypothetical user visits a certain app store, chooses an app, waits for it to download and then goes through all the steps required for installing it on his/her mobile device b. a hypothetical user lands on a website and gets to use the app right there, almost instantly, with no prior installation; moreover, if he/she wishes, he can save the link as an icon on his device's home screen Isn't it obvious why, in a "progressive web apps vs native apps" competition, the advantage of easy access will always outweigh most of the native apps' benefits? In a few words:    you, as the app owner, get to deliver the content you wish to deliver with utmost ease while your users access it using the fewest numbers of steps … and high accessibility translates into a higher level of user engagement   A win-win situation!   5. Users No Longer Need to Install The Latest Updates Themselves A major convenience both for you and for your apps' users:   you'll get to easily keep them up to date with all the changes that you might apply to your services with no updates to run and no need to re-download the app, users always get the latest version of your app, upgraded with the most recent functionality features that you will have added to   6. Extended Compatibility: All It Takes Is a Modern Web Browser That's right since PWAs run on HTML 5 — the standard for web content — a modern web browser on his/her mobile device is all that a hypothetical user needs for accessing your app. Talking about maximizing your app's reach, right?   7. You'll Cut Down Costs For Building and Marketing Your App You can get a progressive web app up and running (and marketed) in no time! With considerably fewer resources of time and money to invest. So, if:   you're facing a limited budget you're in the retail or hospitality business   … the benefit of bringing your customer service app to your customers quickly and in a cost-effective way is just... priceless.   The END! Well, not the end on my post on the progressive web apps vs native apps “competition”, but the end of the list of reasons why you should consider going with a PWA instead of a native app. Stay tuned, for in the second part of this post I'll be:   putting the spotlight on mobile native apps revealing to you all the benefits that you can enjoy from choosing this type of app development approach ... Read more
Silviu Serdaru / Jan 12'2018
Vue Vs React: Which One Should I Use for My Front-End Project?
Ready to set up your web app? One which, needless to add, should deliver your users a feature-rich front-end experience? Great! Now comes the truly challenging part: deciding which JavaScript UI component library — Vue vs React — is right for your web project! For its specific needs and requirements:   is it a small or a large scale one? is it one overloaded with dynamic elements? do you plan to go mobile, too? do you want it built fast or do you want it capable to scale up in order to accommodate all future functionalities and features?   And the debate is nothing but: convenient simplicity and lightness vs superpower backed up by a thriving community  But let's not move away from your initial “dilemma”: “In a Vue vs React competition, where I get to choose the most appropriate front-end framework that should power my future app, which one's the winner?” Let's bring in the 2 contestants on the “stage” now, shall we?   But First: 2 Crucial Questions That You Should Be Asking Yourself Beforehand   1. Will it be a web or a native app? And this is a critical question to be asking yourself way before you start your “investigations” on the 2 competing JavaScript UI component libraries. Here's why:   React has got you covered whether it's a web application (ReactJS), a native mobile app (React Native) or... even a virtual reality front-end app that you're planning to develop. And this is, no doubt, one of the most heavy-weighing answers to the question: “Why React over Vue?”   Vue2.0 has made a big step forward, towards a native approach (and here I'm referring to Weex, of course); and even if it still can't get anywhere close to React Native's built-in support for building native mobile apps, it's still a “promise” for the future to come.   2. How Much Time Do You Have Till You Need to Actually Start Building It? In other words: is it an “ASAP” type of app developing situation or you do have the “luxury” to invest as much time as needed in learning a new JS framework? And this question is more than relevant (and helpful for narrowing your 2 choices down to 1 from the start) since:   ReactJS can be discouraging for some, due to its quite steep learning curve; from its terminology to its heavy documentation, everything looks less familiar, less intuitive, more frustratingly complex   Vue.js, on the other hand, has “seduced” lots of its current advocates precisely with its low learning curve: it “spoils" them with familiar CSS, HTML, ES6 and where do you add that it doesn't call for a Webpack either.   Basically, you get to explore and capitalize upon Vue.js's potential right away, in pretty much any code sharing environment.   Go With Vue.JS If...   1. It's simplicity in syntax that you value most in a web framework  In a “Why moving from React to Vue?” debate, the argument of “extreme simplicity” would have to be the strongest one. That's right, this JavaScript UI framework's simplicity is built deep into its design. Moreover, the familiarity of the concepts that it uses (or better said “copies” from its main 2 “rivals: React's virtual DOM and Angular's two-way data binding) could be enough to help you find the answer to your “Vue js vs React” personal debate. You just run your Vue.js project right from your web browser! And its simple syntax bubbles up to the easiness of altering the state data (not to mention that this also makes it significantly easier to pick it up).    2. It's a small scale, ideally fast web app that you're planning to build Since page size is a game-changer (isn't it?) when it comes to building an app, Vue.js comes to tempt you with its surprisingly low weight (approx. 25.6KB once minified). Now you do the math how this will impact the rendering system and, overall, how it will tilt the balance in any “Vue js vs React speed” comparison.   3. You're more into a “templatey” way of building apps And how could you “resist” a default template structure after all (and even so more if you're not new to AngularJS)? One that uses old-style HTML templates. Basically, you get to drop your markup into an HTML file and thus:   use already familiar (aren't they) HTML attributes for injecting the needed functionality into your default template  use pre-processors clearly separate layout from functionality    … as compared to building your app using ReactJS, which uses a whole different approach: it requires you to put together your own DOM using a JSX syntax. Note: yet, some might argue though that templating comes at a cost, that of learning the extended HTML syntax, as compared to the rendering functions. And, moreover, that React's JSX syntax puts superpowers in the hands of the developer, once he/she gets familiar with it. Since it enables him/her to use JavaScript in his template. And yet: stay assured, Vue.js 2 now provides you with both render functions and a templating option for setting up your web app!   Go With ReactJS If...   1. You Want to Easily Build an App That Should Work on Both Web and Mobile Convenience at its best! This is how we might call Facebook's “protegee's” two-faceted nature:   ReactJS for building your high-power, interactive web app's interface with React Native for building your next best thing in terms of native apps   No need for you to knee deep in learning the nitty-gritty of a whole new JavaScript UI component-based library. Instead, you'll be using the already familiar React for carrying out both your plans (to build a web and a native app), “juggling” with web components and respectively with native components.   2. It's a Complex, Large Scale App Project That You Have in Mind If that's the case, then the following argument might just be a decisive one in your Vue vs React “dilemma”. For React is built with the specific needs of large-scale apps in mind! Which means that it's perfectly equipped for injecting them with high performance! And it's precisely when you're dealing with an overly complex app project that you realize that:   transparency and testability are crucial for you a template system is way too restrictive, far less configurable (although it would help you to create a React app and get it up and running in no time)   In this respect, React's JavaScript-made templates grant you the freedom you need for:   reusing easily testing restructuring   … your conveniently decomposed code. And this is the “superpower” that React lays in your hands: it allows you to “split” its JavaScript structure into multiple components, that you can easily test and reuse! It “spoils” you with an ideally configurable rendering system.   3. It's a Huge Ecosystem and a Thriving Comunity that you value most  React's indisputable “fame” — not to mention Facebook's backing — does come with its benefits. Advantages that you can capitalize upon:   more resources out there for you to delve yourself in and to leverage in your app (tutorials, articles, Stack Overflow answers, etc.) a wide range of add-ons and tools for you to select from and boost your project with the guarantee that you'll benefit from continued maintenance (given by Facebook's patronage and, therefore, by the whole “army” of React developers that commit themselves to keep it closely  monitored)   And The Winner of This "Vue vs React" Dabate Is... Have I made you even more confused? Is it even harder to state which front-end JavaScript framework would win the Vue vs React debate? One's “seducing” you with a simple syntax and set up, the other one with its scaling capabilities. One “boasts” with faster rendering if it's a small app that it's powering, while the other one empowers you to build both web and native mobile apps. And where do you add that the two UI frameworks share a considerably large set of features, as well:   they're both conveniently lightweight they're both open source they both use virtual DOM and reactive components they both rely on server-side rendering … and are both component-based libraries providing you with a “backbone” in terms of functionality.   So you'll need to rely on third-party frameworks for handling any extra functionality (state management, routing, etc.) that you're planning to equip your future app with. Decisions, decisions... Now here are a few conclusions deriving from my little presentation here that might help you decide a bit easier:   opt for Vue.js if it's a new JavaScript framework that you'd like to drop into an already existing codebase choose the React library if you're planning to leverage web technologies to develop a native mobile app go with React if it's a SPA or a really complex, large-sized app that you're planning to build   So, is it any easier for you now to solve your Vue vs React dilemma? ... Read more
Silviu Serdaru / Jan 08'2018