Framework Debunking

[Andres_Vaquero]

We get many situations at work where junior developers want to introduce frameworks to every project and there are plenty of situations where that may not be the best option for different reasons. Nonetheless it is hard to convince anyone that is not a seasoned developer that introducing a framework may not be the best option for a project, because these days they’re everywhere and all the junior devs are using them.
From a personal standpoint I don’t like frameworks, I like to code in raw JavaScript or PHP or start my styling from scratch… but I do undestand other people who feel more comfortable using frameworks, however how to make non technical people understand the cons of using them is something at which I have failed in the past and ended up frustrated and feeling misunderstood.

So in this post I aim to gather some knowledge with a little bit of your help on the pros and cons of using frameworks generally and specifically. Now because I’m not experienced in many of these frameworks some of the things I list might be wrong so please correct me if so and add to it if I missed something. I will be updating this post with any good additions or corrections you can come up with and any other thing I might have missed.

Many thanks for your collaboration.

General
- Pros :
1. Junior devs can get up to speed fast
2. Online documentation and community
- Cons :
1. Licensing
2. Technical debt and more dependency
3. Short life span or incompatible upgrades

Bootstrap
- Pros:
1. Saves time styling
2. Handy grid system
- Cons:
1. Bad for custom designs that do not look like Bootstrap as it will introduce a lot of clutter

jQuery
- Pros :
1. Event standarisation
2. Handy dom node selectors (no longer relevant since querySelector and querySelectorAll)
- Cons :
1. Too many redundant methods
2. Developers learn the language abstraction instead of the language itself

Require.js
- Pros :
1. easily require dependencies
- Cons :
1. easily solved by propper app initialization or a php script
2. too much redundancy in the code

