14 minute read

Front-end Frameworks: Solutions or Bloated Problems?

Juan has 10+ years of freelance UX experience. His work is rooted in perfectionism & providing the best experience to user.
Read the Spanishes version of this article translated by Yesica Danderfer

Modern front-end frameworks require you to download a development environment, complete with dependencies, and compile your code before even trying to view it on your browser. Is this a good thing? Is the problem that we are building more complex sites, or is it that the frameworks are complex in their own right, introducing an unnecessary level of complexity? Are front-end frameworks a quick solution or a bloated problem

Web development today has evolved a lot since the ’90s; we are able to create entire experiences that are very near what any native application can do, and the development process has also changed. Gone are the days when being a front-end web developer was a matter of opening Notepad, typing a few lines of code, checking it on the browser, and uploading it to an FTP folder.

The Front-end Web Development of the Past

I must start by stating the obvious: The world isn’t like it was 10 years ago. (Shocking, I know.) The only thing that remains constant is change. Back in the day, we had very few browsers, but there were a lot of compatibility issues. Today, you don’t see things like “best viewed on Chrome 43.4.1” much, but back then, it was pretty common. We have more browsers now, but fewer compatibility issues. Why? Because of jQuery. jQuery satisfied the need to have a standard, common library that allowed you to write JavaScript code that manipulates the DOM without needing to worry about how it was going to run on each browser and on each version of each browser—a true nightmare in the 2000s.

Modern browsers can manipulate the DOM as a standard, so the need for such a library has diminished greatly in recent years. jQuery isn’t needed anymore, but we can still find a number of extremely useful plugins that depend on it. In other words, web frameworks may not be necessary, but they are still useful enough to be popular and widely used. This is a trait common to most of the popular web frameworks out there, from React, Angular, Vue, and Ember to style and formatting models like Bootstrap.

Why People Use Frameworks

In web development as in life, having a quick solution is always handy. Have you ever done a router before in JavaScript? Why go through the painful process of learning when you can npm-install a front-end framework to overcome the issue? Time is a luxury when the client wants things done yesterday or you inherit code from another developer designed for a particular framework, or if you are integrating with a team already using a given framework. Let’s face it—frameworks do exist for a reason. If there were no benefits to them, nobody would be using them.

So what are some of the benefits and unique properties of using a web development framework?

Time is money. When you are developing a project and the client doesn’t care which framework you use—indeed, probably isn’t even aware of what you use—they only care about getting results, and the faster the better. Established frameworks let you create an instant sense of progress from the beginning, which the client craves from day 1. Additionally, the faster you develop, the more money you make, since the time freed up by the framework can be redirected to taking on more projects.

It’s all about the community. When choosing a framework, this is a very important point—who is going to help you when you get stuck on an issue? You and I both know that it’s going to happen at some point. You’ll reach a spot where you need to do something that the framework wasn’t intended to do, or that the framework was never designed to give you access to, so having a community supporting you is essential. Development—especially freelance—can be hard, as you are immersed in a virtual world, and if you’re the sole front-end web developer in a team, it means you’re the only one with the experience and expertise to find a solution. But if the front-end framework you use has solid support, there is going to be someone on the other side of the world who has faced the same problem and might be able to help you.

Standards are beautiful. Have you ever noticed that, when you look into an old piece of your own code, you can navigate through it pretty easily? Or at least, more easily than a piece of code written by someone else? You think in a certain way, and you have your own way of naming things and organizing the code. That’s a standard. We all follow them, even if they’re only for ourselves. We tend to eat similar things for breakfast, wake up at a certain hour, and place our keys in the same place every day. And indeed, if we changed up our routines every day, life would be a lot harder just from the overhead of figuring out how to do stuff. Ever lost your keys because you put them in a different place than normal? Standards make life easier. When working as part of a team or a community of developers, they become absolutely indispensible.

Frameworks provide a standard from the moment you install them, guiding you to think and to code in a specific way. You don’t need to spend time creating a standard with your team; you can just follow how things are done in the framework. This makes it easier to work tgether. It’s easier to look for a function when you know that the function must be in a certain file because it is built for adding a route in an SPA, and in your framework, all routes are placed in a file with that name. People with different skill levels can work together if you have this level of standardization, because while the advanced coders know why things are done that way, even junior developers can follow the standard itself.

