Paying for online courses: Good or Bad

Let's get right to the point: how often you think "ah, paying 15$ for udemy or coursera course is not worth it"?

Of course, because you can find everything for free, right?

Take a step back and consider something known as perceived value of digital/physical goods. The reason physical books for example are still alive is because people treat them as an extension of themselves, whereas online course in Java can be treated as something less important and valuable.

The reality, however, is that you should count the value it brings and the time you spent enjoying the purchase. The average lunch in London can be approx. 8$ (coffee, sandwich and a cookie), you enjoy it for abstractly 40 min and then leave the cafe (money spent, value received).

Time in this instance (as well as in our whole life) is the only limited resource we should really care about. Time is strongly linked to happiness as with this finite resource you can choose whether to spend time with the important ones, make money, read a book, watch a film, do laundry etc. It is the one and only thing we have in our lives and if we value it properly, it can make us better and happier as a result.

Now back to online courses.

While I was learning coding, I have gone through tons of material online, normally thinking that I can always find a free alternative and make the most out of it. However there is a trick that I didn't know about at that time.

The free stuff is free, just because there is a better paid version

(read it one more time)

Most of the free programming courses that I found useful linked me to a more detailed paid ones and while it was fine to grasp the basics, when I wanted more - it always required me to pay. It is understandable though, a professional developer invest their time and effort, share tips and their experience and does expect to get a penny back. And we all want to learn from the best, right?

This is just how it works.

Google Taylor's motivation theory - he proved that the main incentive for people is actually money (and not perks, benefits, recognition - although that also counts).

Which is why it is not unfair, ugly or bad when someone wants to get paid for what they do, it is unfortunately how our world works🤷🏻‍♂️

With online courses it is also the fact that the guys combine and filter all the informational rubbish that wouldn't get you anywhere, add their own unique experience on top - and there we have a perfect recipe for good course. The logic is dead simple - you can spend 10 hours filtering, testing and finding the good content yourself or pay for a highly ranked course online and get it all right away. As a result, 10 hours saved, which you can actually use to make something with the new skills you learnt and make money (often more than you spent on the course).

☝🏻Finally, my personal statistics show that I am more likely to finish the course that I paid for than the one I got for free. We tend to value money that we spend and want to get the most out of it.

So what are you waiting for? Stop complaining about unfair, money-focused world, go get yourself a course for a few bucks in Neural Networks, AI, Blockchain, Mobile development and learn something that can actually make you rich and let you enjoy your time more efficiently 👊🏻. Good luck!

Agree? Join @thefrontend

(might even get a few dev courses for free, who knows 😀)

Yesterdayby The Front End


Since many of you wanted to know more about the specifics on PWA and INSTANT APPS, here is a quick review on the two, we will look at the 3 basic componential parts.

  • Speed
  • Build complexity
  • Branding

But first it makes sense to do a bit of googling and wikipedying.

First PWA, what is it and why does everyone talks about it?

Google as usual is the one standing behind popularising this concept. While you will see a lot of bold words like: fast, reliable, engaging. Esseintially it is a web app built with typical tools like HTML, CSS, JS and that has a nice caveat around it that can utilise something like service workers that stay in between your web app and the server. This allows PWA to have something that normal web sites won't provide - ability to work offline.

You can easily try telegram, instagram, facebook as web apps and pin them to your mobile home page. So in short, it will provide you the typical app's functionality and will work fine.

Don't confuse it with responsiveness though. While it does inteconnect, your Bootstrapped web site will not be considered as PWA just because it adapts to your user's screen. It will simply be a responsive site.

There is only 1 problem with this: since it is not an app, it is hard to get to phone's functionality like Bluetooth, Flashlight etc.

Then what the hell is Android Instant Apps (AIA) and why not use normal apps?

The AIA is in short is a real app the has access to all your phone functionalities. At some point Google realised that people are sick from dowloading stuff from App Stores and thought on how to make it usable without downloading software to your phone. The picture above nicely represent the concept and main difference from the typical apps you see. It is frankly just a lighter version of an app.

If you have a news app, you can create a lighter component of the app and Google will catch it automatically, show it in the search, but instead of linking it to the Google Play, it will load a lighter component directly in the browser and you can use the app.