React.js
- Pros:
1. Component architecture
2. Fast rendering
3. Works well with other libraries/frameworks
- Cons:
1. Just the view layer
2. Ties code to html structures and promotes technical debt
3. Hard to deal with forms because of non-mutable input states
4. Dodgy terms and conditions (https://medium.com/bits-and-pixels/a-compelling-reason-not-to-use-reactjs-beac24402f7b#.yple4sfpi)

ES6 (I know this is not a framework but seems to be a new buzzword so decided to add it)
- Pros:
1. Introduces a lot of new cool features
- Cons:
1. Introduces too much dependency at the moment (Babel)
2. ES5 is very powerful but misunderstood
3. ES6 obscures the real prototypal nature of JavaScript

[mawburn]

Frameworks are built so many developers can work on a single project and if you’re hit by a bus, then someone will at least have a basic understanding of what’s going on. Having worked on projects with and without frameworks, you should listen to the Junior Developers.

In-House frameworks are the devil. There is no way to Google how Andres_Vaquero did something. There is nobody to help someone out if they get stuck. It’s just you and if something breaks and you don’t have time to help someone, you’re out, or whatever else, then they are up the creek without a paddle.

If you follow the standards set forth by the framework, don’t go trying to override things that probably don’t need to be overridden, then someone should be able to do some training courses, pick up your app and be effective almost immediately. Not only that, but if you chose a good framework there you will spend much more time actually developing production code, instead of building up a foundation or adding in major parts of the foundation that the last guy forgot.

^{Since your post is most geared towards frontend stuff, then I should mention that if your entire codebase is under a few hundred lines, then it’s perfectly ok to not use a framework. But if you have a large complex frontend app (or backend), or god forbid an SPA, I just hope it’s a personal project and you will be the only one to ever work on it.}

Bootstrap
Bad for custom designs that do not look like Bootstrap as it will introduce a lot of clutter

It is not hard to customize at all if you take a few minutes and look at how the source it put together. If you want to compile it yourself, like we do, then their _variables.scss is fantastic and incredibly clear. You usually don’t even have to look at the documentation or where it’s defined. If you need to override any specific piece of it, it’s very easy to find in their location in the source to see what the classes are actually doing.

If you want a true custom design, it adds very little to base DOM elements. So, just add your own CSS on top of it.

Bootstrap adds a good foundation of styles and structure to build off of. However, unlike the rest of the stack, I don’t think it’s a big deal if you want to roll all your own CSS.

jQuery

jQuery was fantastic when every browser said “who does ECMA and W3C think they are anyway?” and did their own thing, had their own bugs, and had their own quarks. If you’re supporting IE8 and below and trying to do anything resembling a rich web application, I guarantee it is completely riddled with bugs that nobody tells you about and probably doesn’t work on at least 1 other browser at all.

The way I used to describe it was that jQuery made JavaScript not suck.

But if you’re supporting only modern browsers, then I don’t believe it should be in your stack.

Require.js

1. easily solved by propper app initialization or a php script

Require.js itself isn’t really a thing much anymore. But I had to comment on this. Nobody wants to use your homerolled dependency manager. The only thing worse than someone who wants to roll their own framework, is someone who wants to write or override dependency managers. Don’t do it.

React
Just the view layer

It’s not really just a view layer. It is a total paradigm shift, and the best way to describe it to people coming from an MVC world is that it’s a view layer.

Ties code to html structures

If you’re building something from components, this is a good thing. Components should only do one thing and do it well. By tying small chunks of HTML inside the individual components, you’re able to see what the component does more easily, which allows for better customization, greater optimization, and less redundancy.

There is are good reasons why every framework to come after React has moved to this style, including a total shift to it in Angular 2.

and promotes technical debt

It does almost nothing for technical debt. React is very barebones and encourages good modular design, standardized JavaScript, and functional concepts.

If you’re referring to JSX is incredibly simplistic and I’ve never known anyone to not pick it up right away. There’s a few gotchas, but far less than any thing like it I’ve worked with before. It’s just a simple template language.

Hard to deal with forms because of non-mutable input states

I haven’t run into any issues with forms in recent releases of React.

ES6
Introduces too much dependency at the moment (Babel)

That’s just one tool and not really a dependency since it’s just compiles your code. But if you’re using ES6, you’re probably going want to use CommonJS and that means either webpack or browserfy. Both are fairly simple to setup.

ES5 is very powerful but misunderstood

Nobody really misunderstands it. ES6 just does a ton of things easier, better, and simpler. It’s a massive improvement, the same way ES5 was a massive improvement over 3.

ES6 obscures the real prototypal nature of JavaScript

Absolutely nothing wrong with this at all.

If you don’t like it, then you’re not forced to use it and still rake in all the other benefits of ES6+.

[Andres_Vaquero]

@mawburn

If you’re building something from components, this is a good thing. Components should only do one thing and do it well. By tying small chunks of HTML inside the individual components, you’re able to see what the component does more easily, which allows for better customization, greater optimization, and less redundancy.

I have to disagree with this. I use component architecture as well but with dependency injection on dom nodes, sometimes if these are not provided they’re created by the component. This way allows my components for much more flexibility and to work for multiple different scenarios. The technical debt I was referring to has to do with having a predefined set in stone html structure defined along with your JavaScript.

Thanks a lot for your long answer. I guess pros and cons really depend also on weather you’re developing an enterprise product you may resell, or just a small client’s website…

[mawburn]

This way allows my components for much more flexibility and to work for multiple different scenarios.

With React, it’s good practice to build components out of components. Where the base component is as simple as possible, then work your way up to the application. Similar to how OOP classes should work.

That way, no rigid structure is forced upon the developer, unless that’s what you intended.

Thanks a lot for your long answer. I guess pros and cons really depend also on weather you’re developing an enterprise product you may resell, or just a small client’s website…

Yeah, it’s a bit of a touchy subject for me. My last job had some developers who were adamantly against frameworks, which made working on the 20yr old codebase an absolute nightmare. Especially when there were hidden, undocumented things, that would override standard things (like dependency managers) and the only way to know something was overriding it was to ask someone else why it broke.

[Andres_Vaquero]

@mawburn

With React, it’s good practice to build components out of components. Where the base component is as simple as possible, then work your way up to the application. Similar to how OOP classes should work.

That way, no rigid structure is forced upon the developer, unless that’s what you intended.

I do have a small script to apply classical inheritance into prototypes, which I guess is similar to the way React component inheritance behaves… Anyway let’s say I have a component that applies certain functionality to an input text field… I can have that component create the input element. In a React way this input would be declared as HTML inside of the component. In a pure JavaScript way we would create a dom node with document.createElement (which would be the fastest way of all). But what if that input text dom node already exists in the document? Well in the way I do things my components would be able to receive an already existing dom node (even as a string selector) and act accordingly. If no dom node reference had been provided the component would create the node for you. I just still miss to see the advantage of having embedded html inside your JavaScripts. It takes more time to generate while being parsed too and might be a no go for large and complex apps. If I have to create an element I’ll use document.createElement and already hold a reference to the node in my application, which simplifies things a lot.

@mawburn

Yeah, it’s a bit of a touchy subject for me. My last job had some developers who were adamantly against frameworks, which made working on the 20yr old codebase an absolute nightmare. Especially when there were hidden, undocumented things, that would override standard things (like dependency managers) and the only way to know something was overriding it was to ask someone else why it broke.

Yes it is a touchy subject indeed… but there is definitely a lot to learn from it. As developers we do hate having to fix third party undocumented code… sometimes though business priorities can have a different say. I believe a big reason not to use 3rd party frameworks would be licensing issues on enterprise products you want to resell. Using a framework might decrease a lot the value of your product. So if you’re working on the next big thing… it’s probably a safe bet to stay away from them.

[mawburn]

React is incredibly fast at rendering, because it’s managing it’s own DOM and optimizing accordingly. It’s so fast, that it’s actually constantly redrawing the page.

https://cardlife.blog/what-is-virtual-dom-c0ec6d6a925c#.xi94528un

This can cause some weirdness if you’re not careful, especially in lists because it will reuse elements with the same key. But that was probably my fault for not reading the documentation thoroughly and not giving unique keys. I’ve ran into a couple other gotchas with it so far, but not too many.

I’ve done my own testing with it. A couple years ago, I wrote the same app that allowed sorting, updates, and deletes to a list of just under 6000 rows of real data. I wrote it using my own createElementNode, Angular 1, and React. React blew both of the other methods out of the water. Both of the others were looking at a 1-3 second render time, but React was under half a second. Interacting with the list felt much snappier too. The code was far more consise and easier to manage and make sense of.

I just still miss to see the advantage of having embedded html inside your JavaScripts. It takes more time to generate while being parsed too and might be a no go for large and complex apps.

It’s designed for large complex apps. Since everything is built on components that are built on components, if you have a good library of components built up for your app, then the final app that renders to the page is very simple and is only concerned with structure.

It allows a strong separation of concerns. Say you need to update something like an Email input field. You go find that one component and everything concerned with allowing a user to input an Email, like validation or whatever else, is all right there in the same 20-50 line file instead of being buried deep within several other files. Then you make your change, commit, and it is able to be merged back into the original codebase without requiring someone else to deal with conflicts. Then the component is updated and everyone else using <EmailInput /> gets new updated functionality without caring anything changed to make it better. The HTML in the component itself is maybe a couple lines.

HTML isn’t important enough to require it’s own file if you’re building things this way, it is simply the semantic structure of how the document element is defined. The final view in a React app should have very little actual HTML anyway. It should be almost entirely composed of smaller components like <EmailInput /> and the likes.

[Andres_Vaquero]

Hey found this interesting article which kind of exposes a different view. Wonder why he’s getting low performance. Maybe his specific test case… Interesting nonetheless… https://objectpartners.com/2015/11/19/comparing-react-js-performance-vs-native-dom/

Cheers…

[mawburn]

In my test I just vomited out ~6000 rows and it was fine.

Either way, it’s not hard to cherry pick random blogs from the internet showing one result over another. At the end of the day, it is built to render as fast as possible while maintaining a logical structure for large apps, and combined with Redux, a very understandable data and event flow that doesn’t lead to a mess of spaghetti code.

You can optimize for your real world use case. Ember is one of the lowest performing major JS frameworks out there, but Jeff Atwood and his team have created a great experience here on Discourse.

React are really pumping up their huge performance gains with their new rendering algorithm in React Fiber (React 16).

React.js Conf 2016: http://www.youtube.com/playlist?list=PLb0IAmt7-GS0M8Q95RIc2lOM6nc77q1IY

[Andres_Vaquero]

@mawburn

it is built to render as fast as possible

Seems though at quite a higher CPU cost

@mawburn

while maintaining a logical structure for large apps

@mawburn

a very understandable data and event flow that doesn’t lead to a mess of spaghetti code

Yeah but no need for a library to achieve this.

Tradeoffs in the long run might be too big in my opinion, it’s quite a big of an abstraction. I still think web components are the way forward and web technology is advancing very fast and will tackle the issue of fast rendering sooner or later

[mawburn]

Yeah but no need for a library to achieve this.

Sure there is for a professional project where multiple people will be working on it. Especially in JavaScript where there are at least 15 different ways to build out an OOP-like structure. If you pick a framework with decent documentation and community support, someone can maintain your application for a very long time.