What Is Wrong With Frontend? Part 1 — Syntax Everywhere

Image for post
Image for post
by Justin Kolenc (Public Domain)

Why i write this?

I am new here, and don’t know how Medium works. But i thought about it and want to share my thoughts about frontend development, what is wrong with it, and what can be done abou it. Or at least what are my observations are.

This will be a long story, or just a short one. Maybe it is my first and last post about it. It depends on so many issues i can not count. But this is a first step and i am willing to do it.

So what is wrong with frontend? Why i have issues with JS, TS, and frameworks? A lots of writing to make it clear. A lots of confusion this post may create, because it is limited by time i can spend writing it. Please take it in mind, there might be shortcuts, maybe i don’t know about everything, or maybe my concepts and observations are totally wrong, or maybe i have some points. Who knows?

Who am i?

First of all, a little introduction. I am a software developer for 20 years. This is the “bragging” part. So just move on if you get bored. But i will try to make it short: My programming carrer started with Turtle :), than with Pascal. It was kinda cool to make a 3D engine in it. Than i moved to Visual Basic, OpenGL, DirectX. Next was VB.NET, .NET Framework, a little bit of Dephi, C, C++, also Java. My first job as a .NET developer-designer, a lots of versions of .NET i have learned through years as a C# developer for desktops and mobile devices. In parallel i worked on web projects: HTML, CSS, JS, jQuery, and eventually Ember.js, some React and Angular, of course. Also have worked with MySQL, PHP, MSSQL. It adds to my resume, and other technologies i didn’t mention here just to be short. To sum it up i have kinda of a broad experience if it comes to technologies, programming languages and frameworks. And this is something special, cause i don’t think there are a lots of people who know that lots of stuff and in such configuration. And this puts things into perpective. Perspective on web development. So here is what i think about web dev from my experience.

What is wrong with the Frontend?

Web development nowadays is weird. In a good way weird and in a bad way weird. In good, because we have so many technologies. We have React, Angular, Ember, Vue, and they are growing and stimulate growth of whole amazing ecosystem that gives us all so many benefits as users. Everyone can participate, its open. Who would have guessed 100 years ago there will be an open community of professionals who work partially for free and create it all. And in result create these nice, pretty UI that work flawlessly and in a pretty cool way.

But also it is weird in bad way. And there are a lots of examples to prove it. And i will tell about some of these. Just to give the idea how it looks from a perspective.

We have this programming language, people love or hate. I actually rather like it. It is JavaScript. Everything is based on it. It is the core of frontend development currently. But it got a little crazy.

JS syntax sugar

For example you can compare variables with 2 equal signs. But also you can compare them with 3 equal signs. And it means different things. Don’t get me wrong, it is helpful and it has meaning. But do we really need two ways of comparing objects? Or maybe is it not enought? Maybe we should have also more strict ==== comparision? Where does this end? And who is to decide? Maybe it was good call or add more sugar way. But ok, maybe it has some sense. but lets look at another example.

Lets go to strings. You can declare a string with: “” or ‘’. But this was not enough because ES creators had to put also backtick to the pack for template strings: ``. And it is not easy on every device to type backticks. Also, although, it is great feature to have template strings, a question arises. Why add a new character no one uses to a programming language? Its very hard to distinguish between ‘’ and `` in a source code. Its hard to type, no one uses it. So why it was introduced?

There was no way to put templating into normal strings, because old would break in some instances. So choice was made. But it was not a right one. For example in lastest Python syntax is f’’ — and this is a perfection. We use a letter f that is a standard letter on every (kinda) keyboard. Cool idea Python creators! Very nice! But ECMAScript creators went the weird way here.

