DEV Community: JSGuru

Go for PHP or Any Other Developer

Sasha Blagojevic — Mon, 27 Jan 2020 10:23:01 +0000

Long time no read! I’ve been quite busy building awesome stuff for our clients so I haven’t had the time to write in quite a while. I still don’t have it to be frank, but this is gonna be a somewhat short read so I managed to squeeze it into my schedule.

TLDR

If you’re not interested in the story behind this list just skip to the end. I highly recommend covering these resources if you’re considering learning GO.^[c]

Why Go suddenly?

I’ve been helping out on an awesome big data / IoT project which is powered by none other then GO! Our client was coming from a Python background and when you add the terms Big Data and Internet of Things to this mix you can clearly see why GO is a natural fit for this project.

It has been really interesting switching from PHP to Go lang. I must admit at the beginning it was a bit of a challenge to wrap my head around all of the different concepts. Not only was I switching from a scripting language to a compiled one, but Go lang is also a functional language, where as PHP supports both the Functional and Object Oriented Paradigm.

To add fuel to the fire GO lang has its own twist with its concurrency model - goroutines and channels.

When your client demands GO lang as the power train you can be pretty sure it’s not going to be a walk in the park, you can expect it to be a high performance / high load type of a project so there will be no cutting corners and optimization needs to be on your mind all the time!

I’d consider my role in this project as kind of a sheepdog since I was setting the path and guiding our junior developers as they do tend to behave like lost sheep sometimes. Client being the shepherd in this analogy I guess lol.

Major Differences between PHP and GO

Aside from the obvious fact that GO is a compiled language these are some of the major differences:

Switch statement does not fall through by default, you have to explicitly add the fallthrough keyword
For is the same as While, that’s the only loop keyword

There are no Classes / Objects, there are Structs which have some of the behaviour, they can have members and methods defined on them
There are no explicit access modifiers like public, protected and private but there is a naming convention. If you declare a variable / type / function lowercase first it will be treated as private on the package level, if you define a member / method lowercase first on a Struct it will not be accessible publicly. On the other hand if you write them uppercase first it will be publicly accessible.
Since there are no Classes there is no Inheritance, but we can achieve Polymorphism because GO has Interfaces.
Interfaces in GO have their own twist and are a bit different than in PHP. While in PHP you have to specify which class implements what interface in GO every data type implements an empty interface{} by default. You can think of this interface{} as something similar to TypeScript’s any. When you create your own custom interfaces you will need to add the implementation of these methods on the desired structs. GO will not check if the interfaces are satisfied during the build process, unlike some other compiled languages, it will be evaluated during runtime when the actual method is called, if you call the method on a Struct that does not satisfy the type hinted Interface your application will fail.
There are no exceptions in a traditional sense, there are no try / catch blocks although there is a proposal to introduce try. What we have though are panics and recover, but recover can only be used to recover from a panic that happened on different goroutine. How do we handle errors then? Well, GO functions have multiple return values. Usually the first value is the desired result and the second value is the error if there is any, otherwise nil.

I’m of the opinion that each language should be written in its idiomatic way, that is the way to get the most out of the language and in addition your code will be easily understandable by the wider community and new developers that might join you or replace you later on.

That’s the whole point behind language style guides, admittedly some have a more strict some less, some don’t have one at all - PHP didn’t have one for a long time before PSRs came into play and our community was honestly a mess, a million of different styles and approaches that just unnecessarily added to our cognitive load.

That being said this is a list of resources that you most definitely should read if you want to write idiomatic Go and follow community best practices:

Must Read / Watch List

1. Official Go Code Review Comments

2. Go Standard Project Layout (Community)

3. Ben Johnson - Standard Package Layout (Community)

4. Go Docs - Package Naming

5. Peter Bourgon - Go Best Practices Six Years In (QCon London 2016)

6. Peter Bourgon - Go For Industrial Programming (GopherCon EU 2018)

7. Ashley McNamara + Brian Ketelsen. Go best practices (GopherCon Russia 2018)

8. Andrew Gerrard GoLand Talks 2014 (Google)

9. David Crawshaw - Organizing Go Code 2014 (Google)

PHP Serbia was a blast

Sasha Blagojevic — Tue, 28 May 2019 23:59:19 +0000

Originaly published at sasablagojevic.com

It's time we talked about the phelephant in the room. *Ba Dum Tss! Get it? This is double wordplay, elephant in the room and php + elephant == phelephant. Ok, I'm gonna stop now...

I wanted to summarise my impressions after the PHP Serbia 2019 conference since this was my first time attending. I thought it might be helpful to those people who are on the fence whether it's worth visiting it.

TL;DR

It is.

PHP Serbia 2019 line-up

The line-up and the topics covered were all really good. Zeev Suraski was this year's keynote and he gave us an overview of the PHP since he joined the band of brothers known as php internals devs and more importantly all the cool stuff that will be included in the upcoming php7.4 and php8. Yep guys, php8 will be coming hopefully by the end of 2020. Oh how the time flies by, I mean I haven't been in this game that long and I witnessed the amazing evolution from php5 to php8.

As I said, all the talks were good but the ones that stood out to me and I recommend you watch when the organizers share the videos are the following (in no particular order):

Hello my name is "if" by Sebastian Feldman, not only did he dance like a madman and put Michael Jackson to shame, but he also gave us a low-level insight and deeper understanding of how different types of if statements work under the hood in php, yes you might have thought that a ternary if statement is just a shorthand way of writing a regular if statement, but when it gets converted to opcodes it's actually not, and the same goes for using the null coalescing statement.

Git legit by Pauline Vos explained the difference between git rebase and git merge strategies in an easily digestible way, even by dummies like myself. Now we can finally put this feud to rest and just pick one that aligns with us philosophically because this is the same shit as OOP vs FP, one is not better than the other they both have their trade-offs. There is no silver bullet in software development no matter how strong we try to find it!

You're not a {framework} developer! - if you are a Symfony or Laravel fanboy you might strongly disagree with this one :D, but Thomas Dutrion gave a good starting point on how to abstract and protect ourselves from the framework. There were some really good examples for both Symfony and Laravel frameworks on how to abstract at both the Model and Controller level. Our domain logic shouldn't know about our infrastructure (framework), this is my key takeaway from this talk, at least that's how I understood it and it makes perfect sense to me now. For those of you who are saying But how often do we change a framework? we are not necessarily going to change the framework itself but we need to protect ourselves from future updates of our framework as well. Each major version will have breaking changes and choosing not to update will compromise both performance and security of our codebase - that's how we get legacy codebases that everybody hates working with.

Making architecture explicit by Herberto Graca, we all know that organizing code and folders can be a pain in the ass and a huge liability if done poorly. Well, Herberto had some great charts and breakdowns on organizing code the DDD way.

I highly suspect that Marcel Pociot's talk Getting started with WebSockets and Damien Seguy's Top 10 PHP coding traps were awesome as well but unfortunately, I did not attend them.

This is me winning a free ticket for PHPSerbia 2020 and a Phelephant on the conf quiz :D

Venue and organization

The venue is a big theater in Zemun, there were two tracks A and B, B being the smaller one obviously. Well, it was quite smaller compared to A, so what happened was that all the people that were interested in a talk at track B could not fit in or chose not to stand. This only happened two times though. Gauging the audience's interest and which speaker should get the short stick end is tricky, so maybe, as Damien Seguy suggested, attendees could vote somehow, when the lineup is known, which talks they're interested in so the organizers at least have some estimate.

There were food and beverages in abundance. I was well fed and watered like a plant xD. I must highlight that the food was really tasty and the Conferences' craft beer as well. What I also really liked compared to other conferences I attended (that being Webcamp Zagreb times two lol) they had a real espresso machine so I could get my daily 37 doses of macchiato, yes I'm an addict and I'm not ashamed. I basically didn't spend a dime the whole day throughout the conference there was really no need to.

In general, the organizers did a great job and they were very welcoming, you just felt at home from day one.

