Explain the Frontend Webdev Ecosystem to Me

twitter logo github logo ・1 min read

Explain JavaScript (5 Part Series)

1) Explain React to Me 2) Explain Vue to Me 3) Explain Angular to Me 4) Explain the Frontend Webdev Ecosystem to Me 5) Explain the State of WebAssembly to Me

Hey folks, I was hoping in this latest edition of this series, some folks could weigh in on the rest of the frontend JavaScript ecosystem. I think we've covered the big three, but what is the rest of the landscape.

What are the big topics and concepts in frontend these days?

twitter logo DISCUSS (23)
markdown guide
  • Angular - When mommy packs you a Lunchable for lunch
  • React - When mommy packs you lunch but forgets the pudding
  • VueJS - When mommy packs you leftover pizza for lunch
  • Mithril - When mommy packs you multiple Nutrigen bars for lunch
  • Svelte - When mommy packs what she calls a "better lunch" but you don't eat it because you just want what you're used to eating.

Stencil is that better lunch, but you actually want to eat it 🀣

(Sorry, I had to 😁)


It's in the same space as Svelte, but Typescript native and compiles into spec-compliant web-components by default.

Been using it since Beta without a framework (or using stencil as the "framework") and it's been pretty amazing. It feels more like I'm writing Vanilla JS with Typescript support.

It supports the major frameworks too... I just got tired of chasing the upgrade cycle.

I can have beta components I built a year ago sitting on the same page with 1.x components from today, and if the old component ain't broke, I don't have to mess with it. I just upgrade when I need it.

I have pretty much everything I need from a framework, but I don't pass any "framework" code to the users, just the compiled vanilla WC.