When Frameworks Fail

A few years ago, saying something like “I don’t use frameworks—I don’t see any real benefit from them” would bring people with torches and pitchforks to your door. But today, more and more people are asking themselves, “Why should I use a framework at all? Do I really need them? Is it that hard to code without them?”

I’m certainly one of them—I’ve never been a fan of any specific framework, and I’ve been coding without them for my entire career. If I have a choice in the matter, my choice is always, “No, thanks.” I’ve been developing in JavaScript for years and in ActionScript before that. I was coding in Flash when most people already considered it dead. (I know, I know… but I was doing lots of animations, and animation in plain HTML is hard.) So if you’re one of the many who never think about coding without frameworks, let me show you some reasons why you might be struggling.

“One size fits all” is a lie. Could you imagine writing a single piece of software that can do everything you’ve accomplished in your career? That’s one of the main problems with web development frameworks. Your project has very specific needs, which we tend to solve by adding libraries, plugins, or add-ons to extend the framework’s scope. No framework offers 100% of what you need, and no framework is 100% composed of things that you’re going to find useful.

Having too much code that you don’t use can result in load time lag for your site, which becomes more important with each additional user. Another issue is that the “one size fits all” mindset results in inefficient code. Take, for example, $(‘sku-product').html('SKU 909090');, which is jQuery code that, in the end, we all know is going to be translated into something like document.getElementById('sku-product').innerHTML = 'SKU 909090';.

That kind of difference on a single line might seem unimportant, but changing the content of a specific element of the page is precisely the virtue of React. Now, React goes through the process of creating a representation of the DOM and analyzing the differences in what you try to render. Wouldn’t it be easier to just target the content that you want to change from the beginning?

That tangle of weeds you’re walking through is growing thorns. Have you ever been in the situation where you’re using your framework and trying to add a library to it, just to realize that the library version you need doesn’t work well with the framework version that you’re using? Sometimes it takes more effort to make two pieces of code work together than it does to just write the code yourself. And since the frameworks and libraries that you use are often built on other frameworks and libraries that can have hidden incompatibilities that you can’t even anticipate, the problem can grow exponentially more complex, reaching a point where they’re impossible to manage if you want the project to keep growing.

Keeping up with the Joneses is a thing. Ever worked on a project in AngularJS only to find out that you need something that didn’t appear until Angular 4 was released? Did you even know that Angular 5 has been released? This is another huge issue; even if you’re sticking to a single front-end framework, when a new major release happens, things can change so much that the code you worked so hard to make won’t even run on the new version. This could result in anything from annoying little changes that need to be made on a lot of files to a complete rewrite of your code.

Keeping up with the latest builds of a framework is challenging, but on the same note, other frameworks suffer when updates stop completely and they can’t keep up with the rest of technology. In 2010, both AngularJS and Backbone were released for the first time. Today, Angular is on its fifth major version, and Backbone is completely out of the spotlight. Seven years seems like a long time. If you build websites, they’ve probably changed completely in aesthetic and function. If you’re building an app, betting on the wrong framework might put the company in a tough—and expensive—situation later, when things need to be rewritten.

When all you’ve got is a hammer, everything looks like a nail. If you’ve used web development frameworks frequently, this has probably happened to you, where a single codebase defines the shape of the code you use in the future, even if it’s only peripherally related. Let’s say you’re going to build a platform like YouTube and you want to use Framework X. There might be a point where, even if it sounds ridiculous in this day and age, you decide to use Flash for the videos because that’s what comes built in with the framework.

Frameworks have opinions, and they are strong; React, for example, forces you to use JSX in a specific way. You can see code being used in that way everywhere. Is there an alternative? Yes. But who uses it? This isn’t always a bad thing, but if you need to perform complex animations, you might only need a framework for animating and not the entirety of React. I’ve seen people do crazy things like add jQuery to a page just to append a node to an element, something that could be accomplished in vanilla JS with document.getElementById('id_of_node').appendChild(node);.

Eval Is Evil, but .innerHTML Is Machiavellian

I want to take the time to explore this point separately because I think this is one of the reasons more people don’t code without frameworks. When you see how most code works when trying to add something to the DOM, you’ll find a bunch of HTML injected by the .innerHTML property. We all seem to agree that eval is bad for running JavaScript code, but I want to put .innerHTML in the spotlight here. When you inject HTML code as a plain string, you lose any reference you might have had to any of the nodes you created. It’s true that you might get them back by using getElementsByClassName or assigning them an id, but this is less than practical. When trying to change the value of one of the nodes, you’ll find yourself rendering the entire HTML back again.

This is good when you start coding. You can make lots of simple things easily without much experience. The problem happens with the complexity of modern websites, which tend to be more like apps—this means that we need to constantly change the values of our nodes, which is a high-cost operation if you’re doing it by reattaching the entire structure via .innerHTML. React solves this problem efficiently via a shadow DOM, and Angular addresses it by using binding as an easy way to modify a value shown on a page. However, it can also be solved fairly easily by keeping track of the nodes you create and saving the ones that will be reused or updated in variables. There are also other reasons to stay away from .innerHTML in general.

The Biggest Myths about Coding Without Frameworks

Time is money. Yep, I’m bringing this concept back from earlier. Many people feel like if they stop using a popular web framework, we will instantly devolve to the internet of the 90s, when <marquee> was everyone’s favorite tag, rotating GIFs on a Geocities site were hip and edgy, Alta Vista was the go-to for web searches, and hit counters were ubiquitous.

With web frameworks, your first lines of code seem to make a lot of time-saving progress, but at some point, the gains turn to losses. You spend your time reading about how to make the framework do things it isn’t built for, how to integrate libraries and make them play nice with the framework, and finding out that the code you built while following the framework’s standards isn’t going to work at all and now you need to rewrite it. When you do things without a framework, you start slower, but you make steady progress. In the end, it’s all about where you want the easy part to be. It won’t make much difference in total time.

My code will be longer than the Great Wall. Writing without a framework is like buying a movie instead of subscribing to a streaming service. You don’t get instant access to hundreds of movies that you want to watch, but you also don’t have to spend money on thousands of other movies you’d never even consider downloading from the store. You can just write what you need.

Is the middleman useful? Sure. But it’s not usually necessary. Every line of code you write has more meaning, as there’s no need for you to adapt to the requirements of a framework. It can feel like you are writing more code with pure JavaScript because the way to create the DOM elements takes lines to create an element, attach it to the DOM, and perhaps add a class for styling, as opposed to calling up a single line of code in JSX. But if you compare code using a library like jQuery or React, vanilla JS can be pretty similar in length. Sometimes it’s longer, but sometimes it’s shorter, too.

There’s no need to reinvent the wheel. The mantra of computer science professors everywhere. And it’s true—it just doesn’t have to mean frameworks specifically. Sending an Ajax request to load or save data is a requirement in almost every web app, for example, but not having a framework doesn’t mean that you need to write the code anew every time. You can create your own library or codebase, or you can extract code from others. The smaller it is, the easier it is to modify or adjust as needed, so it comes in handy when you need something specific for a project. It’s easier to modify 100-200 lines of code than navigate through the mountain of files that a third-party library or framework might contain.

It will only work for small project. This is a very common myth, but not true at all; currently, I am working on an entire system to manage all aspects of a company online in a single place, including a module that is something like Google Drive. Whether with frameworks or without them, I go through very similar steps and encounter very similar problems. The difference is negligible. However, without frameworks, my entire code is smaller and more easily manageable.


Okay. Let’s stop talking about theory and jump to a real-world example. Some days ago, I needed to show a list of brands with logos for a store. The initial code used jQuery, but it had a problem where, when loading in Mozilla, it was showing a broken image icon for brands that didn’t have logos uploaded yet. We can’t have the store looking unfinished just because Company X hasn’t finished their end of the work yet, but the feature needed to go live.

The following code uses the jQuery equivalent of .innerHTML:

var list_brand_names = ['amazon', 'apple', 'nokia'];
var img_out = '';
for (i=0;i<list_brand_names.length;i++) {
   var brandName = list_brand_names[i].toLowerCase();
  img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>";

Without going too deep into the pros and cons of jQuery, the problem here is that we don’t have any reference to the images we created. While there are solutions that don’t involve changing code, let’s use this opportunity to see how it can be done without any library at all:

var brands = ['amazon', 'apple', 'nokia'];
var brand_images = document.getElementById("brand-images");
for (var iBrand = 0; iBrand < brands.length; iBrand++) {
  var link = document.createElement('a');
  link.setAttribute('href', '/pages/' + brands[iBrand]); = 'none';
  var image = new Image();
  image.src = "images/" + brands[iBrand] + "png";
  image.onload = function(){ = '';

The original jQuery code was six lines long, while the vanilla JS solution took twelve. To solve the problem, hiding each image until it’s been loaded, takes twice as long to code. So let’s look at the alternative. Can it be solved in jQuery too? Check it out:

img_out += "<a href='/pages/" + brandName + "' style="display:none"><img src='images/" + brandName + "' onload="showImage(this)"/></a>";
function showImage(image){ = "";

With a couple additional lines of code, there is now only a three-line difference between the jQuery and the vanilla, but on the jQuery, you can see that the img_out line is quickly growing very complex, to the point where you need to pause and think carefully about what you’re doing. Coding the DOM directly by using node functions to add attributes, functions, and the like might be more lengthy, but each line has a clearer, more precise meaning, making it easier to read and maintain in the future.

Let’s take a look at React:

function BrandLink(props) {
  var url = "images/" + props.brand + ".png";
  return (<a href="{props.brand}"><img src={url}/></a>);
class Brands extends React.Component {
  constructor() {
	this.state = {brands: ['amazon', 'apple', 'nokia']};
  render() {
	const links =, move) => {
  	return (<BrandLink brand={step} key={step}/>);
	return (<div className="brands">{links}</div>);
ReactDOM.render(<Brands />, document.getElementById("root"));

This version is clearly sub-optimal. The code is no shorter than it is in vanilla, and we still haven’t even gotten to the point of solving the problem and hiding the links until the image inside them has loaded.

For every example, the results are going to be different. Sometimes, jQuery will be shorter. Sometimes, React will win. There are times when vanilla JS can be shorter than both of them. In any case, the goal here wasn’t to prove that one was inherently superior to the other, but to demonstrate that there isn’t a significant difference between using vanilla JS and using a framework when it comes to code length.


As with just about any real-life issue, nothing is black or white. Coding without web development frameworks might be the best solution for some of your projects and a nightmare in others. Just as with every tool, the key is in learning not just how to use it, but when, and what the advantages and disadvantages to using it might be. Coding in pure JavaScript is just like with any framework—mastering it takes time before you feel comfortable using it.

But the key difference, at least for me, is that frameworks come and go, and even if a framework is popular for a long time, it can change dramatically from one version to another. Pure JavaScript will be an option for much longer, until it stops being relevant entirely and some other language emerges. Even then, there will be more concepts and strategies that you can migrate directly from one language to another than you can with a given framework to another. Time and effort being roughly equivalent where a single project is concerned, the reduction in knowledge depreciation and the lessons you can take with you to the next challenge are very important factors to consider.


Vijay Thirugnanam
I use React. I am told DOM manipulations are expensive. React has this virtual DOM and makes it efficient to do DOM manipulations. Is it not worth it? #JustAsking.
Raika Tech
This is beautiful! I agree with everything you wrote. Frameworks are a siren's song: you can get a certain percentage of the functionality you need very quickly, but getting the remaining functionality *and high performance* becomes a fruitless endeavor.
Ming Hann
It's so hard to maintain a large scale webapp without a framework or library. With react, the amount of code is reduced by a lot compared to the template approach in the past. Of course if it's some small projects, jquery is still very relevant.
Raika Tech
Relative to the inefficiencies inherent in most frameworks, your DOM manipulations are minuscule. The next time you have a JS error/exception in your console, take a look at the stack trace to get an idea of how many hoops the framework is jumping through before it ever executes any application code.
Raika Tech
Another point to add - how much fun it is to figure out an obscure error using a framework; you most often get a stack trace that doesn't even reference code that you wrote.
Raika Tech
That's not true, in my experience. Frameworks cause *more* code to be written by the developer. Without exception.
Ming Hann
But at least everyone is using the same standard, imagine you have 5 developers write in jquery, it will be some kind of mess.
Almost true. You are talking very similar to assembly coders vs. compiled language coder. You are right that plain JS code is much more performant, much less dependent. But, and this is a big but. Plain JS code is hard to read, hard to maintain, because it contains a lot of boiler plate code to achieve what it want to done. Modern frameworks' code much readable I think. I guess, you don't want to write repetitive code for similar tasks and probably you start to collect helper functions in a library. This library is your framework! BTW, React is not a framework, that is a library. Yes, I am a big fan of React, especially of React Native :)
I loved AS3 it teach me a lot of how i code to day, and how i see things. I also had the same feeling when the attack against flash began, why say something is obsolete if the alternative isn't as good? JS has moved a long way and now we can begin to see its real power, and you're right SEO is a big issue still like it was back in the day.
Raika Tech
That's an assumption that would hinge on the habits of the developers. Using a framework to facilitate some standard is a tacit admission that frameworks exist to make up for the lack of quality of developer. I think there's also some clear evidence that using a framework doesn't guarantee sameness between developers' code. When I look at the many articles on the Web, there are quite a few different ways to do the same thing.
Ivan Ivanov
That's soooooooooooooo true
Raika Tech
React is a framework. It implements its own arbitrary folder structure for your project and dictates which "blanks" you as the developer have to fill in. When the project runs, it executes React's codebase, calling out to your objects and methods when it decides to. Whenever the flow of execution is controlled that way, it is a framework. And this is *not at all* like comparing assembly to higher level languages.
You are holding it wrong :D Beside from joking, I have faced the same many times, but I always found another way to solve my problem.
React: A JavaScript library for building user interfaces ( Nothing more, nothing less. However, I am afraid it is tend to be a flame war.
Raika Tech
Their label is not a classification of what something is. I bet it says "light weight" somewhere on the page, too, just as all frameworks do. This is not a flame war, IMO, nothing personal. But really, what someone calls themself does not make it so. I have used React, as well as other JS frameworks and PHP frameworks.
OK, for me React is a library, Angular is a framework. Plain JS is plain JS. I too have used React and Angular, but never PHP. And, yes, when I started to learn web dev I dig into plain JS, but I quickly got tired to implement everything from the scratch.
I think it is not a good measure. You are counting the bootstrap code frame. It is somewhat similar to, let say, you start to debug a Java app from the main() func.
Raika Tech
Every execution of everything will take circuitous route through a very deep stack of the framework's code. It is the same as the Java concept, and if that Java application had a stack of function calls 50 deep before it calls a DOM manipulating function, like frameworks often have, I'd say the same thing -- your DOM manipulation is not the biggest contributor to execution time. (Unlike a framework, in the case of debugging Java, you will actually see the function that causes the error in the stack trace.)
Martin Sosic
Although the line can be subtle between the two, I just wanted to back up "React is library, not framework" claim. I would not agree with the claim that "it implements its own arbitrary folder structure for your project", there is no enforced folder structure. It does come with some strong recommendations on the other hand, so I am assuming that is what you are referring to. I believe you can feel difference the most when taking a look at Angular and React in parallel: in Angular you certainly feel like you are using framework, since it is covers everything needed to build SPA, while React takes care only of the View part: you still have to figure out how to organize your folder structure, how to manage the app state (often with Redux) and so on.
Martin Sosic
Juan, thank you for interesting post! I am sure there are cases where vanilla JS makes more sense than using library like jQuery, however I was somewhat confused by your example where you compare the two. When using jQuery you are concatenating all the elements in one big string and then setting them as as innerHtml of container node, while when using vanilla JS you create node by node and then append them to the container. You then argument that vanilla JS is neater and easier to understand because of that, and I completely agree using nodes instead of concatenating strings is nicer, however why wouldn't you use the same approach in jQuery? You could also create node by node and then append them to the container, and I believe you would find that code similarly neat and readable, if not more readable.
Raika Tech
But who controls the flow of execution from the top and all around? When I'm coding "exit points" for something to call, that other thing is the application. It is what's being executed and it calls code that I write in the methods of an object structure that's dictated to me. Libraries are things you include and call from your code. I don't believe the distinction is subjective or indicated by a feel.
Dmitry Sintsov
Check out Knockout.js: In pure ES5 - no large toolchain, no gulp / grunt / no transpiling with library size much less than of Angular / React, you have the most useful features of Angular and smaller code size than of React for the same app. You may write the large apps with it. It's a hugely underrated library. Maybe it's 15% slower than React due to less usage of virtual DOM, but the advantages of pure ES5 - what you see is what you run, no install, and smaller code outweights the drawbacks. Actually the world should move to ES6 of course and most of current browsers support it without transpilers. Unfortunately IE11 does not have even the basic features of ES6 (even no arrow functions) and Microsoft plans to support IE11 till 2020 or even later :(
Napoleon M
Great article. I can't be more agree with you.
Łukasz Zaroda
The stronger point would be that there are quite a few FRAMEWORKS to do the same thing ;) .
Ildar Sagdejev
I think a language made for the front end like Elm has the potential to resolve some of this vigorous JavaScript framework proliferation:
Kenan Balija
Hi, You have small error here : $(‘sku-product').html('SKU 909090'); It should be $(‘#sku-product').html('SKU 909090'); Great article by the way. Keep up the good work
John Robie
I wouldn't knock Flash (I know it's the cool thing to do an all). I started in Flash, which had a great language (AS3) with a very sensible static/dynamic type system, and legitimate classes / interfaces. I could offload heavy lifting to the GPU, and 3D was easier than JS/CSS is now. We had Workers for multi-threading and background tasks. For RIA (today's SPA), we had Flex, with FXG (styled with CSS). We had AMF and RTMP for push messages, streaming and binary data transfer (with type casting). Deployment was a simple .swf file, and we could target desktop and mobile via Adobe AIR; with essentially the same features that Electron and other web wrappers provide. We could load additional .swf files as needed, similar to how code splitting works now. Now, I work in Vue and React, and repeatedly find myself thinking that we took 10 years to build JS to where Flash already was, but the tooling/build/deploy is worse. If memory usage and SEO were the main problems with Flash, would it really have taken 10 years to fix it!? I think not...
While I do agree that frameworks come at a cost - you are missing out the biggest arguments for using a framework. Frameworks are very cost effective. Imagine each time you join a new team you have to learn their style of doing frontend development (this applies to practically anything in life). It would be a nightmare. However good a developer you might be, it would take you roughly a month+ just to familiarize yourself with their style. With a framework, you hit the ground running almost instantly. Nowadays, you only need to learn React/Angular/Ember and you're employable in most of the companies. This is a simple economical choice a developer and company makes that pays off by a large margin. Internal frameworks are an easy source of yak-shaving/bike shedding. Instead of outsourcing the cost of arguing on how to do things properly, every developer now has their own opinion (and knowing us - this will never end). Majority of what we develop is pretty cookie cutter and most frameworks address that. Unless you're working on a very unique project, major frontend SPAs want to: 1) show a list of things 2) be able to change some of those things 3) update the database with our changes. The only times I've seen where this isn't applicable - was when dealing with visualizations not relying on text only to do the job.
Yes you could use the same approach on jquery, the main idea is to present the possibility of not depending on framework or big libraries, and what will you face pros and cons to do so. Like everything there are pros and cons and learning about a new framework can change the way you view or approach a problem; even while coding on a different framework one or without any.
Yes unfortunately seems in some regards we are like at beginning of the millennium, we still face some browser compatibility but certainly the panorama is a lot better than back in the day, while latest features of the language might or not be available on certain browsers, a lot of things are supported on many browsers. Again Microsoft browser isn't on the edge of supporting what other browsers do ;)
You are right being able to maintain a code-base is hard when people integrate to a team, but same could be say about any process in a company, also this might happen even under the umbrella of a framework. Having a standard is something that should be a critical point in most complex developments. About what SPA's needs those needs could be solve with or without a framework, certainly this is not the best option for everyone ( i do agree on that) but i think is always good to open our minds to ideas we might not agree 100% cause all styles of coding can teach you a trick or two on how to evolve your skills. I do certainly play with frameworks and follow conferences on how they work, and i learned things that have change the way i view coding.
I have build very large application without a framework and the code I'll will need to write seems will be very similar and will need to start adding extra libraries to the framework. I hear this a lot about people using 3rd party code is that you spend a huge amount of time reading and reading code, i spent most of my time writing code. Like everything it has is pros and cons, but you can do anything with or without a framework, in the end is how you choose to work, nothing wrong with any of both ways. I'm here to just present a different option that most of the times is ignore as we don't have as many courses on building complex stuff with plain js, as we do with for example angular or react. I've seen many times landing pages build on a framework, and coders having to spend most of their times trying to make do the framework what they want, meanwhile without the framework restriction it could be done easier.
Jack Leach
Related: (best article I've ever read on JS frameworks).
> You are right being able to maintain a code-base is hard when people integrate to a team, but same could be say about any process in a company, also this might happen even under the umbrella of a framework Except this is the one that you are hired to do. Whether you fit in with the culture is something everyone has to go through (even non-devs). > About what SPA's needs those needs could be solve with or without a framework, certainly this is not the best option for everyone ( i do agree on that) but i think is always good to open our minds to ideas we might not agree 100% cause all styles of coding can teach you a trick or two on how to evolve your skills. No, SPAs are possible to work with without frameworks (that much is obvious), the same way I can solve your cold with some medicine my grandpa taught me. It might work, but if you want another doctor to understand when I screw up, you better show them some documentation that works with any doctor. Otherwise, you are wasting everyone's time just so they can understand your unnecessary and expensive situation. I'm being harsh on you but this is such a dangerous opinion to hold unless you're talking about a specific use case. In all other cases, it reads like a contrarian for the sake of being one. A fair argument should be "learn JS and software architecture without learning frameworks for face value". > i think is always good to open our minds to ideas we might not agree 100% cause all styles of coding can teach you a trick or two on how to evolve your skills. It's pretty much what I wrote above. Learn CS fundamentals - algorithms, data structures, software architecture and general industry best standards. Does this mean frameworks are bad? No way friendo!
Martin Sosic
Hey JC, I agree with your points and I understand that you wanted to present the cons and pros of frameworks vs vanilla JS, however I don't think the example you provided presents cons or pros well. In that example, your are claiming that vanilla JS gives shorter and more readable code than jQuery, but that is true only because you have not used jQuery in the same way as you used vanilla JS (building nodes instead of strings). It is like comparing two boxers, but on of them has their hands tied together behind the back. I believe there must be examples that demonstrate pros and cons of framework vs vanilla JS better, but it does not seem to be the one you provided.
Eduardo Dias da Costa
I've came from Flash era too! AS2 and forward :D I feel your pain with React and Angular being too mainstream. I've created a simpler framework for myself inspired on some approaches I had with Flash. SuitJS -
Even when you don't have the time or the knowledge to solve a problem you can just use a specific library to solve the problem. Smaller libraries are easier to integrate in bigger projects and to extend since they are not a full and opinionated solution.
Taha Hassan
That's true but that library will only contain the functions that your app need and not the 100 of other useless functions which only increase the loading time of your app. Another problem with using any framework or library is that most of the time they support only modern browsers because they try to use latest technologies. Like React and angular support only till IE9. If you are building an app for the market which uses mostly older browsers like IE8, which are still used by many despite what browser statics say, these won't work. There is a reason that Google don't use Angular for everything despite having developed it itself.
You are missing a dot (".") before file extension in plain js example: <code> image.src = "images/" + brands[iBrand] + "png"; </code>
comments powered by Disqus