My only pet peeve is that maybe the talks could be a bit shorter so we have a small pause in between them to reset our brains, chit-chat, drink a coffee or whatevz or maybe I'm just spoiled by WebcampZg.

Final verdict

I give it a solid 9/10 just because I'm afraid if I gave them 10 they'll get lazy. Now is the time for you to stop thinking and start preparing for the next one!

P.S. Thanks to my company JSGuru for paying the ticket, I mean who doesn't like free stuff!

Originaly published at sasablagojevic.com

Improve Your Ionic App Performance

Boris Joskic — Thu, 07 Feb 2019 14:46:11 +0000

Ionic allows developers to build mobile applications using web technologies and allows access to native features such as file storage, camera, flashlight and many more. The first version was released in 2013 and built using Apache Cordova and AngularJS but recent versions, while still using Apache Cordova, are using Angular instead of AngularJS.

The most recent version of Ionic, version 4, includes performance improvements but in my opinion, it’s still having a tough time competing with the performance of native apps, or even React Native.

Make a production build

This might be an obvious one. While developing and testing, we usually build debug versions of the app. How many times have you build an apk and after installing you realized it’s a debug apk? I’ve done it... a couple of times.

The default build command will generate a debug apk which does not have optimized code.

ionic cordova build android --prod --release

command will do the trick. It will generate a production-ready apk with minified and optimized code.

Consider this first tip more like a reminder..

Add a Service Worker

Adding a Service Worker to an Ionic app has its benefits. One of them is that it can cache your static assets so your app can load faster. Not only can it cache your app’s static assets, but it can also cache some data from the API? That probably has some use.

Ionic has built-in support for service workers and adding it is pretty easy.

If you are interested, you can get more information in their documentation.

Native Page Transitions

By default, when switching to a different page, Ionic will use CSS animations to switch between views. This works fine mostly, but you may notice lags sometimes on devices with lower specs and also it’s not very customizable.

To solve this problem, you should switch to Native Page Transitions which uses native hardware device acceleration to animate transitions.

From my experience, performance is improved and the app feels much more native.

It’s supported on Android, iOS and Windows Mobile and you can start using it pretty quickly.

Regarding the customization, you can change the swipe direction, duration, delay in Android and iOS and more.

You can get more information in their documentation.

Use Virtual Scroll and Infinite Scroll

If you are working with a list, you are probably using the Ionic list component which is completely fine and will offer native UI depending on the platform.

However, if you have a large list you may notice some sluggishness. To get rid of that, you can start using Virtual Scroll and Infinite Scroll.

Infinite Scroll is just an Ionic component with the infinite scroll logic. It will call a certain action when user reaches the end of the list. It’s great for pagination as you can load a certain number of items, and when needed load more and append it to the original list. It also offers customization of the loading indicator where you can change the text and spinner.

Virtual scroll will take full list of the array, but only render items that are currently visible which can greatly improve performance. As the user scrolls, views are reused but are filled with different data depending of the row.

When should you use Virtual Scroll?

When you have a somewhat larger amount of data but do not need the Infinite scroll option(eg. all data is loaded in one API call), you can use it and it will greatly benefit you!

Conclusion

Great performance does not come by default in Hybrid apps no matter which starter kit you use. Before trying any performance optimization tricks, do not forget to optimize your own code, remove unused imports and CSS and optimize your images! Even the small stuff can make a difference.

Before you go…

If you enjoyed reading this post please share it. You should check out our other publications, you might like them too! We write from time to time about software development, tips and tricks, and how to become a better developer and business person in general. Join us on the journey of constant improvement!

Originally published at jsguru.io.

Why You Should Care What You Npm Install

Sasha Blagojevic — Thu, 20 Dec 2018 13:36:52 +0000

As if we haven't learned anything from the Left-pad debacle on November 26th the Javascript world was shaken once again.

A popular Npm library with over 2 million installs had a backdoor. Wait, what?! Yep, you heard it correctly the event-stream library which was not archived at that time and was used all over the place from your garage script kiddie to enterprise systems was infected with an obnoxious back-door, a crypto miner /stealer/something. From now on we will call it the C - virus for dramatic effect.

Damn crypto hype, it's high time the bubble burst and let us go on with our lives. - Me, December 2018

But, how did it happen? Well, a combination of unfortunate circumstances and the author's faith in people led us here where we are today.
The author stopped using and maintaining the library a long time ago. Since it wasn't archived over time it became a dependency of many projects and lo and behold one day a good Samaritan slid into his inbox and offered to take the burden of maintaining the library upon himself and to carry the torch onwards, but he was not good, was he now.

// Detect dark theme var iframe = document.getElementById('tweet-1067124100332744704-828'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1067124100332744704&theme=dark" }

The author transferred the rights of the Npm module to this kind stranger but left the module's code on his Github account since there were some problems with name conflict when he tried to transfer it to the stranger's account, or so he says, but I suppose they weren't accidental either. This Samaritan was one nefarious schemer.
As soon as he got hold of the library he removed the publishing rights of the old author, added the flatmap-stream module which contained the C-virus, did a minor version bump and finally a new release on Npm.
The event-stream library was updated to the new minor version all over the world.
As soon as he planted the C-virus, he removed the flatmap-stream module from the library and then he did a major version bump and once again a new release on Npm. Quite smart isn't it? Now there was nothing suspicious in the codebase but since it was a major version update most of the systems wouldn't update to it because they are version locked to the previous major version thus they would still have the infected code.
Even one of my coworkers got infected, barely anyone noticed, but Kevin Beaumont.

// Detect dark theme var iframe = document.getElementById('tweet-1067125660014051330-270'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1067125660014051330&theme=dark" }

That was a brief summary and I probably missed a step or two but you get the picture.

SHORT NOTICE:
We shouldn't blame the author, he probably didn't really think it through that much but maintaining open source software is a real hassle and can be really mentally draining on the authors, especially in today's entitled society where people expect everything for nothing. So let's not put the blame on him.

Now let's get back on track! Oh, here's another gem by Kevin Beaumont

// Detect dark theme var iframe = document.getElementById('tweet-1067130326395351040-919'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1067130326395351040&theme=dark" }

Hallelujah, praise the Lord! Preach! People didn't come up with this meme for no reason:

Key takeaways from this mess:

Sometimes we take for granted and don't think what we Npm install/composer require/yarn add
Developers have become lazy. We have started taking "don't reinvent the wheel too literally", instead of writing a few extra lines we'd rather require a library, sometimes even for the most trivial of tasks (especially in the Javascript World this seems to be the trend)
You should always put careful thought in what you require as a dependency, more dependencies can sometimes mean more technical debt
Add a layer of abstraction and design an interface as a bridge/adapter between your domain logic and libraries, so you can swap them more easily if the need arises
When a library stops being maintained we now own that code and it is our responsibility to fix it as part of our codebase or find a suitable replacement for it

These lessons were once again learned the hard way by many businesses this November.

Thanks for reading my long rant!

Before you go…

If you enjoyed reading this post please share it. You should check out our other publications, you might like them too! We write from time to time about software development, tips and tricks, and how to become a better developer and business person in general. Join us on the journey of constant improvement!

Originally published at jsguru.io.

SEO Guide for Websites

Sasha Blagojevic — Mon, 01 Oct 2018 13:46:01 +0000

This guide will cover a very important topic for every digital business, search engine optimization. SEO can sometimes appear as a black box, there is a lot of magic behind it and it's constantly changing and evolving. In this article, we will try to dispell it by leading you through some of the SEO best practices.

Besides the latest Google algorithm updates, working on our company’s website SEO and trying to battle through the avalanche of information is what prompted me to write this guide, if nothing as a reference for future self.

This is by no means a comprehensive guide, I will go over the SEO fundamentals you need to cover if you want a shot at appearing on the Google's first page and we all know how it is in practice, if you are not on the first page, it's as if you don't exist, let's be honest, how often do you go to the second or the third page? Yeah, thought so…

