DEV Community

loading...

Explain the Frontend Webdev Ecosystem to Me

ben profile image Ben Halpern ・1 min read

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?

Discussion (23)

pic
Editor guide
Collapse
andrewbrown profile image
Andrew Brown πŸ‡¨πŸ‡¦ • Edited
  • 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.
Collapse
dinsmoredesign profile image
Derek D

That leftover pizza though... πŸ‘Œ

Collapse
ninetails profile image
Carlos Kazuo

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

Collapse
scott_yeatts profile image
Scott Yeatts

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

(Sorry, I had to 😁)

Collapse
andrewbrown profile image
Andrew Brown πŸ‡¨πŸ‡¦ • Edited

I haven't seen much of Stencil as of yet.

Thread Thread
scott_yeatts profile image
Scott Yeatts

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...
Stencil

Collapse
iamschulz profile image
I am Schulz • Edited

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

Collapse
sarneeh profile image
Jakub Sarnowski

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.

Collapse
iamschulz profile image
I am Schulz • Edited

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.

Thread Thread
sarneeh profile image
Jakub Sarnowski • Edited

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 :)

Collapse
yaser profile image
Yaser Al-Najjar

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.

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited

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?
Collapse
thebouv profile image
Anthony Bouvier

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.

Collapse
Sloan, the sloth mascot
Comment deleted
Collapse
evanplaice profile image
Evan Plaice

πŸ‘πŸ‘πŸ‘πŸ‘

This should be the landing page for vanillaes.com

Collapse
evanplaice profile image
Evan Plaice • Edited

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

Collapse
brihaspati profile image
Brihaspati Bharani • Edited

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.

Collapse
kaos profile image
Kai Oswald

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:

Collapse
jrop profile image
Jonathan Apodaca

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".

Collapse
jrop profile image
Jonathan Apodaca

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

Collapse
kspeakman profile image
Kasey Speakman

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.)

Collapse
codingmindfully profile image
Daragh Byrne

I found this helpful when I tried to get to grips with it:

frontendmasters.com/books/front-en...

Collapse
keevcodes profile image
Andrew McKeever

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