DEV Community: Web Dev Ken

A Motivational Post About Creating Good Web Frontends

Web Dev Ken — Mon, 09 Aug 2021 09:08:08 +0000

Often the frontend is called the place where the user experience takes place. The counter part of the frontend is, you guessed it, the backend. The backend handles the data that is produced or prepared for the frontend. A frontend can be a web application, a dekstop application, a smartphone app, a smart watch app or even a ticket wending machine. In short, every user interface that has some what a backend behind it, is called a frontend. Nowadays most popular frontends are the ones created for the web, let's call them web frontends, because they are run in the web browser.

Web Browsers

In the early days web browsers have been used to deliver information only. You could open a web page for a restaurant, get some information about the menu, opening hours or location, close it and done. Today, we deliver in addition to that a completely new and different experience. We want the users to stay on our page. A web browser is a great platform for creating more value for the user. Just imagine the amount of devices that have web browsers pre installed: Notebooks, smartphones, tablets, yet even game consoles have web browsers installed. It's crazy.

The Thing That Makes It So Great

Web browsers are the portal to the internet for everybody and thus to that experience. We as frontend developers take a great role in creating and enhancing that experience. We can create something that is immediately available for billions of devices. We are the ones that are actively participating in producing that experience. We are at the front door.

A bad frontend would make the users unconfortable using your solution and they would probably not like to come back. Imagine a good frontend to be a store or a restaurant where the user actually wants to visit often. A good frontend makes the user happy, leaves a positive experience and ensures the user comes back again.

So my dear friend, create something awesome where the user wants to come back and stay at your place. It will not be an easy journey, but it will sure be worth it at the end!

Undefined vs. Null

Web Dev Ken — Fri, 06 Aug 2021 09:22:04 +0000

While developing some awesome applictions you might have come across types or values like null and undefined. The documentation for these types and values can be sometimes pretty confusing. So I am going to try to explain it for you in a practical way, so you can use them wherever you need while also understanding what they do. I will also try to give you examples where you can or have to use them.

Let's get started!

Null and Undefined: Empty Values

Null and undefined are values that belong to the type of empty values. Empty value means the absence of a real value like boolean, number or string.

The main difference between those two are, that in the life cycle of a JavaScript application you would never receive null, unless someone has explicitly put it there. On the other hand, undefined is something that can be produced by JavaScript itself.

Let's consider a simple example:

const me = {
  name:   "Web Dev Ken",
  age:    "Old enough",
};

console.log(me.email);
// undefined

In the example above, I have an object with name and age. If I try to access the property email, I receive undefined because that property doest not exist.

Let's see an example where null comes into the party.

function getObjectProperty(property) {
  const value = me[property];

  if (value) {
    return value;
  } else {
    return null;
  }
}

Above I have a simple function that receives an object key as an argument and tries to access that property from the object me. In the if-statement I check if the value is available and return it accordingly. If the value does not exist, I explicitly return null. Here we can see that there is no way that JavaScript somehow returns null by itself. It's something I have put there to fullful a purpose.

Let's consider a more advanced example with TypeScript:

type MeType = {
  name:   string;
  age:    string;
  email:  string | null;
};

type OtherMeType = {
  name:   string;
  age:    string;
  email?: string;
};

Above I introduce you two very similar types. MeType has name, age and email and OtherMeType has the same properties. The difference is with the property email, that explicitly can be null with MeType but that is optional with OtherMyType.

const meType: MeType = {
  name:   "Web Dev Ken",
  age:    "Old Enough",
  email:  null
};

const otherMeType: OtherMeType = {
  name:   "Web Dev Ken",
  age:    "Old Enough"
};

In the code example above I create to objects, one of type MeType and the other of type OtherMeType. In the case of MeType I necessarily have to set the property email where in the case of OtherMeType I don't. Once we log the property email, we will see what this leads to.

console.log(meType.email);
// null

console.log(otherMeType.email);
// undefined

Above you can see the result of logging the property email from both types as a practical example. With meType.email we gave our object a possibility to be either a string or null. While on otherMeType.email we actually don't know if there is a value or if it results to undefined.