If you are interested in the history of the Google's algorithm and how it changed over the time the guys and gals at Moz have organized it in a nice searchable list.

Let's start from the beginning, what is a search engine?

You know how your website has different pages, and it has a navigation bar that links to every one of them? Well, you can look at Google, or any other search engine for that matter, as the internet's navigation menu. Google "collects" all the websites from the world and indexes them. But how does he collect them?

Well, there are three ways how Google can discover your website:

From DNS registries - if you're not familiar with the term DNS, I recommend you read this article. While we're at it, did you know that Google itself is a DNS registrar although they do not sell domains?
If other websites link to your, Google will follow those links and discover you (unless there is a rel="nofollow" attribute on them). Those links are called inbound links and they are one of the major factors that determine your SEO ranking.
By adding your website and sitemap to the Google Search Console you are basically telling Google "Hi my name is so and so, and this is my address, here you can see my living room, and that is my kitchen, oh I almost forgot about the porch…" ;).

1. Google Search Console

This should be your first step on your path to SEO glory. Go to the Google Search Console, add your website and go through the verification process, and now you are at your first crossroads. You have two options:

You can either add both of your website versions, a non-www and www version (e.g. https://jsguru.io and https://www.jsguru.io) and choose a preferred one. In our case, we set the preferred one to be the non-www.
Or you can add only one version to the Google Search Console, whichever you prefer, and configure your server to redirect from the other version to your preferred one (e.g. add only https://jsguru.io to Google Search Console, and redirect from https://www.jsguru.io to https://jsguru.io). It must be a permanent redirect so your HTTP Response Code should be 301.

Either way, you must handle both of the domain variants, if you just leave them in the wild, without handling them as previously described, there is a high probability Google will treat them as duplicate content, and duplicate content is penalized.

On the other hand, it would be really bad user experience and detrimental to your brand if you served only one domain variant and your website errored out on the other one.

2. Sitemaps

Sitemaps are, as the name already says, a map of all your website pages represented in a format Google or any other search engine can easily digest. It is a collection of all your links, usually in an XML document, but it can also be in a different format such as HTML for example. Look at them as a skeleton of your website.
There are a lot of free online tools that can generate them for you. After you've done that you should submit it to Google Search Console under the Sitemaps section. This will allow Google to index you more easily, but still, be patient, it can take time.

If you have a publishing website like a news magazine or a blog, it would be best if you could find a way to automatically update them to reflect the changes on your website.

Since you can submit as many different sitemaps to Google Search Console as you want, a good approach would be to have at least two sitemaps, one for the "static" part of your website that doesn't change that often and another one for the "dynamic" part of your website which is updated frequently, like the blog section for example.

In our case we have two sitemaps, one that covers our main navigation and contains links to the pages like Home, About Us, What We Do and so on, and another one for our blog where we publish articles every two weeks.

3. HTTPS vs HTTP

From July 2018 Google Chrome has started to mark websites without HTTPS as non-secure, which could negatively impact your traffic, users might decide to leave your website because they perceive it as insecure, or they might get worried that it's some kind of a scam, in addition, HTTPS websites are reported to have a slight ranking advantage over HTTP websites.

In the early days of internet getting an SSL certificate and securing your website with HTTPS was a tedious and expensive process, but thanks to the open source community and Let's Encrypt Foundation it is now both free and easy to set up.
Follow these links for a detailed tutorial on how to add HTTPS to your website:

4. Meta tags

Yes, meta tags are still a thing!
The description meta tag allows you to customize the brief description which will be shown in the search results, otherwise, you're leaving it up to Google to determine what's important and what will be shown, which can lead to some nasty and completely unrelated descriptions. Traditionally, the description length was capped at 155 characters, but recently Google started to allow more, so to play it safe your description should be between 50 and 300 characters.

Although the keywords meta tag has been obsolete for some time, I still included it, because the SEO tool I use bugged me that it was missing and since I'm a bit OCD I just had to add it.

The og, not to be confused with original gangsta, meta tags are used by Facebook, LinkedIn, and other social media to determine what content will be shown when someone shares your page. Same goes for the twitter meta tags.

<meta name="description" content="JSGuru is a high-quality software development shop where clients come first. We build your desired products and provide excellent, long-term customer support so that you can focus on the core of your business.">

<meta name="keywords" content="software development, web development, mobile development">

<!-- Facebook-->
<meta property="og:url"                content="https://jsguru.io">
<meta property="og:type"               content="website">
<meta property="og:title"              content="JSGuru">
<meta property="og:description"        content="JSGuru is a high-quality software development shop where clients come first. We build your desired products and provide excellent, long-term customer support so that you can focus on the core of your business.">
<meta property="og:image"
      content="https://jsguru.io/img/jsguru.png" />

<!-- Twitter -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@jsguru_software">
<meta name="twitter:creator" content="@jsguru_software">
<meta name="twitter:title" content="JSGuru">
<meta name="twitter:description" content="JSGuru is a high-quality software development shop where clients come first. We build your desired products and provide excellent, long-term customer support so that you can focus on the core of your business.">
<meta name="twitter:image"
      content="https://jsguru.io/img/jsguru.png">

5. Canonical Links

What are canonical links? For all of you who are not familiar with the term, canonical links are HTML tags that you put in the HEAD of your document and their purpose is to point to the original source of the content.
Canonical links can point to a different page/ link from the current page you are on, or they can be self referencing, meaning they can point to the same page you are currently on.

When Google comes across a canonical link that points to a different page it says to him "Hey don't index this page, the actual source you should index is there.".

If the canonical link is self-referencing, that signals to Google "Ok this is the definite root of the content". If Google were to come across the same content again on a different website he would definitely know that your content is actually the original.

<head>
    <title>JSGuru - What We Do</title>
    <link rel="canonical" href="https://jsguru.io/what-we-do">
</head>
<body>
 ...
</body>

Do you remember how I mentioned earlier that we should handle both the non-www and www version of our domain? Well, be careful not to mix them in your canonical links, choose one preferred version and stick with it!

6. Localization - hreflangs

What if you have a multilingual site and you want different language versions served depending on the country of the visitor? How to go about that?

A common, but a discouraged approach is to geolocate the user by his IP address. This is usually done by storing the IP tables in your database and comparing them with the user's or using a third party service like Ipinfo.
After determining the user's location you would store it in a cookie and serve the appropriate language.

This seems like a sensible approach, doesn't it? But why is it discouraged?

Well, firstly the geolocation by IP is not that precise, especially nowadays when people value their online privacy and are using VPN's more and more, additionally, some internet providers themselves use proxies when giving out dynamic IPs.

Secondly what if the user is a German but he is in England on a business trip? He would get the English version and we don't want that.

Thirdly you are taking away the possibility to manually choose the language version from the user.

Last but not the least, you are preventing Google from properly indexing all your website versions because their crawling servers are mainly in the US.

Now that we went over what not do, let's go over what you should do!

First and foremost, the pages your hreflang links are pointing to should have the same content just in a different language, they should never have a completely different content, that is a NO NO.

When it comes to actual linking, you have two options:

a) Add hreflang link in the head of the HTML document

<!-- English (default) language page -->
<head>
    <title>JSGuru - What We Do</title>
    <link rel="canonical" href="https://jsguru.io/what-we-do">
    <link rel="alternate" 
          hreflang="x-default"  
          href="https://jsguru.io/what-we-do" />
    <link rel="alternate" 
          hreflang="en" 
          href="https://jsguru.io/what-we-do" />

    <link rel="alternate" 
          hreflang="de" 
          href="https://jsguru.io/de/was-wir-tun" />
    <link rel="alternate" 
          hreflang="de-ch" 
          href="https://jsguru.io/de/was-wir-tun" />
    <link rel="alternate" 
          hreflang="de-at" 
          href="https://jsguru.io/de/was-wir-tun" />
</head>
<body>
 ...
</body>

It is important that you add the hreflang links on all pages not just your default language page.

<!-- German Language Page -->
<head>
    <title>JSGuru - Was Wir Tun</title>
    <link rel="alternate" 
          hreflang="x-default"  
          href="https://jsguru.io/what-we-do" />
    <link rel="alternate" 
          hreflang="en" 
          href="https://jsguru.io/what-we-do" />

    <link rel="alternate" 
          hreflang="de" 
          href="https://jsguru.io/de/was-wir-tun" />
    <link rel="alternate" 
          hreflang="de-ch" 
          href="https://jsguru.io/de/was-wir-tun" />
    <link rel="alternate" 
          hreflang="de-at" 
          href="https://jsguru.io/de/was-wir-tun" />
</head>
<body>
 ...
</body>

Be careful not to combine hreflang tags with canonical links which point to different pages, as well. Hreflang tags can only be combined with self-referencing canonical links.

In our code example, we included the canonical link only in our English (default) language page, that's because that is the original source of our content, the German page shouldn't include the canonical link because it's the same content just in a different language, if we were to include it we would just confuse the Google crawler.

b) Add hreflang link to the sitemap

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://jsguru.io/what-we-do</loc>
    <xhtml:link rel="alternate" 
                hreflang="x-default" 
                href="https://jsguru.io/what-we-do" />
    <xhtml:link rel="alternate"
                hreflang="de"
                href="https://jsguru.io/de/was-wir-tun"/>
    <xhtml:link rel="alternate"
                hreflang="en"
                href="https://jsguru.io/what-we-do"/>
    <lastmod>2018-08-28T09:24:19+00:00</lastmod>
    <priority>1.00</priority>
  </url>