Now the fun part.


Let's try to find a random AIA and PWA to compare. For the last there is a nice website that has a list of PWAs - And for the AIA - anything that Google retrieves can work.

PWA Financial Times.

It will open in a perfectly responsive form, suggesting to add this web app to the home page (nice addition as you can later launch it from home). Loads pretty fast, the drawbacks are the search bar (which does dissapear if you launch from home screen) and the fact that it is not an app - you can feel that your experince is not as smooth as the typical app will provide.

However it does the job, loads very quickly and some other examples (e.g. telegram) can work offline - will take your message and send it as soon as there is an internet connection, which is similar to the app.

Taking news website as an alternative.

It actually does offer both PWA and AIA. When checking it out we can see that the main page loads without significant differences for both. However if you open for the first time - you will notice that the AIA starts downloading something (which looses in the speed battle) - that is that ligher app's component that can be used in the browser.

The good part is that in the further launches it will be instant and will outperform PWA.

Meduza AIA:

The AIA will even create an 'instant app' that you can launch in the future right away:

But news web sites are something simple to compare - let's dive deeper.

Take a financial manager tracker or a messenger as an example. The PWA will launch fine, will work offline, can be added to the home screen BUT you will definetly say that it is not an app. The speed, animations will be like what you see in the web.

The messenger's AIA will be different. But the question is - does it actually exist? Which part of the messenger can be considered light? Shall we remove ability to record audio or send stickers? That is the main AIA's problem - it is unlikely to even challenge this problem and only cope with news apps, info apps, online shops where PWA can do it all (unless you need to access a flashlight in your app).

Build Complexity

This one is tricky. On one hand, to build a proper PWA you will have to first make a responsive web site, differentiate between all devices (tablets, phones), allign your components so that it can be seen nicely on all devices. Add to those the fact that you have to add service workers (and learn how to use them) - and building PWA doesn't look like a 3 min deal anymore.

AIA subjectively is easier. You are building an app anyway and just by specifying in the app which component to load (e.g. only news retrieval) - you can hit two birds with one stone. But you also should remember that AIA is not as popular and iOS users won't be able to use it yet.

So while AIA does offer a nice, more native experience, you can simply loose iPhone users because of this and well people also won't use your instant app on PCs for obvious reasons.


It became too popular to shout out that we are PWA, we are modern, smart and reliable. Or also - we are AIA, which most people will think you are speaking Chinese.

The reality though, is that if you are building PWA - you can be considered trendy, a huge proportion of users can start using your service without downloading uneccessary stuff.

Check mitty as an example, it is an iOS app built in Swift, but that has a selection of PWA apps like uber, skyscanner, airbnb etc - so instead of downloading all of them you can download 1 app and have access to the rest. One could argue however, that you can also just pin uber, telegram, facebook, airbnb to your home screen and then there is no need to download apps at all.

On a personal note, I have a belief that both conepts are here to stay - and those who master both PWA and AIA will rule the world. Development of full native apps will be displaced by PWA, and AIA's responsive sites and web services like online shops will be able to compete with PWA by providing a light component of the app.

Finally, if you read it all the way till here, take a minute and think about this:

Why is it mainly Google that tries to push the industry to the new standards? Why does Apple stay aside and doesn't invest into industry's evolution? What would happen with its App Store revenue if suddenly everyone moves to PWA?

Liked the article, disagree or want to discuss?

Join @thefrontend in telegram

August 30, 2018by The Front End

SASS in 15 minutes

If you write a lot of CSS, preprocessor like SASS can significantly ease the amount of your work and your stress levels. Things like SassLessStylus or PostCSS make your CSS files more readable and improve maintainability. Thanks to variables and functions the code will become cleaner, better structured and as a result help developers to work faster and make less errors.


The browser on its own doesn't understand Sass files, so it needs to compile them in the normal plain old CSS. Hence, we'll need something to convert .scss files to .css. And there are several options here:

  • The easiest way - is a browser converter for compilation Sass on the spot — SassMeister.
  • Usage of apps: there are both paid and free ones available. Read more here.
  • If you a command line - lover, you can install Sass on your machine and compile it manually.

