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?
That leftover pizza though... 👌
Svelte is when mommy packs a lot of snack bars and call it your nutritional balanced meal
Stencil is that better lunch, but you actually want to eat it 🤣
(Sorry, I had to 😁)
I haven't seen much of Stencil as of yet.
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
ELI5, pure basics:
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
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.
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:
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?
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.
👏👏👏👏
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
nutshellsausage.tl:dr; Yo dawg, I heard you like sausage
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.)
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.
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:
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?
Any other conversation has to do with libraries/frameworks.
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.
I found this helpful when I tried to get to grips with it:
frontendmasters.com/books/front-en...
Popularity of frontend frameworks has given way to demand learn paradigms like functional programming even more than before.