</urlset>

IMPORTANT - you should always provide the full link including the protocol (also known as an absolute link) to the canonical or hreflang link tags!

You can read more in-depth about localization, hreflang tags and an additional approach to localization I didn't cover here.
Here are some tools which can be helpful:

7. Images and Videos

When it comes to images you should always add the alt attribute which contains the textual description of the image. The benefits of adding alt attributes are twofold, firstly it will make your website more accessible, the visually impaired people will get the description of the image, and secondly Google will be able to understand the context of your images which will, as a result, increase your visibility in the search results both on the general search and image search.

Same goes for the videos as well. No matter whether you are adding them directly on your website or on platforms like Youtube/Vimeo you should always provide transcripts. Google can't process images and videos, the only way search engines can discern their content is by textual descriptions.

8. Google Structured Data

If you ever thought about SEO being a black box, wait 'till you start with Google Structured Data, that is a black Pandora's box. There's no closing this lid when you open it.

This is such a vast topic that it deserves a whole new blog post in itself, but I'll try to cover the basics here and provide you with some helpful links.

Google Structured Data is an implementation of the Schema.org standard for rich data. Google uses this data to fill it's Knowledge Graph, and show you rich search results a.k.a. Google Rich Cards.

What's more, you can do everything right and your structured data might still not appear in the search results.

Using structured data enables a feature to be present, it does not guarantee that it will be present.
The Google algorithm tailors search results to create what it thinks is the best search experience for a user, depending on many variables, including search history, location, and device type.
In some cases, it may determine that one feature is more appropriate than another, or even that a plain blue link is best. - per Google's Policy

You can provide the structured data in three formats, but Google recommends JSON-LD so we will concentrate on that format. Here is an example of how it looks:

<script type="application/ld+json">
    {
         "@context": "http://schema.org",
         "@type":"LocalBusiness",
         "address": {
             "@type": "PostalAddress",
             "addressLocality": "Manhattan",
             "addressRegion":  "NY",
             "postalCode":"10036",
             "streetAddress": "400 Broadway"
         },
         "description": "This is your business description.",
         "name": "Craig's Car Repair",
         "telephone": "555-111-2345",
         "openingHours": "Mo,Tu,We,Th,Fr 09:00-17:00",
         "geo": {
             "@type": "GeoCoordinates",
             "latitude": "20.75",
             "longitude": "13.98"},
             "sameAs" : [
                 "http://www.facebook.com/example",
                 "http://www.twitter.com/example",
                 "http://plus.google.com/example"
             ]
    }
</script>

Here we have an example of LocalBusiness entity which is a subset of Organization entity. You should always try to be as specific as possible with structured data and use the most narrow definition of the entity as in this example. Additionally, you should always try to provide all possible attributes.

You can find example snippets that have been tried and tested by the community on this link, just replace the values with your own.

I also recommend Merkle structured data generation tool for starters, and later when you get a better understanding of how everything works you can expand on the generated data with additional properties.

Another option is to use Data Highlighter, it is a tool within Google Search Console under Search Appearance section, but it is currently only visible in the old view! Google is currently rolling out a new Search Console so I'm not sure about the future of this tool, it is to be determined.

Where should you put your structured data?

Structured data should go in the head of the HTML document.

<head>
    <script type="application/ld+json">{...}</script>
</head>

There is one general rule of thumb that you should adhere to, all the data that you've put in the script tag should be actually visible on that page. For more info, you should consult the Google Guidelines.

Here are some links that could be helpful, as well:

Intro to structured cards
Guides
Rich Cards Search Results Testing Tool (currently in beta and limited to following entities: Job posting, Recipe, Course, TV and Movie, Event)
Google Structured Data Validation Tool
Google's Simple Tutorial on How to Add Rich Cards

9. Google Local Business

Google Business, among other things, is essentially a more user-friendly way of adding LocalBusiness structured data, and you should definitely do it!

If your business has multiple locations you should add all of them. It is best to combine this method and adding structured data manually because if Google's Knowledge Graph is populated with your social media pages and B2B platforms like Clutch it will automatically link them to your business and your reviews will be shown in the rich results.

There's nothing much to add here, let's move on!

10. Blog

Blog is still the Holy Grail of SEO and Digital Marketing. Despite the over-saturation with articles on many topics, this is still the best organic way to build links and increase traffic to your website.

You should try to publish regularly, but you shouldn't sacrifice quality over quantity, Google's algorithms have shifted more towards quality vs. quantity in recent years. Not only do they look for quality in the content but the quality of the links that lead to it as well.

When it comes to the blog the only dilemma you can have is whether to host it on a subdomain e.g. blog.jsguru.io or a subfolder jsguru.io/blog.
Well, actually it's not a dilemma, you should host it in a subfolder because subdomains are treated as different domains by Google so they will need to build their own reputation independently of your main domain. There is no value added to you with this approach.

When it comes down to the implementation of the blog you should still, at least partially stick to the old-school server-side rendered approach because Google indexing is two-pass, the second pass is for JS only websites which is a week after the initial pass, especially if your business model is centred around publishing. This has been confirmed by a Paul Kinlan on Twitter:

Paul Kinlan

@paul_kinlan

@HenrikJoreteg Indexing is delayed for pure client side sides. Google indexer is two-pass, first run is without js, then week later it's with is (or there abouts)

12:26 PM - 12 Sep 2018

11. Google Page Insights

Performance is one of the major factors of your ranking. The lower the load time of your website the higher your ranking will be, especially when it comes to mobile devices.

One great tool you can leverage when it comes to performance tweaking is Google Page Insights.

Some basic and common ways of improving your website performance are:

Minify your javascript and css files.
When adding jpg/jpeg images compress them to 80% of the quality, the difference will not be visible in the web environment but their size will significantly decrease.
If possible use a cookieless (stateless) domain to serve your static assets like images. Serving different images for different screen sizes. There is no need to load a 1920x1080px image on a 320px wide screen.
Lazy loading images - loading images only when they enter the viewport of the device.
Gzip compression and browser caching (images, javascript, css). Here's a nice tutorial for improving your page insight rank for ngnix servers. If you're using apache you should look up mod_deflate and mod_expires extensions.
Use script defer and async.

12. Mobile Responsive and Mobile First Indexing

More and more internet users are coming from mobile devices, actually, they have surpassed the desktop users in general, and according to this trend, Google has shifted its focus on mobile devices several years ago. If you remember Google used to show a tag mobile-friendly in its search results.

