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

TOP OF THREAD FULL DISCUSSION
re: Let's just say "all the supporting code and how they're tied together".

all the supporting code

So libraries I'm guessing

and how they're tied together

So an 'architecture' in the loosest possible sense.

All code has libraries and an architecture. Sure, I'll buy that.

But not all code uses a framework. A framework is when somebody else other than me has chosen the libraries and the architecture for my project and is preventing me from changing them.

All libraries and architectures are chosen by someone. I'd just rather that someone was me and my team rather than the collected generalizations and compromises that make up a 'framework'.

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 be that dude, who will be forced to maintain your product after you done playing the architect role.

Or, shall I expect your commitment for next 10 years or more? Should I expect great support for your solution going forward? Should I expect more and more solved technicalities? Will you give me a good documentation?

While I agree that any given framework might be too heavy for certain cases, they save time whenever anyone like it or not. It is too bad, that js offers too many half backed frameworkd and people choose to write their own.
Why franeworks any a necessity? Because every developer faces same technical challenges: DOM manipulation, templatization, communication via protocol, security, auth/authz, localization, event consumption....

Every project is different, yet some technicalities are the same. It is very natural to have shared common high-quality code to solve above with writing less client code. Which means yes - given up some architecture decisions to existing solutions.

But is that really that bad? Shouldn't you worried about solving for your specific client rather worrying for entire developer community? Framework solves for tech stuff, but it does solve for customer domain? What's the reason to increase backlog for yourself and people after you?

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
Security?
Auth?
Localization?
'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?

o_O

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:

martinfowler.com/bliki/DefinitionO...

and

martinfowler.com/bliki/Refactoring...

If you so like Mr. Fowler, it will be good for anyone to understand his take on architecture:
kylecordes.com/2015/fowler-softwar...

code of conduct - report abuse