Those two examples show that JS has some syntactic sugar. It introduces a new, weird syntax elements from nowhere. There are more examples. They all show the syntax grows, and a combination of characters like: ` ‘ : . <> and you name it, have different meanings in different combinations. Just like in Mortal Combat. If you know what to type UP UP LEFT RIGHT KICK — you know how to make fatality. But its not so impressive like Mortal Combat. Do you know what “…” can be in JS? No, you can not guess it. You need to know it to use it. You see “…” in code and wonder… this is an unfinished story. But it is a spread syntax, and it is very useful and helpful, but it introduces a new “command” and a weird way to use it.Three dots? Come on! What will be next “.,.” for next “command”?

So if it was not clear from previous paragraphs i think the sugaring of JavaScript went nuts. And it is bad for beginners to learn, and for every programmer to follow this trend. And it will become harder and harder to understand and learn code if we will add so much syntax sugar into it.

TypeScript syntax sugar and syntax mess

We are talking about JavaScript, but this problem spreads into frameworks and libraries. There is this hidden concept that if we want something new, we add a new syntax for it. Forget all the language engeneering, in this age, we can make “…” do whatever we want. Examples? Lets look at TypeScript, it is based on JavaScript. And it should provide a new value for frontend, and it gives, but also follows two concepts in a bad way: backwards compatibility and adding new syntax.

So in JS you declare a variable with var. var x = 1. But var has a lots of problems. So what TS introduces? A new way to declare variable, but don’t touch “var” because “backwards compatibility”. Lets add a new name for the same task and name it “let”. Ok. We are kinda ready, but “let” does not work so good if we want to have strict type for a variable. Cool, lets use “const”. So now you declare all variables with “const”. const x = 1. Just to recall, almost every other language uses “var” to declare a variable. And it is strongly typed. But TS uses “const” for such type. Where… in almost all languages const is used for a variable that does not change value. Crazy! It is totally out of mind! You declare a variable… var is the shorthand for variable. Const is shorthand for constant. It can not get more bad that this.

Dont get me wrong here. I love TS and work in it. It gives a lots. But this shows a major design concept flaw in this language. Eventually every developer gets used to it. And surely TS will be used for years, because it is so awesome. But this does not explain why TS breaks linguistics!

One of TS biggest perks is strong typing. Lets look at other languages, how it is solved:

C#: int X = 1;

C++: int X = 1;

Java: int X = 1;

TS: let X: number = 1;

Ok, so we reserved the first word for let/const. So we need to put type somewhere else. Lets add :, and after this the type. Why? Why this have happend? Was there anyone in the design room who said it is crazy? Why “standard” way of defining strongly typed variable was not followed in TS? Did we really need more syntax for a rather common situation? I think not. And it makes again TypeScript kinda weird kid in the programming class.

There are a lot of more bad syntax decisions in TypeScript and i know, there were reasons for it. And these reasons, of any kind, it is based on the concept in a wrong way:

  1. we can make syntax more complicated
  2. we need to have backwards compatibility

Both concepts are essentially used in a evil way and it makes TS flawed.

Ember, Vue, Angular, React frameworks syntax mess

So lets look now on frameworks. I will just show you another examples of how such concepts rod frontend code.

Main feature of each frontend framework is providing one-way binding to a variable from template property (interpolation). This is a syntax for this issue in major frameworks:

Ember: src={{this.url}}

Vue: v-bind:src=”url”

Angular: src=”{{url}}”

React: src={url}

One thing i have issue with here is that every framework uses other syntax. Can’t you guys just agree on something? Second is that every syntax is just unnecessary. Why? I will explain. This is a example html tag:

<img src=”https:///….” class=”aclass” />

As you can see each attribute of a tag “img” has quoted value. And in 99% code in 99% examples it needs to be quoted! So, there is almost no example when attribute value is not quoted in HTML! So…? Here is a crazy idea? What if we used unquoted attribute as variable name? Like for example:

<img src=url class=”aclass” />


It would mean url is variable to fetch value from for src parameter! Get rid of {{ }}, v-bind: {} syntax. So here are some arguments against it, and i will explain my reasoning why these arguments are wrong:

  1. “It may break code” — it is not a problem, there needs to be a space after attribute equation end (or some other special chars). It is possible to parse. If someone didn’t type a space (or other special char), it is a wrong HTML code. Easy to recognize!
  2. “But JavaScript…” - who cares about JS. If we use a framework, it can take care of processing and translation. It kinda does it already!
  3. “We won’t know if this is one way binding or not” — 99% of time you use bindings if you write a project on a framework, so you have {{ }} {} 99% of the time. Exception is mostly class attribute! One class attribute. It is easy to recognize. {{ }} {} makes it actually worse to read the code since it is stuffed with this useless syntax.
  4. “What if we use 2 frameworks at once?” — nope, you don’t and you won’t
  5. “What about 1% exception”? Well.. i think we can invent a syntax for this 1% since we will remove syntax from 99% of cases.

So this is just one example from all major frameworks, where a behind the scenes assumption pops out:

  1. Add more syntax

No one uses 2 frameworks in the same time. We don’t write exceptional code (p.5) all the time. But these bad assumptions might have influcence syntax creators to add more syntax. The syntax gets more complicated and obscure for not a good reason.

So, to conclude it all. I showed you how JS adds syntax, TS does the same and frameworks also. I have showed you examples where more syntax is a remedy for problems in JS, TS and major frontend frameworks.

There are a lots, more complicated examples where syntax was added to JS, TS and frameworks. This is just a tip of syntaxberg! And there is a very good reason to point it out, not only as a mere observation:

Results of a concept of “add more syntax” as a remedy for every problem are:

  1. Beginners need to learn more syntax to start working
  2. Teachers have more problem with explaining syntax in a methodic way
  3. Code is harder to scan, read and understand
  4. New syntax does not give so much benefits
  5. There is no standarization
  6. “Fix it with more syntax” way is like a virus that digests whole frontend stack and spreads everywhere
  7. It will become worse and worse

So its really not a good idea to expand syntax too much is it?

Keep it simple syntax!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store