Nowadays there is no need for it, and having a mobile-friendly website that offers a pleasant experience on all screen sizes is a no-brainer. In order to offer a better mobile UX, some people have sacrificed the content in the mobile versions of their websites.

With the latest changes to Google Algorithm, now they might pay the price for it. Google has started mobile first indexing, but what does that mean?

Previously Google would crawl the desktop version of the website for indexing, from now on, the mobile version will be used for indexing. So if you left out content to fit everything nicely in the smaller screens, your SEO might suffer.

13. Summary

If you've come this far I congratulate you, it has been exhausting for me to write all of this, I can only imagine how it is to read it! Yes, you deserve to pat yourself on the shoulder.
If I wanted you to take anything from this article it would be the following.

The three most important factors for good SEO are:

quality content,
quality traffic and
quality links.

As with everything in life quality trumps quantity, long gone are the days where you could just pay for links on some obscure websites or churn out shallow articles that barely touch the topic they are supposed to cover.
And lastly, have patience, these things take time, Google has no infinite amount of resources, and indexing new websites is not really on the top of their priority list, so it might take a few weeks or even months, to start having some real results.

OMG! I almost forgot I highly recommend you watch this Q&A with Riva from Digital4Startups we had the privilege of hosting her in our offices. The video quality su*ks but the audio is the important part anyway!

Before you go…

Leaving the Old Ways - jQuery vs React

Sasha Blagojevic — Thu, 16 Aug 2018 15:21:30 +0000

Contrary to popular belief, React’s biggest use cases are not SPAs, it’s the hybrid apps that are most common, and the best fit in my opinion, in this post I will cover how and why I went from a React hater to a React fanboy, and why React is a perfect replacement for jQuery.

I used to have some kind of an inner resistance when React and Vue first started to gain traction and were becoming the de facto standard for building modern UIs.

Yes, I’m purposefully leaving Angular out, even though AngularJS was the pioneer of the front end revolution that brought us web 2.0.

Angular is philosophically on the completely opposite side of the spectrum, it’s a full-blown SPA framework, whereas React is just a view library, and I’m still not convinced SPAs are the right way and personally I prefer the hybrid approach.

For all of you that are thinking right now - “And what about Vue?” , Vue would be somewhere in between these two extremes.

Contrary to popular belief, React’s biggest use cases are not SPAs, it’s the hybrid apps that are most common, and the best fit in my opinion. Don’t believe me? Well look what Facebook’s Dan Abramov had to say:

It’s interesting that React became associated so much with SPAs but Facebook isn’t using it for SPAs (except for the Instagram website and some internal tools) - @dan_abramov

One of my major pet peeves was Webpack and all the tooling they brought with themselves.

I held a strong opinion that they were introducing unnecessary complexity to the front end, yes they made us developers feel like rocket scientists with the amount of tweaking we had to do and the number of levers and gears we had to pull and turn to make them run, but at the end of the day, did they really add value to the business?

Did they improve the product and the user experience to warrant a higher maintenance and development cost and a higher barrier of entry for new bloods, when we could have done the same with plain ole jQuery, or even better, vanilla JS?

After I found out React introduced react-cli I decided to give it another go, and boy oh boy was I pleasantly surprised.

With the introduction of react-cli (and vue-cli) all that nitty-gritty tooling and those build steps that were equivalent of getting a PhD in Computer Science were out of the way for 80–90% of use cases, although you still had to roll up your sleeves and mess around with webpack for some edge cases.

Sure if you’re building something fairly simple, may it be a contact form with an Ajax submit or something entirely different but that is simple enough, vanilla JS is, in my opinion, a sound approach, there is no need to roll out the big guns. You can even go with jQuery, but there is really no need for it in today’s world, but that’s a completely different topic.

Keep it simple - this should always be your mantra.

In that case, if you were to use a framework, 90% of your code would be the frameworks infrastructure and the rest would be your actual logic. That is a major overkill, you are introducing unnecessary boilerplate and increasing your bundle size which directly impacts performance. Bigger bundle means a lot more bytes have to be sent over the INTERNETZ, so you’re actually costing your business, just because you wanted to use that shiny new thing.

Oh, you think those milliseconds don’t matter much? Well they can quickly add up, especially on high traffic sites, just because today’s machines are powerful doesn’t mean we should be reckless and throw anything at them, we need to be conservative with our resources.

Look at it like this, it’s as if you are building a foundation for a ten story building only to put a tent on it.

React, versus the old way, really comes to shine when you are building complex UIs.

With React the simplicity of development increases with the complexity of the UI you are building, or in other words, the cost of development is inversely proportional to the complexity in comparison with the vanilla JS/jQuery approach.

Here’s a little graph for all you visual types.

Talk is cheap, let’s get our hands dirty with an example from the real world.

We have an invoice form, aside from the general data like the date of the invoice, the due date of the invoice, subject etc., the user needs to be able to add/remove invoice items.

Invoice items, on the other hand, have the following:

name and/or the description of the product/service you’re invoicing,
it's quantity,
price,
any discount you may give,
any penalty interest that incurred,
then we might have VAT tax or sales tax depending on your country’s laws

and finally, all the calculations that go with the aforementioned.

You see now how a seemingly simple thing can get complicated quickly?

With the old approach, you would have to have a lot of things on your mind, you would need to:

Add change event handlers on all the different input fields, and some of them would additionally need to cancel each other out so you would need to track when to detach them.
Every time an invoice item is added or removed you would need to manipulate the DOM, by either adding or removing child nodes or writing HTML as a string.

No matter the choice, you’d need to concatenate some HTML and fill it with variables, which can get unruly pretty fast. ECMA 6 string literals do ease this a bit, but still, it can get cumbersome.

Imagine a designer changes something, on how many places would you need to changes all those bits that you’re glueing together in your vanilla JS code?

Another thing you would need to keep in your mind is that if you manipulate DOM as a string you’re killing all the event handlers on those particular DOM elements. Yep, another gotcha moment.
Calculations - every time an invoice item is added or removed you need to calculate its particular values and in addition update the invoice’s subtotal, tax, total, etc. Essentially you would be creating your own state store.

I probably might have missed a thing or two that would pop up while trying to handle this use case the old way, as it usually is, everything sounds simpler on paper until you start to implement it and a whole new spectrum of cases that need to be handled appears.

Using React requires a slight shift in your mindset, in a nutshell, you only need to be concerned with one thing, the state. This simplifies the logic immensely, you are only concerned about your state, that is the only thing you need to manipulate, and your invoice input fields and invoice items will be re-rendered according to the changes in your state.

Let’s take a look at our simplified code example, this might give you a clearer picture.

import React from "react";
import ReactDOM from "react-dom";
import PropTypes from "prop-types";

class InvoiceItemForm extends React.Component {

  constructor(props) {
      super(props)

      this.state = {
          itemInput: {
              description: '',
              quantity: 0,
              price: 0,
              subtotal: 0,
              taxRate: 0.17,
              tax: 0,
              total: 0
          },
          invoiceItems: []
      }

      this.handleInputChange = this.handleInputChange.bind(this);
      this.addItem = this.addItem.bind(this);
      this.removeItem = this.removeItem.bind(this);
  }

  handleInputChange(e) {
      let input = (e.target || e.currentTarget);
          input.subtotal = input.price * input.quantity;
          input.tax = input.subtotal * input.taxRate;
          input.total = input.subtotal * (1 + input.taxRate);

      this.setState((state) => { return state.itemInput[input.name] = input.value; });
  }

  addItem() {
      let state = this.state;
          state.items.push(state.itemInput);

          // Clear the last input
          for (let key in state.itemInput) {
              switch (key) {
                  case 'description'
                      state.itemInput[key] = '';
                      break;
                  case 'taxRate':
                      state.itemInput[key] = 0.17;
                      break;
                  default:
                      state.itemInput[key] = 0;
                      break;
              }
          }

      this.setState({itemInput: state.itemInput, items: state.items});
  }

