[conatus]

"The value of a software is not the code itself but in the reasons behind the existence of that code"

I wholly agree with this. However, I'm sort of baffled by this approach. What frameworks allow is you not to have to continiously solve the same problem and waste weeks implementing something that others have solved.

For example, I worked with a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user". In the world of Rails, Django, Laravel and Phoenix this is a configuration task, with existing libraries. In Javascript it was a slog getting the implementation that still lacked much of the functionality of these mature frameworks (there are notification frameworks for Javascript but it was decided not to use them - "no frameworks"!). While it is fun to implement your own thing, here the reasons behind the existence of the code are essentially developer vanity in thinking their notification situation is an absolutely special case, and developer desire to do something stimulating like develop a notification system rather than serve product, organisational or user needs.

To have a clear discussion of this, however, it might be useful to define "framework". Is the target here frontend or backend frameworks? One thing I have observed is in the frontend world frameworks have caused some core skills to atrophy. For example, how many Javascript front end engineers can now confidently, given you click on something, change the colour of it. Probably here a framework is wildly overkill and you will get there with plain Javascript until such a point as complex user interaction is needed.

Realise rhetorically there is less punch to "use a framework mindfully" but this should be basic to any engineering decision "use a language mindfully" and in the last instance "do we need to solve this with software"? Doesn't sound like a movement per sae but corre software engineering skills - use the right tool situationally.

[brabel]

You seem to be equating frameworkless with library-less.

> a team that spent weeks on "given a certain event happens in the software, dispatch a notification to the user".

This is trivial without a framework as long as there is a library you can use to "notify the user" (e.g. an email or chat library). It's actually easier without a framework because "event" is just a line of code somewhere in your own application, while in a framework, it can mean a million things and maybe NOT what you actually wanted.

[Scarblac]

But libraries are much more effective in frameworks.

Say an event that shows a message to a user next time the user sees a page has to know about users, has to be able to store messages for users and remove them once they have been shown, it needs to know about i18n, and have tools to display the current messages in HTML.

A Django library for it can assume the existence of Django for all those things, a general library has a much harder time.

[conatus]

No, I'm not. Libraries were certainly used in this case.

But whereas in Rails this would be mixing in a library to a controller to allow events and configuring them, this was building a new set of models and code over the top of a library for something like Mailgun from no code. A two hour job in Rails/Django/Phoenix but a two week sprint long job to roll your own. Why bother?

[schwartzworld]

> how many JavaScript front end engineers can now confidently, given you click, change the colour of it

The overwhelming majority of JS developers learn the basics before moving on to a modern framework. The most common exception I've seen is backend developers picking up front-end tasks.

If all you're doing is changing the color of something, obviously you don't need a framework. In other breaking news, you don't need a chainsaw to slice bread.

[conatus]

> The overwhelming majority of JS developers learn the basics before moving on to a modern framework.

I'm not sure if this is the case.

I actually set this as an interview question for mid-weight to senior on paper front end engineers and a solid 60% couldn't do it - this was four years ago. Not being able to do this wasn't a "fail" by the way, it was more something to talk around, especially when people successfully reasoned it out without knowing the underlying API, but it did reveal a relatively shallow understanding of the browser environment.

I imagine it is significantly worse now. Do the training course at boot camps take people up from `querySelectorAll` before jumping into React? I'm not sure they do.