re: Todo-MVP: Or 'Why You Shouldn't Use A Web Framework' - The Revenge VIEW POST

re: This is exactly the reason I am not supporting "no framework" idea. You want to make archetectual decisions. Good for you. However I don't want to ...

Why franeworks any a necessity? Because every developer faces same technical challenges: DOM manipulation, templatization, communication via protocol, security, auth/authz, localization, event consumption....

DOM manipulation? Use a library
Templates? Use a library
Communicate by a protocol (say HTTP)? Use a library
'Event Consumption'?

Shouldn't you [be] worried about solving for your specific client rather worrying for entire developer community?

Absolutely. Which is why I solve the specific problems of a client rather than installing the generalized website solution software (which solves problems that my client may not have) and then spending the rest of my life hacking around to make it fit the specification.

That is a real issue; heavily customized 'framework' solutions which are neither fowl nor fish. Developers have adapted the framework so heavily to fit requirements that it's barely recognisable, giving you none of the benefits of the framework but none of the upsides. I think I cover this in my other article.

Lib-way works for small to mid sites, where functionality is segregated and don't overlap, sorry.

There is no one-size-fits all and pushing for a "no framework" feels like it.

Use lib X. Use lib Y. Use lib A.
Add glue-code.
After first year, add lib B and lib C
Oh, C depends on another version of A.
Add glue-code.
Oh, now these libs should be mobile friendly...

I would expect framework to guarantee consistency with API and contracts cross-functionality wise. It is expected to minimize glue and boilerplate code.

In the ideal world.

I certainly understand the frustration then new intent and requirement doesn't fit with old framework. Sh!t happens, time to migrate to more suitable tool.

... or change roles and go to java, .net, c# whatever. Those guys stuck with a framework for decades :)

However I don't want to be that dude, who will be forced to maintain your product after you done playing the architect role.

You know that it's possible to refactor and change code right?

If you dont like the way Dave has architected the code (which btw, isn't anywhere near as big as you probably think it is for most projects) then you can just refactor it.

If you dont like how a framework has architected things, well good luck.

I am sorry, but do you understand that refactoring is not supposed to change architecture of an app? At least I call it re-work / re-write / re-fit. It usually insane amount of work for mid-sized codebase.

If architecture doesn't fit and it is too expensive to change it, I would discard it. No hard feelings.

It is not a question of "like" or "not like". Are we professionals or what? If framework doesn't fit - replace it. Customers doesn't care what exactly are you using.

I am sorry, but do you understand that refactoring is not supposed to change architecture of an app?

Says who? Refactoring is about re-expressing code without changing behaviour. That's all it is

At least I call it re-work / re-write / re-fit. It usually insane amount of work for mid-sized codebase.

You only believe this because you are indoctrinated in framework-land where everything feels big and enterprise I suspect.

If you have sufficient tooling and tests you can easily rearchitect how a system is done in a codebase that has no frameworks. Source: Me.

I am sorry, but do you understand that refactoring is not supposed to change architecture of an app?


Refactoring is a controlled technique for improving the design of an existing code base.
-- Martin Fowler - Refactoring

Design != architecture

Also, refactoring supposed to improve one and only one quality only - maintainability.

Please continue reading and understanding Martin Fowler. I would also recommend to check out Uncle Bob's thoughts on it.

You cannot easily do it. Architecture is too big of change that also invalidates good percent of your test base (integration, system, etc). I am not sure if we are on the same page or not, but I treat architecture as fundamental decisions written in code which defines core properties of a given system. You can change it, but certainly NOT during refactoring. Mostly due to addiction of new properties and removal of others. Switching stacks from java to serverless lamda javascript is an example of architectural decision. Show me code transformation steps from one to another.
Another example is switching MVC to messaging.

Design is more flexible in that sense. Please don't mix system architecture and system design.

If you have tests, you are the king. But I would expect any good mature framework to have more stability than your codebase, btw I have seen your acceptance test.

Don't put me in single camp ;) I am not a framework evangelist nor a binary simpleton.

I have now decided that you're trolling me to ensure that I don't get any work done today.

But in case you're not, or anyone wants to take you seriously:


If you so like Mr. Fowler, it will be good for anyone to understand his take on architecture:

code of conduct - report abuse