  removeItem(e) {
      let rowIndex = (e.target || e.currentTarget).parentNode.parentNode.rowIndex;

      let items = this.state.items.filter((item, i) => { return i !== rowIndex; });

      this.setState({items : items});
  }

  renderCells(item, rowIndex) {
      let cells = [<td>{rowIndex + 1}</td>];

      let i = 1;
      for (let key in item) {
          cells.push(<td key={i}>{item[key]}</td>);
          i++;
      }

      cells.push(
          <td>
              <button onClick={this.removeItem}>
                  {'Remove Item'}
              </button>
          </td>
      );

      return cells;
  }

  render () {
    return (
        <React.Fragment>
            <div>
                <input
                    name={'description'}
                    value={this.state.itemInput.description}
                    onChange={this.handleInputChange} />
                <input
                    name={'price'}
                    value={this.state.itemInput.price}
                    onChange={this.handleInputChange}>
                <input
                    name={'quantity'}
                    value={this.state.itemInput.quantity}
                    onChange={this.handleInputChange}>
                <input
                    name={'taxRate'}
                    value={this.state.itemInput.taxRate}
                    onChange={this.handleInputChange}>
                <input
                    name={'subtotal'}
                    disabled={true}
                    value={this.state.itemInput.subtotal}
                    onChange={this.handleInputChange}>
                <input
                    name={'tax'}
                    disabled={true}
                    value={this.state.itemInput.tax}
                    onChange={this.handleInputChange}>
                <input
                    name={'total'}
                    disabled={true}
                    value={this.state.itemInput.total}
                    onChange={this.handleInputChange}>
            </div>
            <table>
                <thead>
                    <tr>
                        <th>Item no.</th>
                        <th>Description</th>
                        <th>Price</th>
                        <th>Quantity</th>
                        <th>Tax Rate</th>
                        <th>Subtotal</th>
                        <th>Tax</th>
                        <th>Total</th>
                        <th></th>
                    </tr>
                </thead>
                <tbody>
                    {
                        this.state.items.map((item, i) => {
                            return (
                                <tr key={i}>
                                    {this.renderCells(item, i)}
                                </tr>
                            );
                        })
                    }
                </tbody>
            </table>
        </React.Fragment>
    );
  }
}
export default InvoiceItemForm

Vuoala, that’s it!

Hey, do you have a jQuery app you would like to migrate or are you just trying to figure out which framework would be best for your next million dollar idea? Contact us at info@jsguru.io, and let that be our headache.

Before you go…

Originally published at jsguru.io.

Do's and Don'ts for Javascript Newbies

JelenaKalaba — Fri, 27 Jul 2018 13:00:07 +0000

Since the day Brendan Eich created it, JS has had many makeovers, changes, additions, and frameworks added to its body. After a lifetime of turbulence, JS has been shaped into how we see it now in 2018, and yet there is much more growth awaiting in its future.

Today, I think the current state of JavaScript is best described by Atwood’s quote: “Any application that can be written in JavaScript will eventually be written in JavaScript.” Virtually anything you imagine can be written in JavaScript.

In this post, we will give you some tips on what to do, and what not to do, for both JS newbies and for those who have had some previous experience in this language.

There are some common rules of thumb when it comes to writing JavaScript code that should always be on your mind. Such rules relate to variable declarations, naming conventions, code commenting, striving to write cleaner code and keeping up with the JavaScript world in general. Let’s tackle some of these.

VARIABLES

When it comes to naming variables, using the camelCase rule is generally considered to be the best practice. That’s how we at JSGuru name them and it helps when the whole team uses this rule as it helps keep the code uniform.

It is also important to keep variable names short, concise, and descriptive. This should be adhered to as much as possible due to the fact that code is shared most of the time. The reader should be able to figure out what is stored in that variable or what it refers to without logging it in the console and backtracking your code. A good variable name should tell the reader about the context it is being used in within a chunk of code, and not refer to its value or purpose it is being used for from the user’s point of view. For example, “userAnswer” is a better variable name than “userInput”, as it clearly refers to, from a coding standpoint to a question asked earlier. You know exactly what input it refers to. Along the same lines, avoid using generic names such as “num” and “arr”, without at least appending it with information related to what it refers to, i.e. “selectedColors”. Along the same lines, “wantsSubscriptions” or “shouldRemember” is better than “trueOrFalse”. Use verbs and plural/singular to help indicate the value, instead of some acronym related to the type of value inside of a name.

Making the code cleaner and easier to read is considered a good practice. You can do this by placing the declaration of the variables at the beginning of your script, adding var or let in front of the first variable in the list, and only the first one. A comma can divide the rest, and to seal the deal place a semi-colon at the end of this declaration. Initialize variables first-hand when you declare them so that we avoid undefined values, and then do everything else.

LET OR CONST INSTEAD OF VAR

Since the adoption of ES6 (also known as the ECMAScript 2015) standard, variables should be declared using the keywords let and const. The reason behind abandoning the var keyword is that it should provide clearer meaning regarding the purpose of the variable and the context in which it is used. Const should generally hold references to values that will not be changed over time, even though, in cases of objects and arrays, it is allowed to mutate them. On the other hand, the keyword let indicates that a value might be changed or that a different value will be assigned to the particular variable. If you try to change the value of a const, JavaScript will tell you about it and help you avoid bugs. A good use case for const is storing a reference to a DOM element which you always want to keep in that variable. Keyword let is meant to be used with loops or mathematical algorithms, generally when its value is expected to vary. Variables declared with let and const aren’t hoisted, like those declared with var.

COMMENTS

Have you ever found yourself in a situation where you looked at your old code only to see there are no comments related to it? Maybe you forgot to write them at the time or you accidentally postponed writing them and wound up forgetting to do so later. Whatever the case may be, now you’re in a situation where you’re looking at a bunch of hieroglyphs and start feeling overwhelmed because you don’t know where to start reading and understanding it. Writing clean code and adhering to good naming conventions can surely help, but a more complex chunk of code sometimes just simply needs one or two comments to help the reader understand it quicker. I remember returning to my code on multiple occasions and spending a good amount of time figuring out what I wrote and how exactly I went about it. This is when I learned the importance of writing some logic inside comments, just to serve as notes and help me understand it quicker in the future. You will, almost undoubtedly, find yourself in a situation where you are trying to understand the code you or someone else wrote and wishing there were some comments around it just to speed up the process of catching up.

Use this experience as a motivation to help you understand the importance of writing comments and keep it in mind next time you write some complex logic. Just write a short sentence capturing the essence of that chunk and trust me, you’ll thank yourself in the future. More importantly, whoever reads your code will be grateful as well. As a side note, it doesn’t hurt to make your comments humorous and positive since negativity and arrogance are counterproductive.

FORMATTING CODE

Formatting code can be tricky sometimes. To help you with this you should try out code linters like ESLint or JSLint (links to official site ). Both of these tools will help you have cleaner and better code in line with community standards. The least you can do is use whitespace and newlines to group your code into related chunks. This will make your code that much more readable and you will be able to make sense of it a lot quicker!

EFFICIENCY

In this section, we will remind you of the importance of general efficiency in programming. These are some common newbie pitfalls when it comes to Javascript.

1. Fetching DOM elements

If I got a dollar every time I saw document.getElementById scattered all around the code, I'd be a millionaire by now. If the DOM elements haven't actually changed, just store it in a variable an use it later down the road.

    let container = document.getElementById("someElementId"); 
        container.innerHTML = "<h1>Hello World!</h1>";
        container.addEventListener('mouseover', function(e) {
            this.innerHTML = "<h1>Hello Again!</h1>";
        })

This is especially common with jQuery, we've all seen code like this:

    $('#button').addClass('actioned');
    $('#button').hover(function () { ... });
    $('#button').click(function () { ... });

Instead of:

let button = $('#button');
    button.addClass('actioned');
    button.hover(function () { ... });
    button.click(function () { ... });

What you should also keep on your mind is that fetching a DOM element by Id is the fastest method, so you should use it over other methods like document.getElementsByClassName, document.getElementsByTagName document.querySelector, etc. whenever you can.

