I'm a big fan of <a href="https://en.wikipedia.org/wiki/Separation_of_concerns" target="_blank">**Separation of Concerns**</a> (SOC), yet the modern era of Web Development is made of really lazy developers who do not want to maintain their project in a long run. 

But we are where we are. Your write CSS in JS, you write ~~html~~ jsx in js and build your dynamic landing page.

This is super cool but you now have a couple of serious problems. 

#### The Elephant in the room SEO! 
You know that all those javascript libraries are rendered on the front-end right? Yet search engine crawlers work with server-side rendered content, you're in luck nowadays most major search engines added their javascript engine in their crawlers so you have a good chance to get indexed. Although I would not rely on it completely and just push it to the limits. My business is my feeder, I want my feeder to be well and easily found, also it should not rely on experimental tech.

#### The other major problem, 1MB of bundled JavaScript

How much is your javascript bundle? Yeah that thing, transpiled by your babel into necessary code. You might say but gzipped is only 500kb! Well, my friend if you believe that your average user would like to stare at a white screen for the next 3seconds until they manage to download your 500kb worth of javascript then you're wrong. Nobody wants to wait for your site to be loaded for a long time, especially google. You get a lower score if your site loads slow,


#### The Solution

Well, gladly there are a bunch of solution for this. 

**The easy way:** Reconsider if you need to build your application in Javascript, maybe a server-side rendered language is a better fit? 
Criteria you should always keep in mind:
* Is this an application that will require a lot of UI updates in real-time?
* Is this an application that will cover your stories? Like a blog?
* Is this an application that will eventually transform into a mobile app? 
* Are you choosing this tech for the hype around it?

There are many criteria that particular from project to project, but you should think before you make a decision.

**The not so easy but I'm too deep to reconsider using a different framework way:**
I've been like many of you in situations where I should've gone for an SSR framework but I realized that too late. 6 months after we've started developing our project we were given a new requirement, and that was server-side rendering, we had to come with a fast solution, that wouldn't cost 1 month of re-development and re-testing. The solution was <a href="https://github.com/stereobooster/react-snap" target="_blank">React Snap</a>. It's a small npm package that is set-up on post-build as a part of the deployment process. In a nutshell, it launches a headless chrome engine, crawls your site and renders as HTML all your pages as HTML files, then you updated your index file to hydrate or render your app as necessary and you're done. Highly recommend if you don't want to go for **the hard way** (see below).

**The not so easy way:** Before you begin your project start building it with some frameworks that have that out of the box. My prefference here has <a href="https://nextjs.org/" target="_blank">Next.js</a>, but you should definitely consider alternatives like <a href="https://www.gatsbyjs.org/" target="_blank">Gatsbyjs</a>, <a href="https://nuxtjs.org/" target="_blank">Nuxt.js</a>. These are the main alternatives and the best out there that you should definitelly consider.

**The hard way:** If you are a badass developer and think the best way is to build it on your own, and you should not consider the experience thousands of other developers you could always go your own way and build your small node.js server that will handle all your requests, render your pages on the fly and then make your react hydrate with necessary content when your javascript bundle finally loads.

#### Final words

If you should always consider your options and the tech stack that you're going for. It doesn't matter what are you building, it matters what you want to achieve. Here at Emerald Solutions, we consider very well our options and our client's desire and we build what is the best for our clients. In case you want to say hi to us, feel free to use the link below.



blog-post-post-2.jpg

A critique view on modern web development and an appreciation of the right separation of concerns. By a web developer who's been around for a while now. #react #ssr #nextjs #nodejs #separationsOfConcerns

Modern Frameworks and Server Side Rendering

avatar - small.jpg

### CSS should've been written in BEM!

I know I know, it's a weird way to say it, but I truly believe that BEM is that good!

CSS is ignored a lot of times by developers. You hear a lot of *that it's not a real language*, *CSS is for weak*. But they get to the breaking point fast and then this happens:

