DEV Community

Cover image for The Layers of Javascript
Laurie
Laurie

Posted on • Edited on

The Layers of Javascript

Recently I was writing up a lesson plan to teach a small group about data display in Gatsby. My goal was to break down the topics and have an answer to all of the low level questions that participants might ask. In the process of doing this I noticed that the ecosystem of javascript has a ton of layers! Figuring out what technology is in charge of each feature is incredibly helpful for debugging and growing your knowledge. So without further ado, I give you the layers of javascript!

Javascript...or is that ECMAScript? ES6? What's going on?!?!

Javascript is your base language. However, it's based on ECMAScript which is a standard for scripting languages. ECMAScript has versions, just like programming languages. Understanding what happens when the ECMAScript specification changes is important.

In a way, ECMAScript is there to tell you what Javascript could do. What it actually does is up to the Javascript engine that's interpreting it. Javascript engines exist in browsers. Browsers need to support the standard in order for you to use the new features.

At present, the ECMAScript version that is widely supported is ES6. ES6 marked major changes in the standard, introducing concepts like let and const.

character.map(function ( [first, last] ) {
    return first + last
});
Enter fullscreen mode Exit fullscreen mode

Destructuring assignment is one of the things introduced in ES6

Understanding ECMAScript's place in the Javascript ecosystem is especially helpful if you're looking to use newly introduced features.

Node -v is my Javascript version, isn't it?

One of the more confusing aspects of front end development has to do with Node. When you're developing locally you likely have a version of Node your computer points to. Node is actually bundled to include two different things. Node.js runtime and npm package manager. As a result, you may be using one, both, or neither.

You can use npm to install external project dependencies. That does not necessarily mean you're using Node.js runtime.

As mentioned before, Javascript is interpreted by the browser. Node.js runtime is a combination of an interpreter and environment that allows you to use Javascript as a general purpose programming language, i.e. outside of the browser. It's actually based on the Javascript interpreter Chrome uses. However, that means if you're building something like a React application, Node.js runtime is not having any affect. What you're really interested in is how different browsers are able to interpret your code.

JSX

So there are layers to the way your code is interpreted and what features are supported. However, that's just one of the ways the actual syntax of your code can be influenced. One of the complexities of modern Javascript is that core frameworks are in use. React is a particularly popular framework. Within React you have the ability to use JSX. JSX is a Javascript syntax which allows you to use HTML tags directly in your React components. This means you're using a combination of the Javascript language and the markup you'd expect to see with an HTML file.

const IndexPage = () => (
    <Layout>
        <div>Your code is going to go here!</div>
    </Layout>
)
Enter fullscreen mode Exit fullscreen mode

JSX has different syntax rules and features than the Javascript language. Expectations about function scope parentheses vs. brackets may seem unfamiliar. Recognizing that this is a rule that JSX enforces will help remind you why it's clashing with your Javascript knowledge.

Frameworks

Another layer of your Javascript are features that are available specifically because of the framework you're using. For example, in React you may deal with passing props. Props is a concept of the framework.

function Introduction(props) {
  return <h1>Welcome, {props.name}</h1>
}
Enter fullscreen mode Exit fullscreen mode

Frameworks...on frameworks?!?!

One of the complexities of modern Javascript is that core frameworks are in use...sound familiar? That means that you have frameworks, like Gatsby, that are based on React. Understanding what Gatsby is doing versus features provided by React can be a challenge. While this is unlikely to affect your syntax it will affect your behavior in various situations. For example, Gatsby passes the result of a GraphQL query directly to your component props. Try doing that in React and you'll wonder where you went wrong.

Wow

Writing a Javascript application can be amazingly easy to set up with all the tools out there. However, when you get into more sophisticated features and dig into the code a bit more it's easy to get lost. Knowing what layer of the stack is giving you problems, or may provide an easier solution, is incredibly helpful.

Top comments (13)

Collapse
 
forsureitsme profile image
Pedro Cardoso da Silva

We trying to explain nowadays javascript tooling

Me trying to explain meme

Collapse
 