As you can see in the examples above, null is something we as developers can introduce and that is not produced by the JavaScrpt mechanism itself. This can be very powerful especially in TypeScript, if you want strict type safety and not deal with undefined, you can create your types by explicitly setting null where you have an absence of a value. Afterwards you can strictly check for null in your code like me.email === null and create robust and predictable code.

Why JavaScript Numbers Are Not Precise

Web Dev Ken — Mon, 02 Aug 2021 16:09:39 +0000

You might have already heard not to do mathematical calculations with JavaScript. Atleast if you need precise results.

But there are whole numbers, decimals and floating point numbers in JavaScript. Why can I not calculate my mathemtical formulas with it?

At first glance, it might look like JavaScript displays large numbers correctly. Mostly it does, but then mostly it doesn't. Why is that? There is actually a pretty concrete reason from the perspective of a computer, but we will get to that in a moment. Let's first look at some examples:

const divide = 15 / 3;

console.log(divide);
// 5

As in the example above, 15 gets divided by 3 that results in 5, if we log the result to the console. Everything fine so far. Let's do a more complex calculation.

const divide = 15 / 0.1;
console.log(divide);
// 150

In the calculation above, we divide 15 by 0.1 which results in 150. Still no issues, right? Let's make the divisor smaller and observe what happens.

const divide = 15 / 0.01;
console.log(divide);
// 1_500

All OK.

const divide = 15 / 0.001;
console.log(divide);
// 15_000

Still OK.

const divide = 15 / 0.0001;
console.log(divide);
// 150_000

Hah! No issues, give me more!

Note: I am using thousands step notation like "1_000" for better showing the growth. The console.log actually doesn't display numbers that way. Writing numbes that way however is absolutely valid in JavaScript.

Until now everything seems to work as expected. The next line will change your expectation drastically:

const divide = 15 / 0.00001;
console.log(divide);
// 1_499_999.9999999998

What happened? We expected 15 divided by 0.00001 to equal 1_500_000 but actually received 1_499_999.9999999998. What's going on? Let's explain that.

The Explanation

Not only JavaScript, but also other programming languages have sometimes issues in displaying large floating point numbers. Consider the number PI, which is something like 3.141592653589793... and so on. Pretty much every programming language has problems displaying the full number PI, but why?

The reason is pretty simple: Memory space. Holding a large floating point number actually needs a lot of memory space to display it as accurately as possible. Most programming languages have therefore agreed on a strategy to solve this problem. They either round the value at the last comma place, once it reaches the end of space, to fit back again (also called approximation). Or they use a special type like BigDecimal in Java or BigInteger in C#, to reserve more memory space than the normal number type like int or double.

When it comes to JavaScript, it runs in an environment where it has certain limitations and design choices baked into it. One design choice why it results in even less accurate numbers is, that whole numbers, negative numbers and floating point numbers all have to fit in 64 bit memory space. You can imagine that shortenings had to be made to actually fit all these numbers into a limited space of 64 bits.

Source: Values, Types, and Operators

How should I display large numbers in my application?

The answer is easy, you don't - if possible. Because eventually you might run into inaccuracy very quickly. If you have an application with a backend that uses a programming language that can handle larger numbers, you could use JavaScript to only show these numbers as strings. Or you could use JavaScript NPM packages like decimal.js or bignumber.js, that can handle large numbers a little better. At the end you have to acknowledge that JavaScript has these limitations.

Why I Decided To Stay A Frontend Engineer And Stopped Searching Full-Stack Jobs

Web Dev Ken — Mon, 02 Aug 2021 14:55:00 +0000

My goal writing this post is to emphasize you to deepen your knowledge in the field you are currently in, instead of trying to move to new fields too quickly. If you are a frontend engineer yourself and think what you do are basics, read my story!

My software engineering career has pretty much started in January 2018. Coming from a mechanical engineering profession, it was hard for me to easily get a job in software engineering. At the time, I successfully landed a trainee job at a small company that had a frontend solution for their clients that was built with Angular. At work, I was confrontend with Angular, UI Architectures and Client-Server Architecture. Learning Angular was pretty fun, because the framework itself developed very quickly and there were tons of things to learn and apply to the application I was maintaining.