![text](https://media.giphy.com/media/13FrpeVH09Zrb2/source.gif)

A saviour to this situation is **BEM**! 

How can BEM help and why is it better than anything else?
Well CSS as any other programming language is interpreted by an engine (your browser). Because of that, there are computational expenses when your write your filthy selectors.

Whenever you write something like 
```
#header .nav ul li a {
  /* awesome css here */
}
```

The browser reads from right to left your code to match your selector.

So, in this case, it finds all anchors on the page, then from matched elements, it finds those within a list item, then those within an unordered list, then those within any element with a class name .nav and then those in the element with a header id.

That is a lot of work don't you think so?

To solve this problem you can easily add a class name to your link so that the browser does just one simple query.

Yeah, easy-peasy, problem solved. However, you have to assign a new class name for every link that is different from the other one, in behaviour visual representation and so on. In a project where there's more than 1 page, it becomes a mess really fast and easy.

To solve this problem finally BEM comes in handy. **BEM** means **Block Element Modifier** Please note the singular count, it is very important. BEM refers specifically to your selectors nothing more than that.
There is a specific way to write your BEM selectors. 
These are the rules: 
* you refer to your block as `.block`
* you refer to the element always as `.block__element`, you cannot get just to the .element because in this case, your element is actually a block.
* you refer to any modifications on the element or on the block as `.block--modification` or `.block__element--modification`

No more rules, just follow these rules and it's going to look perfect and you'll enjoy your life.

BEM is a CSS component library for your js components. As you try to keep your components as small as possible it BEM becomes better. 
Let's get back to our selector we mentioned above and split it up accordingly.
`#header` first of all **never** use an id in your CSS. CSS is for generic use, for elements that may or may-not appear multiple times on your page, while IDs are for identifying one element. It's like the identifier you have in your passport, nobody in the world has your id, same should apply to your elements. 
Now back to our styling methodology, header is a block it contains multiple elements. Normally you'd have a logo and a nav in your header, thus you'd have something like this in your file:

```css
// _header.css
.header {}
.header__logo {}
.header__nav {}
```

Now yes we have links and a list and stuff within the nav, but nav is actually a block. So it becomes as follows:

```css
// _header.css
.nav {}
.nav__list {}
.nav__item {}
.nav__link {}
.nav__link--active {}
```

What does this give us? It seems pretty similar, just more files and lots of things to think about. Well yes, but at the same time the CSS Engine, will do only one query for every single particular case and we won't overload it with unused selectors. 

You can always write your selectors as 
```
.header .nav .nav__link
```
but this is not BEM this is an anti-pattern, to solve that, it's better just to write down a modification on your link or block and that would solve up all the problems you have.

Another benefit here is that you usually split up the CSS files separately and keep the names consistent with the block names, so whenever your encounter your block and want to update your legacy code you just open your file-browser in the editor enter _header.css and you know where to do your modifications, you don't need to search throughout the whole project and see if the header is somehow related to your blog-header.css or contact-header. You know that those files live their life and are not related to your file in any possible way.

As a bottom line, I want to ask you and every other developer give it a try, and once you're in there's no way out, maybe only styled-components, but that's a topic for another discussion.

blog-post-post-1.jpg

Block Element Modifier (BEM) the goods and the bads. The when to use it and when to avoid. Web Development done right!

BEM is my true love

**Mobile app development cost** is one of the most popular questions these days. Almost every client we get in touch with, asks us about this non-trivial question.

Because technology advances at a high pace and on a weekly basis, there are new solutions for a problem or another. We at Emerald Solutions, solve every problem our customers face in a matter that is most optimal. We suggest which tech stack you should go for and explain to you why.

Before we dive into the costs, we need to understand fundamentally different approaches which produce roughly the same results. Modern mobile app development is split into three different methodologies.

* **Webview Based Apps.**
* **Native Apps.**
* **Cross-Platform Apps.**

To explain each of them is important and we need to understand these before we can talk about app development cost and choose an approach for our future.

**Webview Based Apps** - as the name suggests is based on web technologies. In a nutshell, your Mobile App runs a browser (Chrome/Safari) and it shows a website designed as a mobile app. This was a popular approach a couple of years ago because it’s very cost-efficient, you don’t need to re-educate your developers on a new technology, it’s roughly the same as developing a website, everything that applies to web apps applies to your mobile app.
It’s drawbacks though were:
* Lack of native feel (not smooth enough)
* Lack of performance
* Limited hardware interaction (Bluetooth, Wifi, etc.)
* Pulls behind a massive amount of issues related to Web Technologies

**Native Apps** - once again as the name suggests, these are native apps. There are 2 major players on the market, Android and iOS (Apple). These have 2 absolutely different programming languages for each Operating System, and everything should be built around that, that’s why there are usually 2 teams of developers that work on both versions of the app in parallel. 
It’s advantages are:

* The best of the best.
* Perfect integration with every piece of hardware
* Flawless operation.
* Secure and compliant with many Security Protocols (e.g. Bank apps)

However benefits come at a cost, which is mainly the only drawback here, and it’s the biggest issue. A native apps targeting both markets is at least twice the price of Webview or Cross-Platform App. Because for every team you have a project manager, a team of developers and a QA.

**Cross-Platform Apps** - is the sweet spot. It’s one of the most popular ways of doing things these days. A lot of big companies like Airbnb, Facebook, Instagram, Tesla, Uber and many more use this approach. Because it’s cost-effective. It uses web technologies but compiles (converts) to native apps which is a big deal because it doesn’t pull behind the drawbacks of web technologies and adopts most benefits of native apps. At the same time 
It’s advantages are:
* Native feel
* Android and iOS in one codebase
* Way cheaper than Native apps
* Smooth apps
* Secure
* Uses one of the most popular web framework on the web (React.js)

It’s disadvantages are:
* Limited hardware support
* Lack of documentation in some areas as it’s still a beta technology.
* Game development is a no-go here.

At Emerald Solutions we develop mostly Cross-Platform Apps because we think this is the way to go. In case you have specific requirements we’re always happy to provide native solutions. 

Now that we understand how mobile apps are built we can discuss their cost. Of course, the cost will differ depending on the project, company, estimated amount of work and amount of changes. But we are absolutely transparent with our clients, and we share this information up front. 

For example, let’s say we want to build a Todo app, it’s small and has basic functionality like adding an item, editing it, removing it, marking/un-marking items as done. Behind the scene, it has to have a database where it stores your items. It should be cross-platform, that involves having a user account and an authentication system. 

Each of these requirements, require work to be done. Let’s say that the main functionality is done within 1 day, authentication is done within another day, and the database connection and organization for infrastructure is another day. So that's a **total of 3 days.**

With the first approach, *Webview based*, you can do it easily enough, yet there are things regarding animations and interaction that would feel sloppy and unnatural, thus bringing you an unpleasant experience. Regardless of the experience, the cost for such an app would be **about 1000$.**

With the second approach, *Native apps*, you can do it easily as well, as this is yet again a trivial task and many can do this and there’s plenty of tech to do it. But because we need 2 developers to accomplish this task it would multiply the cost of the app **to 2000$**. In comparison with the previous approach, this app would feel smooth and would look as good as it gets.

With the third approach, *Cross-Platform*, yet again this is a trivial task, and you can accomplish it within the given timeframe. The cost would **be 1000$** as in the first case, but the app would feel way more natural and very close to a native one. An untrained eye wouldn’t even see the difference, and this is obviously a great result.

Looking across the world, most companies go for the Cross-Platform approach because it offers the best performance for the best price. As this approach evolves it’s getting easier to port your apps to different environments as well as windows native apps, Virtual Reality and Augmented Reality platforms. This looks like a bright future and offers high extensibility for your potential product. 

Besides, it offers high performance, good security, great codebase maintenance and a great opportunity to save money compared to the native approach.
We consider that the Native approach has a good spot anyways and it’s great to be worked on, and depending on your requirements we should take one approach or another. We’ll always advise you which would be the best option for you.


app dev costs.png

Mobile app development cost is one of the most popular questions these days. And we need to discuss this topic appropriately. Exact numbers matter 1000$ bills and 2000$ bills need to be explained.

Modern Frameworks and Server Side Rendering

BEM is my true love

Define: Mobile App Development Cost