Some additional thoughts on the recent discussion about “frameworks vs vanilla JS” on mobile

Some context for those of all that haven’t been following this thing:

Paul talked about his research on whether to use a JavaScript framework on mobile devices was good or not, for a number of parameters of what “good” could mean. I thought it was a really good starting point because it is nuanced, has data, considers a number of pros and cons and it’s, in short, way more constructive than the usual FRAMEWORKS SUCK message.

The conclusion is that vanilla JS is faster to start as it doesn’t have to do all the bootstrapping that frameworks do. But perhaps using a framework can also be convenient for you as a developer—and for the user if the developer can provide value to them instead of building their own ad-hoc framework. But ultimately the decision depends of each particular case, and each developer has to make their own judgment.

Unfortunately people in Twitter started essentially responding that “hey phones would just get faster (MOORE’S LAW!!! MOORE’S LAW!!!!), so deal with it and use a framework”, and by the way, “actually Paul used an old version of Ember and also React would never be used that way”, despite the fact that Paul said so himself in the post. Anyway…

Tom didn’t quite like the analysis and said that you would need to compare using some other app other than TodoMVC because it’s too simple.

Dave added some more insights too, replying to Tom.

I want to add a number of additional reflections because I ALSO HAVE OPINIONS and since I’m done with talks for the year, I have time to manifest my thoughts now:

The “phones will get faster” fallacy

They might. But that’s not the case for everyone who is not a developer or a techie. The constant, absurd, terrifying-to-witness delusion of developers who believe that everyone is accessing their websites using a 4G connection with the latest and greatest device is just painnnnnful.

Granted, some apps will be built for very niche segments, and you can “count” that they will have the appropriate device to run those. An example of this, somehow, could be games that only run on PS4. The crucial difference is that, ideologically and ideally, the web is not a closed controlled platform as a games console is, despite the multiple and insistent efforts from certain vendors and the irrational buy-in from many developers.

But I go on the streets and I do not see everyone using the latest and greatest iPhone. I see a variety of devices. Tons of cheap Android phones which are suuuuper painful to see in action because the hardware is ‘utilitarian’ but developers assume that everyone has a great Nexus phone as they have. And also—people have been taught that they have to install an app per service because said services do not know how to build a website to provide the service. So turns out that people do need to complete a lot of tasks with their phone, and the more apps they install, the more crippled the phones become.

Yes, you can get another phone which is faster, but it’s going to eventually get slow as you reinstall your ‘task based’ apps again. And the fact that is “faster” doesn’t mean that it actually is giving you the 100% of the resources to you.

Also: apparently JS is not getting faster on Android, despite people buying ‘faster’ phones.

Todo MVC might be, in fact, good enough

While it might not be a super complex app, it is still an app and something we can compare between different ways of offering the same functionality built in different ways. Dismissing it because it’s smaller is ignoring the fact that this is a low bound of “how bad” it gets even with small apps. If anything, it might get even worse.

Code size is not necessarily bad by default

You can have a big code base that seems to run very fast on the phone—time from download to render being super small and the app being very responsive.

But you could also have a very small code base that blocks like there’s no tomorrow, and makes the users of an app cry in frustration because it makes them think that their phone is somehow broken (“WHY IS THIS SO SLOW argh I’ll need to get a new phone OMG NO”).

The sweet spot

Or: but what do you really need?

Framework fans often seem to get offended that the simple proposition of not using a framework (also known as “vanilla JS”) is brought into a conversation. “WHY WOULD YOU NOT WANT TO USE A FRAMEWORK IN YOUR SITE?!! ROWR ROWR ROWR GROOOOWL!!”

Well, actually, you might not need a framework. Or maybe you might need one. Or maybe not now, but soon. So it’s good to plan a little bit ahead, but it is not advisable to plan too far away, because you might be adding lots of additional baggage you won’t need after all.

I think that using a framework starts to make sense once you go past a certain level of complexity. Specially when you have URLs that need to be parsed with a router, and then you have to render templates and all that—possibly your best bet is to use an existing framework with a good community behind, so that people have already tried doing similar things to what you might want to do, and there’s lots of literature you can find.

Those are probably well better tested than any “Frankenstein framework” you might write, and can also offer you great features such as rendering on both the server and the client side, so you get the best of both worlds. Developing this kind of thing yourself might take you a very long time.

But maybe you don’t need to do all that; perhaps you just need a router. Or just a template engine. In my ideal world you should be able to just pick bits and pieces individually, and use them. But that tends to only work for small projects.

Frameworks as a neutral option

It’s not explicitly discussed in the existing posts, but adopting an external framework developed, vettoed and regulated by some other organisation can be one of the most neutral things to do in organisations which do not want developers to “get territorial”, i.e. if the whole organisation adopts the framework ONE of its developers wrote, that developer “wins”, and it creates a potentially problematic power dynamic. I guess that would be Conway’s law at its best.

Another great side effect of not using a framework developed ‘in-house’ is that developers who work on the code base later don’t need to deal with the terrible lack of documentation that is the usual case with in-house frameworks. To date I yet have to see an in-house framework that is not terribadly documented, and I’ve been building stuff for the web for more than 15 years…

Developers love to engage in loud neverending discussions about framework technicalities but it’s important to keep in mind that politics are what ends up driving adoption more often.