2. DOM manipulation in the loop

This is an example of what not to do. Here we fetch a DOM element from within our loop. That means that we unnecessarily fetch it on every iteration and then subsequently we fill its inner HTML on every iteration as well.

function processArray(myArray) {
    for (let i = 0; i < myArray.length; i++){
      let div = document.getElementById("container");
      div.innerHTML = div.innerHTML + myArray[i];
      if (i < myArray.length - 1) {
        div.innerHTML = div.innerHTML + ", ";
      }
    }
  }

The first thing we can do to optimize this code is to move the fetch statement above the loop. By doing this, we will not change the logic of this code block but give the code a significant velocity boost, while also decreasing the memory usage at the same time. To avoid the constant updating of the DOM with every iteration, as this is quite time-consuming, it would be a good idea to move the innerHTML out of the loop, as well.

    let container = document.getElementById("someElementId"); 
        container.innerHTML = "<h1>Hello World!</h1>";
        container.addEventListener('mouseover', function(e) {
            this.innerHTML = "<h1>Hello Again!</h1>";
        })

These examples help us keep two things in mind when we talk about the code's efficiency. Firstly, to declare variables outside the loop and secondly to reduce DOM operations and make sure to use them intelligently.

In addition, it's important to remember to use let more then var when you're creating new variables.

However, global variables defined with let will not be added as properties on the global window object like those defined with var.

STRICT MODE

We are encouraged to use ''Strict Mode'' when our goal is to create more robust JavaScript code. Strict Mode changes (previously accepted) ''bad syntax'' into real errors. It means that trying to add values to the properties of a mistyped variable, which would create a new global variable in the regular mode, will now give you an error. In Strict Mode, any assignment with a non-writable property, a getter-only property, a non-existing property, a non-existing variable, or a non-existing object, will throw an error.

Staying up to date with the newest JavaScript standards is perhaps the most important thing on this list.

Firstly, your code will be modern and most likely written close to what industry standards are at the time. In addition by using the newest features, you and all other developers are encouraging and creating a need for browsers to implement those features and start supporting them out of the box. Right now, this is done with the help of transpilation tools such as Babel. If you’re not familiar with Babel, simply put, it “translates” newest JavaScript code into the format which browsers of today can understand. Babel reads your JavaScript code and compiles the newest features you used down to ES5, which all browsers can understand. Some browsers support ES6 features already, but using Babel and similar tools is still necessary because we want our JavaScript to be supported by all browsers and older versions as well.

For further information regarding Babel, I recommend you visit their website they have a great documentation which will get you started quickly.

What's more, you will make your life easier! Newest JavaScript features are amazing and they get better and better with each specification. They are an improvement to the old ways of doing things, i.e. using Promises or Async/Await to avoid being in a callback pyramid of doom.

Learning new things means leaving your comfort zone, but trust me, once you pick them up, you’ll never look back. Couple of features I’d recommend looking into are Array methods (map, reduce, filter), async/await, and of course, my favorite - String Literals.

It’s important to remember, you can always improve your coding skills and write cleaner code. It’s a marathon, not a sprint, so don’t feel overwhelmed if your code is not as clean as it can be. The most important thing is that it works! Over time, as you become more experienced and start adhering to industry standards, you will start writing cleaner code, and even then, there will be tons of room for improvement, just like there always is with everything! So don’t get discouraged, it just takes time.

I hope that you found this article helpful guide. Until next time, Jelena, signing out...

Why Your Business Needs a Progressive Web App

Bojan Gvozderac — Thu, 28 Jun 2018 14:39:48 +0000

You ever look at a web site and think: "Everything is either a potato or not a potato…" and more ( or less? ) importantly: "This web site would be great as an app!"? If you did, you're not alone, buddy boy!

Some very cool folks over at Internet HQ ( don't fact check this just blindly believe that it exists ) that govern how the internet behaves agree with you ( the potato thing AND the web site as an app thing! WOW! Look at you go! ).
They introduced a concept called Progressive Web App - PWA, for short.

It's called Progressive Web App because it progressively gets better as you use it

PWA = Progressive Web Awesome!
There are a couple of key things that'll make you want to rock out with PWAs

Offline Mode

Imagine this scenario.
You're on a news site and just finished reading an article, at some point in time later you want to reread that same article or show it to somebody else but there's a catch!

You don't have internet access!

If the article you want to read is on a non-PWA site you're EFFED and getting a big fat serving of "No internet connection" screen buuuuuut if the article is on a PWA site you'll be reading your article just fine.

What PWAs can do is save the web pages you've visited and make them available even when you don't have internet access.
To me this is a game changer, it mitigates every web site's greatest weakness and, in some cases, completely nullifies it!

Push Notifications

Lets take a look at another scenario.

You own an e-commerce site and looking at your web site analytics reports you came to the conclusion that a lot of your visitors come to your online store, look at items, think about buying something, maybe even go through some of the purchase process and then just leave never to be seen again.

What PWAs can do for you is send push notifications that feel natural and look native to the device your visitors are using - even if the browser isn't open on their device - to let them know that the item they've been looking at earlier is, for example, discounted and with the click of a button can place them back in the purchase process where they've left off.

The takeaway is clear.
Having a PWA site is like having a sales person working around the clock on bringing you new customers or re-engaging with old ones, letting them know you still value their business.

A really good example is Jumia. There's a link later in the blog, make sure you check it out.

Web Share

In this scenario…

I'm kidding! No scenario for this one. Phew!

Kidding aside, the ability to share content between apps and platforms in the modern world is absolutely necessary.

Web share invokes the devices native share functionality, this means that any app or platform that has allowed sharing on it PWAs will be able to share content with that app or platform.

I lied we're gonna go through a scenario

Say you own a business and sharing content is a key part of your online marketing strategy.
When you first hired a web development studio they integrated Facebook and Twitter sharing and that was perfect at the time but later on your business has grown and expanded to, lets say, China. Nice!

Now you need to integrate sharing on WeChat. In order for you web development team to integrate WeChat they need to read the developer documentation ( which may or may not be translated to a language your developers are comfortable with ), next they need to write the code, after that they need to test if the new code works and also that it doesn't break any of the old functionality.

All of this work costs money - hundreds if not thousands of dollars that could have gone somewhere else like marketing for your product.

With PWAs all of this avoided because writing one sharing functionality covers all relevant platforms for your web app visitors.
Share away my wayward son!

Cuts Costs

In most cases businesses don't need anything more than a web site to be present and relevant online but in other cases they need a small part of functionality that is reserved only for native devices.

This forced businesses to invest in costly native apps for both Android and iOS which can cost anywhere between $20 000 and $120 000.

PWAs want to solve this by making web sites more like native apps and extending their functionality with device native features, as a result it cuts costs significantly because companies now have to develop only for one platform instead of three.

Thanks PWA!

Progressive Web Apps turn a boring old web site that's just THERE to an indispensable tool for converting visitors to clients

Success Stories
Still not convinced that PWAs are the sauce of awesome? Fine, lets ask these upstanding businesses:

AliExpress ( LINK )
Aliexpress is a popular e-commerce site that lets you order items directly from China.

After migrating their site to PWA these are the results they saw:

104% for new users across all browsers; 82% increase in iOS conversion rate
2X more pages visited per session per user across all browsers
74% increase in time spent per session across all browsers

Jumia ( LINK )

Jumia is a leading e-commerce site in Africa. I'm gonna highlight the challenge that they faced ( taken from the LINK above )

Nearly a quarter of shopping carts were abandoned on Jumia's mobile site every day.
To counter this, they reminded customers via email to complete their purchases. But getting people to provide their email addresses is challenging, and email open rates are low. With over 65% of their web traffic on mobile browsers, Jumia looked to progressive web app technologies like Push Notifications to solve their problem and re-engage mobile users who had abandoned carts.

What PWA did for them:

38% Open rate
9X more conversion on previously abandoned carts from web push users
7.85% conversion rate on previously abandoned carts from web push users, vs. 4.5% for native app

Twitter ( LINK )
C'mon… I'm not gonna explain Twitter to you, you know what it is.

Twitters PWA became the default web experience on mobile devices in April 2017.

Note from the Engineering Lead:
Twitter Lite is now the fastest, least expensive, and most reliable way to use Twitter.
The web app rivals the performance of our native apps but requires less than 3% of the device storage space compared to Twitter for Android.

Results:

65% increase in pages per session
75% increase in Tweets sent
20% decrease in bounce rate

You Want a Piece of This?!
So you saw the greatness of PWA and want to get in on the action.
You could spend months learning the necessary technology and how to write PWA code or you could head on over to jsguru.io and let us do all the heavy lifting for you.

Before you go…
If you enjoyed reading this post please share it. You should check out our other publications, you might like them too! We write from time to time about software development, tips and tricks, and how to become a better developer and business person in general. Join us on the journey of constant improvement!

Originally published at jsguru.io.

React image lazy load component Revisited

Bojan Gvozderac — Thu, 24 May 2018 08:06:31 +0000

A long a$$ time ago I created a simple React component that would lazily load an image and while it’s busy loading an image it would show a placeholder and wrote a tutorial how I did it. It is inspired by Polymer’s iron-image and a neat little trick how to transition from placeholder to loaded image.

The Magic
While playing around with Polymer (shameless LINK to another article I wrote) I learned that you can make a pretty cool “Blur Up” animation by taking the image you want to show, scaling it down to 1% of its width and height, using that as the placeholder and when the original size image is done loading you fade it in over the placeholder.

This creates an effect that looks like a blurred image hinting what it’s supposed to show suddenly sharpening to reveal the original image.

Sweet!
The Reaction
He he… see what I did there? The title is The Reaction and we’re talking about a React component! …I’m sorry you had to read that.
When I released my component into the wild I thought it wouldn’t be interesting to a lot of people since it’s a relatively basic component but to my surprise the interest for my component started growing and growing.

Thanks React community! Appreciate it!
The article I wrote keeps getting views and claps and according to medium statistics the activity is coming mostly from google search!

It made me really happy that I found a topic that continues to interest the React dev community and that I offered a possible solution to a problem as well as shared some of my knowledge.

The Realization
Looking at everything that’s happening something dawned on me…

While the article explaining the concept behind image lazy load and the neat trick I learned from Polymer is cool, the component it self sucked big time.

That’s why I decided to rework the component and publish it on npm as a library!

The Good Stuff
If you’re lookin’ for that sweet sweet component to use in your sweet sweet project then head on over to sweet sweet npm and install it (sweet sweet LINK)

If you’re looking for the Github page you can find it here (LINK)

Originally published at jsguru.io.

Top 10 reasons to upgrade your Angular Application

Boris Joskic — Thu, 03 May 2018 12:01:09 +0000

Angular is a popular JavaScript framework, used to create web, desktop and mobile applications. It is built and maintained by Google.

Angular 5 (codename pentagonal-donut) was released on November 1, 2017, a major release containing new features, and focusing on making your Angular application faster, smaller and easier to use.

So, with all these new features, what are top 10 reasons you should upgrade to Angular 5?

1) Performance