Built by the Ionic team and they built Ionic V4 with it (but ionic isn't required for it) and I know Apple used it for the new Apple music, and (anecdotally, through friends) a few other large companies are evaluating it...


Svelte is when mommy packs a lot of snack bars and call it your nutritional balanced meal


ELI5, pure basics:

  • there's HTML, which structures a document
  • there's CSS, which styles a document
  • there's JS, which adds functionality to a document

  • Vue, Angular and React are Javascript frameworks that help you creating web apps more easliy. You don't differentiate between HTML and JS here anymore, so it feels like some kind of magical HTML on steroids.

  • Typescript is a form of Javascript that has your grammar teacher looking over your shoulder

  • npm is a big bucket with all the code snippets that people smarter than you have made. feel free to use them, but only take whats necessary!

  • Sass/Less/PostCSS let you organize your CSS, so you can stay sane in large, complicated projects

  • Babel takes your fancy, modern JS and transforms it into old-time-standard JS, that even your uncle's browser (the one with the blue letter e and five toolbars) can understand.

  • Webpack takes all your code and wraps it up into a ready-to-deploy website.

  • Jest makes sure that your code snippets work fine one by one

  • Cypress makes sure that your code snippets play nice together

  • Lighthouse makes sure that you didn't accidentally write too much code


Lighthouse makes sure that you didn't accidentally write too much code

I think that more often you need to write more code to improve your app performance, thus improving the Lighthouse score.


You do when writing on top of other code that already hurt your a11y and perf scores.
Build from scratch with semantic HTML, WAI-ARIA and progressive enhancement in mind and you'll be fine.
The tools we work with right now, like node packages and frameworks for everything just don't encourage that style of working. In all our tooling confusion, some people forget that websites are performant and accessible by default.

You do when writing on top of other code that already hurt your a11y and perf scores.

Agreed! I was actually thinking about this specific scenario. My bad, I didn't describe my argument properly :)


Overtime, developers had real struggle with many processes like:

  • Adding/updating/deleting libraries.
  • Fallback to support old browsers.
  • Bundling multiple files into production-ready files.
  • Running tasks automatically.

That's when we saw stuff like NPM, Babel, WebPack, and Grunt.

Not just that... part of the tools that we took for granted came from similar struggles, such as browser dev tools.


That's a nice way to put it.

What are the main struggles that the other parts of the webdev ecosystem are trying to solve?

  • "JavaScript 1.0 had a lot of rough edges" => ecmascript
  • "simple typos mistakes are causing annoying runtime exceptions" => Typescript
  • "I want to use my webdev skills on other platforms while still accessing native features" => electron, react native
  • ... What else?

Imagine a box full of leftover HDMI, USB, power cords, and that one random LPT or serial (you can't remember) all tangled together. You know you have this box or had one till you finally said "eff it" and purged it. But you know what I'm talking about.

Now imagine the same thing, but it is snakes tangled together instead of cables.

Now imagine the same thing, but it is your leftover xmas lights, some of which you still have even though that one bulb is broken making part the lights not work.

Now imagine they're all in the same box actually. And you have a machine that makes these boxes on demand. Your own little cord-snake-lights-in-a-box factory. It's even nice enough to put a bow on the box for you.

Now slap a label on the box that says "reactive". You don't know why, but just do it.

There is the current front end development landscape.


ES is a radical, new platform for building dynamic web apps.

  1. Performant - Built-in to the browser weighing in at an astonishing 0 KB.
  2. Streamlined - Write less code with higher-order functions such as map, reduce, and filter.
  3. Flexible - Freedom to mix and match any programming paradigm of your choice. Pick any tooling to run tests and build tasks.
  4. Drop-In - No assumptions about your technology stack. We fit right in with the rest of your JavaScript code.
  5. Server-Side - You can use ES on the server-side using Node.
  6. Async Fetch - Our new asynchronous data fetching feature called "Grabber" allows you to make simultaneous requests with built-in Promise chain. Compatible with our intra-state fetch display system called "Cliff-Hanger."
  7. Organize - Built-in module system allows for code organization and structure.
  8. Compatibility - Works with all modern web browsers across multiple devices and platforms.
  9. Templates - Templating building blocks using template literals. Combine with our module capabilities to create reusable components.
  10. Carpal-Tunnel Friendly - With features like Destructuring, Spread Operators, Object Literals, Arrow Functions, and more, we promise to save precious keystrokes and a reduction in physical pain.
  11. To Hell and Back - Our extended support for Promises releases you from the depths of Callback Hell.
  12. Standards Compliant - We are 100% compliant with the standards set forth by ECMA.

Start today! Clicks on Get Started button



This should be the landing page for vanillaes.com


Imagine you have a pile of meat and prepared small intestine

You grind up the meat, feed it into the intestines, twist it up, and voila. You have sausage.

But sausage isn't reactive enough. So you grind up the sausage into a pile of sausage+meat amalgam and use it to make new -- slightly different -- sausage.

Et voilΓ , 'modern' FrontEnd web development in a nutshell sausage.

tl:dr; Yo dawg, I heard you like sausage


I'm surprised, that webassembly (Wasm) has not been mentioned yet.

Wasm is designed to be compiled from higher-level languages that can run the client code, therefore replacing the need of JavaScript.
This allows client-side applications writting in languages such as C#, Python or Java.
Interesting to know is that Wasm is already shipped and supported by all major browsers.

A few interesting tech specific links:


Here is the problem in front end that I have seen in last 5-6 years, especially in React ecosystem. I am saying this after writing good amount of code in these libraries/frameworks. This is not a biased opinion, but an honest observation.

In my opinion all the front end libraries/frameworks, its all pretty much same in terms of concepts like routing, state management, type safety etc.
Angular 2+ was well written especially for large applications in mind. What Angular did few years ago is what React/Vue is doing in last one year or so.

Type safety: Let's take static typing for example, Everyone wants type safety now(both in React and Vue) which Angular had built in. Again in React, there is Flow/Typescript

State Management: when it comes to state management, React ecosystem is not good to be honest. There is so much discussion around Flux/Redux, thunks, sagas, observables and lot many other middlewares. It's not so intimidating when someone starts to write React code with small components, but then when it starts to grow big, it's very likely that they will feel frustrated. Angular and Vue is much better when it comes to state management, reason being Angular has observables built in and there is only ngrx store to learn. Although there is a fair bit of learning curve in the beginning, once it's crossed, one doesn't need to worry about 10 other libraries/middlewares to make a decision. Vuejs has vuex which is quite simple and easy to work with and its by far the most easy thing to work with in my opinion.

Routing : This is pretty much same except that in React one can do dynamic routing easily. Its not very complicated when it comes to React which is a bit of a relief when compared to everything else.

Functional programming : React tries/trying to move towards functional programming more these days with the advent of hooks etc which angular doesn't by default having components as classes. But except the components, it doesn't stop the developers from writing more functional code for application logic.

Build size : Angular was bad when it comes to build size, but with Angular 8, it should be little better. Vue/React are better when it comes to build size. But when we start adding lot of third party libraries, it adds lot of burden on the developers to go into the minute details of JS and start working on code splitting, tree shaking etc. This definitely makes one a better JS developer, no doubt in that. But at the same time, the time spent in doing that is not worth in all cases.

In my opinion, writing React code is good especially in a smaller projects. But when we need more batteries, things can get very dirty soon. Also there is so much of new apis, new ways of doing things all the time. This definitely needs lot of time investment. Writing Vuejs was the best among three major frameworks to be honest considering its simplicity. But if its moving towards the way of React, I would say it would be bad. Lastly Angular is not all bad. It's definitely suitable for enterprise/large applications when the team working on it is big.

In the end, if we are spending lot of time deciding flux/redux, class/hooks, thunks, sagas, flow/typescript, its definitely eating fair amount of time one could rather invest in writing application logic or adding more features to the product. It's not always necessarily revolve around developer experience, organisations need to benefit.


It is easiest to see the need for a lot of things when you start with the realization that JS had no built-in module system for a long time. When NodeJS came along (server-side JS), it adopted CommonJS as the module system, and NPM (third-party packages) was born out of this. The front-end still lacked a tried-and-true module system, unless JS passed through a build step. To complicate issues, only newer browsers support the latest version of JavaScript, so there was a need to compile new JS => compatible old JS. So where does that leave us?

  • NPM => package manager
  • BabelJS/CoffeeScript/PureScript/ReasonML/TypeScript => Compile some newer language to ECMAScript5
  • Webpack/Browserify => a build step that bundles all the JS + NPM packages into one bundle (it can do code-splitting, too). Webpack can do one better and bundle other things inside the bundles it produces, like processed CSS, images, etc.

Any other conversation has to do with libraries/frameworks.

  • React => simply a view library: no batteries included. It offers the most flexibility
  • Vue => somewhere between React/Angular
  • Angular => a full MVC framework for frontend JS/SPAs (no backend)

There are a gazillion libraries that are capable of running on the server-side, or in a browser: these are called "isomorphic".


Reading through my comment post-mortem, I feel that I should disclaim that this is a vast simplification of JavaScript's history.


MVU style apps as introduced by Elm. I use F# Elmish now. This is my favorite way to make front-end apps. I have found it very maintainable after multiple years in production, unlike every framework I ever tried. (They start out really good, but eventually becomes too much messing with framework abstractions instead of my own code.)


Popularity of frontend frameworks has given way to demand learn paradigms like functional programming even more than before.

Classic DEV Post from Jun 15

What are your favourite resources for beginners?

What resources would you give a new team member who is also starting their first tech job?

Ben Halpern profile image
A Canadian software developer who thinks he’s funny. He/Him.

DEV is where senior developers are built

Sign up (for free)