If you choose the command line at then end - you can install Sass in its original wrapper, developed on Ruby or you can try Node.js port.

You can compile .scss file using the command line like this:

node-sass input.scss output.css

Also, it is now a good time to mention that Sass offers 2 different types of syntax: Sass and SCSS. Both do the same thing, but developed differently. SCSS is a bit newer and normally considered to be a better option, so we will be using that. If you want to read about the differences on the two - have a read here.


Variables work in exactly the same way you saw in every other programming language. When declaring, we store a specific value in it, which we usually see in CSS like color, font or any other property like box-shadow.

Below are the examples of such variables in SCSS and CSS.

After compilation, the above will look like this in CSS:

The idea is that it can simplify the process of repetitive usage of variables and also we can quickly change the value of a specific variable where we declare it instead of surfing through your code.


Mixin can also be used as a class-constructor in the programming language: you use several properties from the CSS creating a separate object, which later can be used wherever you want assigning different values to its properties.

Have a look at the example below:

Thats what we will see in CSS:

One more way to simplify you work with mixin is to use it with prefixes for browser adaption.



Next nuance that we will look at is @extend. It allows us to inherit CSS properties to one selector from the other one. The principle is somewhat similar to Mixin, but Extend is mostly used to create logical connection between the page elements.

E.g. Extend is used when we need 2 similar elements that has slight differences. For example, let's take 2 buttons: Confirm and Cancel.


If you have a look at the CSS code, you will see that Sass combines selectors instead of repeating the same ones several times in the code.

Nested constructions

As you would know, in HTML the developer write code following the 'nesting' principle. In other words, blocks of code are located in other blocks. CSS on the other hand normally looks chaotic in this sense. If that is a problem for you Sass can help you to organise and structure it.

An example of code in SCSS:

And the same in CSS:


You can do different mathematical operations right inside the code, which massively improve the workflow.


Although right now you can do the same thing in CSS by using calc(), the Sass alternative method is faster to write and has mod (%) operation and also can be used in a wider spectre of types.


Sass provide a huge list of functions. For example, functions for operations on lines, colours or different mathematical operations like random() or round().

To make it a bit more visual let's have a function darken ($color, $amount), which (as you probably guessed) will darken or attach hover effect.

SCSS code:


In addition to a huge list of functions, you can also declare your own.

Some parts of the above will eventually get to the normal CSS, but till then preprocessors are a great way to make your life easier and Sass here is a very decent choice.

*Translated from WebDev.

*Join @thefrontend channel for more🔥.

July 8, 2018by The Front End

Learning Material

☝🏻Setting up the environment with React

(the fastest and easiest way is to use their official 'out of the box' solution)

☝🏻Thinking in React

(it is pretty specific on how React view development with breakdown into different components. The link also has official facebook tutorial on the right)

☝🏻Best way to structure your React dev is to split everything in Components/Containers view 


React Bootstrap 