Angular 5 will make you application smaller and much faster. Angular CLI v1.5 comes with a build optimizer turned on by default and Angular compiler is improved to enable faster builds and rebuilds. Size of the bundle is reduced by removing AST classes, only changed files are emitted for incremental compilation and much more. Ahead of time compiler is turned on by default and it is much faster than in Angular 4. It’s different from Just In Time compilation because it converts Angular Typescript into JavaScript code before the browser downloads and runs it. The Just In Time compiler was compiling application at runtime. Using AOT gives faster rendering, smaller download sizes and detects template errors earlier. This makes Angular 5 faster in development and production.

2) Progressive Web Apps

A Progressive Web App (PWA) is a web application that uses modern web capabilities to deliver an app-like experience to users. It is an experience that combines the best of the web and mobile applications.

A Progressive Web App works for every user, regardless of their browser, it’s responsive, always up-to-date thanks to service workers, and if served via HTTPS, it’s safe as well, and all the while it feels like a real app!

Right now, the development of progressive web applications a complex process. One needs to take care during both development and deployment that neither caching nor the delivery of older versions is impaired.

This has changed with Angular 5. The development of progressive web applications should be simplified so they can even be created by default.

With Angular-CLI, Angular has the ability to create configuration and code on its own. Essentially, this allows the creation of mobile web applications that have features of native mobile applications, like offline capability, push notifications and an application logo in the start menu of a particular platform.

3) Build Optimizer

The Angular team focused on making Angular 5 faster, smaller and easier to use. In Angular 5, production builds created with the Angular CLI will now apply the build optimizer by default. The build optimizer is included in Angular CLI.

The build optimizer removes parts of your application that are not needed, and it removes Angular decorators from your application’s runtime code. Decorators are used by the compilers and are not needed at runtime and can be removed.

This reduces the size of your JavaScript bundles, and increases the boot speed of your application!

4) HttpClient

Before version 4.3, @angular/http was used for making HTTP requests. HTTP is now deprecated and the HttpClient API from @angular/common/http package that shipped in version 4.3 is now recommended for use in all apps.

Some of the features include

● JSON is an assumed default and no longer needs to be explicitly parsed

● Interceptors allow middleware logic to be inserted into the pipeline

● Progress events for both request upload and response download.

5) New router lifecycle events

Router has new lifecycle events, allowing you to track the cycle of the router from the start of running guards through to completion of activation. These events could be used for things such as showing a spinner on a specific router outlet when a child is updating or to measure performance of guards and/or resolvers.

This new lifecycle events are GuardsCheckStart, ChildActivationStart, ActivationStart, GuardsCheckEnd, ResolveStart, ResolveEnd, ActivationEnd, ChildActivationEnd.

6) CLI

Starting with Angular CLI version 1.5, support for Angular 5 is added and the CLI generates v5 projects by default and build optimizer is also turned on. By default, the build-optimizer plugin will now be applied to your build if you are using Angular 5 and building in AOT.

Build command

ng build --prod --build-optimizer

is now simplified to

ng build --prod

Angular CLI will also warn you if you are using version of TypeScript which is not the recommended one for your Angular version. You can deactivate the warning (only if you believe in yourself and you know what you are doing) with

ng set typescriptMismatch = false

7) Forms

To improve performance, we can now specify when validators should be executed. Every time a value is changed, the validation will most likely be performed with every keystroke!

In Angular 5, forms have the ability to decide when the validity and value of a field or form are updated via on blur or on submit, instead on every input event. This can drastically improve performance!

To improve performance, you can now specify when validators should be executed in forms.

8) Pipes

In previous versions, Angular has relied on the browser to provide date, number and currency formatting using browser i18n API’s. Users were seeing inconsistent results across browsers.

Angular 5 comes with new date, number and currency pipes.

Pipes rely on the CLDR to provide locale support and configurations for any locales you want to support.

Here is a document that compares pipes between v4 and v5.

You are not ready for the new pipes? You can import DeprecatedI18NPipesModule after the CommonModule.

9) Incremental builds

A lot of improvements have been made to the Angular compiler to make it faster, and it now enables faster builds and rebuilds. Ahead of time and incremental builds are possible when using –aot with ng serve command. This will probably be used by default in a future version of the Angular CLI.

10) Better Typescript and RxJS support

RxJS version 5.5 introduces a new way of using RxJS called ‘lettable operators’. Any operator can now be imported from rxjs/operators. These new operators eliminate the side effects and the code splitting / tree shaking problems that existed with the previous method of importing operators. New Angular CLI will pull this version by default and will save considerably on the bundle size!

Would you like to upgrade your application to Angular 5?

The Angular team built a nice tool to make upgrading as easy as possible or send us a message at info@jsguru.io.

Before you go…

Originally published at jsguru.io.