maxwell_dev profile image
Max Antonucci

This definitely helps illustrate how JavaScript is like a seven-layer cake which may add extra layers in the middle when you're coding. Keeping track of them is never easy, but this post definitely helps in starting to clear it all up!

Collapse
 
theelectricdave profile image
David S. • Edited

It doesn't have to be this way, but it seems like the trend of web developers making their lives harder by stacking as many abstractions and dependencies as possible on top of each other will continue until this comes to a head.

I have seen so many projects destroyed by relying too heavily on other people's code, when the square cannot be jammed into the circle..

The JS ecosystem seems a lot more insane than the PHP ecosystem i work with.. i cannot imagine learning a new framework every year.

Collapse
 
desolosubhumus profile image
Desolo Sub Humus 🌎🌍

This is why I use VanillaJS for everything, personally. It can be frustrating at times, but not as frustrating as dealing with my own JS AND other people's frameworks and libraries, especially when the commenting in them may be confusing or non-existent.

I genuinely feel bad for anyone forced to use dependencies because of their boss's preferences.

Collapse
 
laurieontech profile image
Laurie

There are a lot of good reasons for dependencies. Oftentimes rolling your own isn't the right solution. There are plenty of merits in frameworks as well. It's all about picking the right tools for the job.

Thread Thread
 
desolosubhumus profile image
Desolo Sub Humus 🌎🌍

Perhaps, but all too often I'll see some nonsense on Stack Overflow or Medium where someone asks 'how do I do x in JS?', a simple two line VanillaJS answer that would work gets posted by someone else, and a hoard of others come in to bash the VanillaJS answer because they feel 'you should have used jQuery to make it one line and it should do y'.

I'm referring more to the obsession with forcing employees to do everything with the bosses' favorite libraries and frameworks purely because the bosses feel VanillaJS solutions are icky and only for stupid people who write their own code.

On top of that, if a framework or library is updated and part of your code breaks because your dependencies work differently now, it's frustrating to have to go back and figure out what the change is, why, how the new way works, how to fix your own code, and hope it doesn't break again. It's much less frustrating over time to write valid, working code that relies on nothing but your own work.

So, absolutely, the right tools for the right job. Sadly, it's more often the trendy tools for every job, because it's trendy.

Thread Thread
 
laurieontech profile image
Laurie

Definitely, all about tradeoffs.

Collapse
 
matthew_collison profile image
Matthew Collison

Some find the layers to be in a cake... Pretty and tasteful 🌈

Others find it like the layers of an onion... It makes them cry as they go deeper 😢

😂 Honestly though, the state of JS and its' many layers is super intimidating to newbies. We think this breaks it down really well. Great job 👍

Collapse
 
avatarkaleb profile image
Kaleb M

The challenge even continues when you're trying to use them all together :), determining which features work with different versions, how JSX can interpret your JS version, webpack and babel configurations to set up builds, the madness continues :D

Collapse
 
ssimontis profile image
Scott Simontis

I'd encourage you to dig into how modern JS interpreters work (they aren't really interpreters at all anymore!) I feel like it has helped me conceptualize how code runs on a whole new level and I gained a ton of respect for where the ecosystem is today. There's a book in the .NET world called CLR Through C# which explains in extreme detail all the inner-workings of the .NET runtime and it pushed me to become a better coder more than any other book has. Unfortunately, I am not sure how relevant it is now that we have .NET Core, but it's still pretty mind-boggling the amount of thought that goes into every aspect of a programming language and how much we have left to learn.

Collapse
 
rohovdmytro profile image
Rohov Dmytro

Knowing what layer of the stack is giving you problems, or may provide an easier solution, is incredibly helpful.

That why we can see a lot of effort people putting into error messages.

Collapse
 
daveskull81 profile image
dAVE Inden

Great post. The JavaScript world has a ton to offer which is great, but it can also be daunting to someone getting started. This does a great job of breaking things down.

Collapse
 
jacobmgevans profile image
Jacob Evans

"Frameworks...on frameworks?!?!" this had me rolling! Great article.