(React's bootstrap can slightly vary from a normal one, just to make our development a bit more.. like React style) 

Refresh your JS knowledge


(the best quick videos I have seen on how firebase work with React. They have a series of videos there on Firebase+React)

To add on the above, this guy explain really well the authentication in React


a few practical examples in React

A lot of quality content on React with examples

July 7, 2018by The Front End

Cooking with JS asynchronously

What the hell are callbacks, why do I need to promise anything, what's all the fuss about async/await stuff?

If you have ever asked those questions yourself. Here is a quick recipe how to not get confused.

First, let's cook some Carbonara🔥.

To do this, we basically need few things (the example is simplified)

🔸 Cook pasta

🔸 Cook bacon

🔸 Mix the two

🔸 Throw a bit of cheese in

Now that the functions are done, let's call them.

Couldn't be easier, right? What we end up to see in the console is a nice list of our actions.

Ready to get your lunch? Not so fast. To the left from the log you can see the time at which the function was fired. Looks like we outperformed Michelin star chefs and got pasta and bacon ready in just a few milliseconds.

Doesn't look too realistic..

Let's bring us back to reality and simulate at least a tiny lag in the first 2 functions. Don't worry too much about the setTimeout function for now, what it does is simply waits for a bit and then logs the stuff we want.

Shouldn't make it catastrophic, let's see how the console looks right now.

Shit. Something clearly got out of control. One cannot add bacon to pasta, put cheese on top before those 2 are not ready.

This is what real life looks like though. And the problem we experienced here has something to do with the fact that all functions were fired simultaneously. In other words, JS didn't care whether we finished cooking pasta, it went on launching other functions in the meantime.

Since the example was simplified, you can only imagine what kind of damage to your app would this bring in the real world.


One way to deal with that is to use something known as callbacks. Regardless your favourite computer language, this will refer to a "call after" function, or in other words, anything executable that can be passed as an argument in your code.

Sounds, realistic. Let's give it a shot. To show how the callbacks work, the most simplified example will look like below:

Also we are creating another function to notify us when the cooking has been finished.

Then calling all function and the first 2 with callbacks.

Looks like it worked. But bear in mind that the purpose here is to just show you the concept of callbacks. And you can guess that the more functions you have the more complicated it will get. Eventually with this technique, you might end up having loads of functions calling each other here and there. This has a huge potential to make your code massive and unreadable.

That's where the promises come in.


To put it simply, promises help us to wrap our functions and wait till something returns before moving on to the next function.

In our case, we would like to cook the pasta first, then do the bacon and then all the mixing/finishing stuff.

This is how the implementation can look like. We creating a promise, which will simply return the check emoji on success (on so-called 'resolve') and this will happen after a short time lag.

We then take this result and push it to our prepare() function. The prepare function has also been slightly modified and now also returns the dish after writing it to the console. This should then push it to the next prepare() and so on.

Looks good, we are now waiting for pasta to be prepared, then do the bacon when the pasta is ready, then the rest. This called chaining as we chain through all the .then.

The above helps us to ensure we wait till the promise is resolved and then start cooking pasta. One example of how functions can be fired asynchronously.

In the real world, you normally return something from the function then send it to the next function to use. For example, you could fetch some data from an API, parse it and then send to the next function (which would fail to properly run without getting something from the API first).

The above example again, was simplified to familiarise you with the concept, in real life you will also specify what happens if the promise was rejected and catch errors in each .then

While this is still a better, cleaner solution than callbacks - it can also get pretty messy.


Another way, which is still fairly new and was introduced with ES8 is sync and await. And the main goal is.. well make your code cleaner and smaller again.

The idea here is extremely simple. We have to create a new async function, which is a fancy way of making the functions inside work asynchronously and specify whatever part of it needs to calm down and wait for a bit. This can nicely work with promises, but you can also just wait till the function returns you something.

So for now let's actually drop in a delay for each of the actions to simulate real case. For this we can create a simple function:

Similar to the Promise example, we are creating a delay and on success it should pass the element further in the chain. Also, as it would happen in normal world, we substituted all our console.log() with return , so that now all functions should return something.

Finally, instead of calling all functions one by one, we are going to create a separate function for this and call it later. And all you have to remember is this 2 things:

🔸 You need to use the word async next to the function - this will allow usage of await and will make your code to work asynchronously

🔸 You will have to specify await where something needs to wait till it gets the something back

And please - Do not try to use awaits without specifying async first and do not attempt to await for something in the top level - this wouldn't work. The 2 aforementioned points are must-have.

By looking at the code above, we should expect to see the following process:

'start cooking' will be printed in console → then the variable will wait for 1250ms simulating the time delay for the specified functions. After each function we are also printing out whatever it got after waiting.

Remember, we are now returning things, not printing them in the console. So our combine variable for example will have to use dish and dish2 to mix them and won't be able to do it until both are done.

Finally, we are also adding a nice checkbox ✅ after the element showing us that it has been retrieved from the waitTillFinish() function.

Here, let's have a look what we got.

As you can see now we doing it all with approx. a 1 second delay (still to quick, but good for demonstration). For combination we obviously getting 2 checks meaning pasta and bacon are ready and then the mixing is also done.

You can try it yourself in the Chrome Dev tools, some things will differ, like you won't have to use .this word and probably will need to specify function Name when creating one.

Now that is done go make yourself some Carbonara and make sure you don't add cheese until pasta and bacon are done (wouldn't be good).

Join our telegram @thefrontend

May 18, 2018by The Front End
Show more