After two years as trainee with a solid knowledge with Angular, I decided to move on and get a job as a software engineer at a company that deals with multiple projects, so I can learn from different environments. Luckily, I could land a job at an agency that helps customers expand their digitalization strategy by creating React frontends for their needs. Meanwhile I finished my study and received my bachelors diploma in computer science. After one and a half year at this company, occasionally looking at my local job market, I noticed a trend in full-stack developers being eagerly employed by mid to large companies. There were double more full-stack jobs than frontend jobs. As a fresh baked software engineer, I wanted to get future proof by gaining knowledge as a full-stack engineer, so I can always easily find a job once I need a switch again. But I had pretty much no knowledge about creating full-stack applications. From university I learnt all the basics like relational databases, service architectures, MVC and even .NET and C# basics, but I had no practical hands-on in years. So I decided to deepen my knowledge in C#/.NET in my spare time by creating leisure projects and learning online.

Mid 2021 I started applying for various job descriptions that were looking for a .NET full-stack engineer. In total I had three job application interviews that, almost predictable, all rejected me. Here are the reasons why:

Interviewer number one

The first one wanted me to create a small solution for visualizing IIS logs that were saved as text files. So I created a solution where the files get parsed, written into SQL database, read from with Entity Framework, mapped to a data transfer object with a mapper, sent to the client through an API endpoint via JSON and nicely displayed in the browser. I thought, that's what full-stack developers do. I handed in my solution in time and was invited to the company to present and discuss my solution. After presenting my solution, the responsible guy started to ask me questions. These were questions like:

What does LINQ do internally?
What does line number so and so do (on an automatically generated .cs file)?
What are the differences of objet and value types?
What can be potential caveats of your application when you need to handle millions of lines of logs?
What are memory leaks?
What is garbage collection?
What is encoding UTF-8?

The moral of the story was, that he asked me lot's of questions about backend development which I could barely answer. There were pretty much no questions about frontend engineering. So my impression was, that these guys were actually looking for a backend engineer that knows a bit HTML/CSS and not a full-stack engineer. After getting rejected, I moved to the second interview.

Interviewer number two

The second interviewer didn't require me to create a small application, but during the interview they wanted me to create a UML class diagram of a problem description within 15 minutes. So I tried my best to create an agnostic diagram and try to solve the problem. They asked me questions about my solution which were related to creating a relational database out of it. Overall, they further asked me questions like:

What does the keyword virtual do in C#?
What are the differences between abstract classes, interfaces and class inheritance in C#?
Does an abstract method has to be overriden or not?
What is the difference between SQL and No-SQL?

They mainly asked me conceptual questions like class modelling, relational databases and so on. Again, there were little questions about frontend engineering and UI architectures.

Interviewer number three

The third interviewer had pretty much only technical questions about .NET and SQL Server. These were questions like:

Can you inherit from multiple classes in C#?
What are SQL Server functions and procedures?
What is a left, right and inner join?

With this interviewer, there were equal amounts of questions for frontend and backend. I pretty much could answer the frontend questions perfectly, but the backend questions almost none of it.

My conclusion

After getting rejected from all three, I was extremely frustrated and felt like that I was stuck creating frontends forever. At the beginning, I had great interest in also doing backend development, but I highly overestimated my skills and didn't really know what a backend engineer needs to know. After calmly thinking and re-considering the feedbacks I received, I thought about the constellation of these interviews. As can be seen, they didn't want to know that much about my frontend engineering skills, just as if they were looking for a classic backend engineer only, who has some frontend skills. I could have been miserable in creating frontends and still land a job as a full-stack engineer, if I could answer their backend questions well. For me this meant that in the industry in my area, or at least the companies I had an interview with, still didn't recognize frontend engineering as an own discipline with an enormous complexity, that even has it's own bachelor programs nowadays. Becoming an expert in backend and frontend at the same time with a certain amount of deepness was no option for me. So I had to set my focus and move on.

After all this, I recognized what I really wanted. I wanted to become a very skilled frontend engineer. Being a good frontend engineer requires a lot more than just creating fancy HTML with some JavaScript and CSS. I noticed that there is actually still a lot of things to learn creating frontends and that I actually just had started my journey. Yes, I didn't even know all the parts of JavaScript yet. Why should I switch disciplines before becoming an expert at what I do right now? From now on, I will dig much deeper, try to learn everything about the web and become a great frontend engineer.