Frameworkless Movement

https://www.frameworklessmovement.org/

by WolfOliver • 5 years ago

45 85 5 years ago

bckr4• 5 years ago

Oh my God this is exciting, particularly the resources linked at the bottom [0]

As a new developer who does have some input into the tools we will try at the startup workplace, I feel pretty overwhelmed with how.... Much.... There is.

That others are saying more or less "just use the language, dabnabit", is great.

[0] https://github.com/frameworkless-movement/awesome-frameworkl...

Xeronate2• 5 years ago

I would be pretty hesitant to suggest not using a framework at a startup of all places (although really anywhere). They may seem overwhelming, but they are ubiquitous for a reason.

bckr4• 5 years ago

Yeah, da baws would agree and I understand that. But this is something I'm interested in anyway. I really want to "learn it to the bottom".

gregoriol• 5 years ago

I feel like when you don't use a framework, you actually end up creating your own framework. And while it is of a great engineering challenge to do so, and quite fun to think the system through, it uses much time out of the main aim of the project and you then have to train others on it, and maintain it.

In the meantime relying on an existing framework that fits your needs (and I'm not talking about some obscure ones with only 10 commits by 1 maintainer), you can probably limit the time spent implementing and debugging "basic" stuff that have already been done, integrating components that don't have great connectors yet, ...

brylie2• 5 years ago

Likewise, rich frameworks like Django, Laravel, and Rails tend to handle needs you didn't anticipate. They build collective experience and familiarity into your project far beyond the capacity of a single organisation.

For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead.

enriquto• 5 years ago

For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead.

You cannot seriously believe this.

setr• 5 years ago

The problem I think is the inversion of control — django owns your code; you’re just a citizen within its confines. You’re typically hooking into the framework’s runtime, and thus everything you do is mediated by the framework — great when you’re doing what the framework wants you to do, and a massive PITA when you stray from the golden path.

Not to mention it bifurcates the library ecosystem — you end up with a react forms library versus an angular forms library versus a vue forms library that are all fundamentally the same yet somehow split, by nature of the framework they hook into.

movedx3• 5 years ago

I really want to use frameworks, but I find the learning curve is often hard to overcome without using the damn thing daily.

Any advice on this front? Is it just a case of using, using, using and eventually it'll all click?

sputr2• 5 years ago

Honestly no. Developer would not be paid as much as they(we) are if these things were neither easy nor time-consuming. And yes, a lot of learning development is the latter.

That's why the idea, still pushed as some collages "if you know one coding language, you know them all" is so stupid. In the real world you're not a "X language" developer. If you want to be really good/charge a lot you have to be "X framework" developer.

It's insane how quickly and well one can code when you really "get" on the mainstream frameworks. The designers really did a fantastic job. But it takes a while to learn.

have_faith• 5 years ago

I find that the surface area of a framework (amount of concepts you need to learn) is roughly comparable to the number of problems it attempts to solve. Most established frameworks started with a few problems to solve and they picked up new problems to solve on their journey. The worst offenders don't stop adding new problems to solve.

Looking for a simpler framework often starts with sacrificing some of the problems you want to solve (or didn't realise were being solved by the frameworks you're considering). Maybe I'll make a website for sorting frameworks based on more personal concerns like "on-ramping complexity" and "amount of learning required to be productive". Obviously subjective but maybe helpful.

mettamage• 5 years ago

Learn one framework quite well. I had the fortune in 2014 to be obsessed with making iOS apps and learned Cocoa Touch as a result.

Later when I learned React, I noticed there already were a couple if concepts that I saw before such as lifecycle methods, to the point I could guess what other lifecycle methods React might have.

Once you are on your fourth framework, while only knowing one well, it will feel all the same. At least it does to me.

The questions I ask are:

- what is the preferred way of working with this framework?

- what constitutes fighting against a framework?

- what concepts look a lot (or are identical to) concepts in other frameworks?

If learning is still difficult:

- who wrote a good beginner book?

When I was learning React, I read The Road To React in a few days, then made a small project, then an actual project.

When I really got serious, I had a lot of code already written that I reused as boilerplate/template code and would simply alter it and expand where necessary, learning more advanced concepts on the way.

YMMV

richeyryan5• 5 years ago

You definitely don't want to go reinventing the wheel. The problem that I find, especially in the React community is the belief that everything should be done in the framework. How do you make an API call in React? How do you change the page title in React? How do you convert a string to an integer in React? People create libraries that are closely coupled to React when 90% of what they're trying to achieve could be a plain Javascript module. This isn't just React, its most of the frontend Javascript frameworks.

I think the idea here isn't to abandon frameworks entirely but to use them judiciously and appreciate what can live outside the framework as much as what the framework already gives you:

"Nonetheless, we believe that a framework, when chosen, should be used responsibly throughout the life of the project. Continuously remind yourself that every tool has some kind of tradeoff.

Frameworkless means that you must give the right importance to the technological decision making and realize that the choice to develop a project or a single feature with no dependence on a framework is a real possibility!"

pcl• 5 years ago

“ Frameworkless means that you must give the right importance to the technological decision making and realize that the choice to develop a project or a single feature with no dependence on a framework is a real possibility!”

The thing is, following normal English rules “frameworkless” means “without frameworks”. It’s good to see that the authors know this, but sad to see that they are so blatantly tapping into confusing terminology right there in their pitch.

I get it that this has been a bit of a trend (“serverless”, anyone?), but the fact that others do it isn’t a great excuse.

Hey, they could even riff on the theme while staying true to the language by going with “Lessframework Movement”.

neolog• 5 years ago

"How do I add two integers together with Twisted?"

https://stackoverflow.com/questions/7313761/how-do-i-add-two...

void_mint3• 5 years ago

he problem that I find, especially in the React community is the belief that everything should be done in the framework. How do you make an API call in React? How do you change the page title in React? How do you convert a string to an integer in React? People create libraries that are closely coupled to React when 90% of what they're trying to achieve could be a plain Javascript module. This isn't just React, its most of the frontend Javascript frameworks.

This matches my experience as well. It feels kinda wild - lots of other areas have taught to separate concerns as much as possible, meaning React would just be a View layer that renders content but is unrelated to the rest of the application. In reality, everything seems to get stuffed into React, such that React becomes your entire application.

pruski• 5 years ago

But it’s a problem with bad developers, not a framework.

On the other hand, think of the code those guys could write without a proper “framework”

citrin_ru• 5 years ago

If the app requires 1% of what framework can, you likely will end-up with micro-framework which is much smaller and simpler.

With maintenance the same - if your app is really small most time will be spend upgrading framework (and adapting app in case of deprecation of an old API or other incompatible changes). And you cannot just stick with an old framework version because there are security fixes (and the bigger framework the more often they happen).

But for medium sized app which is actively developed framework can be quite useful.

akvadrako2• 5 years ago

I agree. If I write my own framework which only does what the app needs it does a lot less and can easily be refactored if need be. Usually it isn't a framework at all, just some shared functions. I don't like have tons of unused functionality shipping with my app.

lloeki• 5 years ago

I feel like when you don't use a framework, you actually end up creating your own framework.

It's kind of a reusability fallacy: you have needs, and you implement (or glue together off the shelf small independent blocks) that solve those needs. Of course: you a) structure your code and b) a framework implements similar blocks. So of course a) resembles b) because it solves largely similar problems, especially in the www/HTTP world.

But what doing a) solves that b) can't is that b) is a dependency, and often a big one. The bigger, the higher the chance of a systemic impedance mismatch. And sometimes (more often than we think) the impedance mismatch is too much to bear, and even changes over time as the framework updates, causing cascading costs (including people getting up to speed with the new version). It's all the more frustrating when the impedance mismatch is caused by structural decisions (which are not wrong in themselves!) on technical or functional parts of the framework you're -not- using.

More generally, there's a big myth about reusability in software, which seems to work in an ideal theoretical world, but in practice isn't a fit for everything because reality is messy. There's this big placating warning and shaming over NIH and 2SS, but these should not be dogma.

What I found to be consistently true though, is that simple code produces the best results, both in TTM and saving-my-future-ass-some-bloody-time-and-blood-pressure. But simple is also the hardest. Sometimes it's spinning up over a framework because it's a good fit, sometimes it's skipping or dropping the framework because it's too impacting. Both are OK, and sometimes both are even OK at the same time because overall it's a multivariate trade off.

KronisLV• 5 years ago

Currently experiencing this at my current place of work. Instead of picking a popular React component framework (though the smaller ones would probably be considered libraries), i'm now stuck creating basic stuff, like new components for tabs and whatnot. That's even more fun when you have coworkers that enjoy lengthy discussions about the implementation (which isn't necessarily a bad thing) in combination with clients that want things done ASAP (which is a bad combination).

On the other hand, there are certain other projects which use frameworks like AngularJS which were essentially dropped and are now in the process of dying out - maintaining solutions written with AngularJS isn't fun either and also wastes time sometimes, especially when new components or other libraries can't be integrated with it easily (no pre-existing integrations for modern stuff exist and our own ones need to be written).

Of course, that's just in regards to the front end development - when talking about back end development, i'd err on the side of caution. Working without a pre-existing framework would mean having to write your own security code and that's generarlly regarded as a very bad and dangerous decision based on what i've heard:

- https://youtu.be/4qN3JBGd1g8?t=2371

- https://speakerdeck.com/eoinwoods/secure-by-design-security-...

bartimus• 5 years ago

My last vanilla Javascript project ended up with a library of useful functions which could be used independently. My last vanilla PHP project indeed had some sort of glue layer to tie some things together (routing). But it was more about convenience and less about requirement. Most of the code could be used independently nevertheless.

usbzcable• 5 years ago

gherkinnn• 5 years ago

I see it as a good exercise to discover why frameworks make sense.

And then you build stuff using a framework.

arcturus17• 5 years ago

Every engineer I've ever talked to or read about going frameworkless says the same thing: we ended up rolling our own. And in most cases, with poor results and quite a bit of hair-pulling.

I like to keep an open-mind about all things engineering, and I agree that some of the complexity of the tooling and frameworks that engineers use daily can be overwhelming; there may be simpler ways to do things, and it's very healthy to question the default of using a framework for everything.

However, such a movement will also be judged stringently based on results. How many relatively large-scale and critical applications will it manage to produce economically, and with developers reporting high levels of happiness?

sputr2• 5 years ago

Personally I would consider any developer that advocates what this "movement" advocates as a developer that should never touch any production code. And this is the reason:

Every engineer I've ever talked to or read about going frameworkless says the same thing: we ended up rolling our own.

Reading their critiques of frameworks the only thing I could say at every point was "yeah, but not using a framework is even worse".

I think this is nothing more than the "I am very smart" sentiment. Well I'm not smarter than (large, respected) framework designers. Most developers aren't. And it's not just a matter of "learning" but a fact that neither I, nor most other developer will ever be. And why should we be - that's just reinventing the wheel, isn't it? We should focus on our own specific domain challenges.

And yes, it means doing things "the framework way". Because most of the time it IS the better way, even if I can't realize that yet (oh, but I will in a few months).

omniscient_oce• 5 years ago

Yeah I caught myself almost doing something similar when I wanted to implement some internal tools with a React webapp and a backend server that I was going to write in Go because I wanted to learn Go and it seemed like it would have better performance, yada yada.

Then I came to the (obvious) realisation that the other guys have predominantly experience in JS/TS so it would be kind of irresponsible of me to force anyone else who wants to contribute to this now or in the future to have to do it in a new language, rather than the one that we use in our main project. Ended up going with Typescript and I think it was definitely the right choice. For production code you just gotta go with what A) works. B) the rest of the team is familiar with (or has a reasonable chance of learning enough to read/contribute)

Ma8ee• 5 years ago

I thought it was obvious that you, except for the most trivial systems, would have to roll some kind of replacement. The advantage of rolling your own would be that it could be a simpler, tighter, framework just for your specific use cases.

Just starting to code without any plan or architectural concerns, of course that will go to shit.

And maybe this points to one of the biggest advantages of frameworks. They force (inexperienced) developers into some kind of structure, where there otherwise would be none.

legulere• 5 years ago

In theory you should deeply know how the frameworks that qualify for your project. You need to know it to make a good decision wether to take it or not.

You need to know it deeply if you use it, because frameworks usually offer relatively leaky abstractions where you need to know implementation details for the best results.

You need to know i if you roll your own code, so you understand which parts you can leave off and how to do the parts that you also need (if you cannot reuse code you should always try to copy the idea of existing code and adapt it to your problem first).

In my opinion using a framework or not should always be an informed decision.

tpetry• 5 years ago

Have fun recreating everything a good framework does provide you and see your competitors running away because they will have a much higher developing as they don‘t have to constantly reinvent the wheel.

Every frameworkless project i have seen was total spaghetti code vbecause there were no clear rules. Or they build their custom in-house framework you had to learn first which was highly inferior to open source ones.

How about a databaseless movement? /s

bauerd• 5 years ago

You can just substitute "framework" with any abstraction, eg "operating system", "graphics driver", "programming language". Might as well have been called the looking-under-the-hood movement.

jbverschoor• 5 years ago

Let's ditch the standard libraries too

ekvilibrist• 5 years ago

  They are very powerful tools, written in plain vanilla language and in a very generic way, a fact that makes them great learning tools which can help anyone learn how to code without them. In order to know how and when you should use a particular framework you have to understand how frameworks work.

So work to spread knowledge of the language and tooling. Don't throw out the extreme benefits that comes from frameworks and strong conventions. At any given point, you are (probably, unless working alone) gonna have junior and senior developers in a team.

  Understanding the strengths and the constraints of each framework will enable you to make the right choice of a framework. Even more, it will be very clear when you don't need one at all. Grasping the concepts of how frameworks work behind the scenes will deepen your knowledge about the language itself. Knowing the framework's rationale will enable you to write better code for each specific problem you encounter.

All of that sounds great. But its not gonna be feasible in any environment I've ever worked in, the requirement that everyone should be at the exact same skilled professional mindset and experience.

throwaway3699• 5 years ago

But its not gonna be feasible in any environment I've ever worked in, the requirement that everyone should be at the exact same skilled professional mindset and experience.

You don't need the same levels of experience to do this. It's not like junior engineers are the ones picking frameworks to use, that's the responsibility of a manager/TL.

naranha2• 5 years ago

The term framework itself is kind of hard to define and in many cases almost identical to "library". Is express.js a library or already framework? Or both? At least it calls itself a framework..

Many libraries or frameworks do one thing and one thing well, but there are also frameworks that are a collection of libraries for different purposes. I feel entrenched when frameworks limit library choice by making it hard to switch out components. From that perspective I prefer libraries over frameworks, but the distinction is kind of hard to make.

dnautics2• 5 years ago

I think the general rule of thumb (which I don't think the op adheres to): if your code calls it, it's a library, if it calls your code, (as in you are fulfilling some interface) it's a framework.

naranha2• 5 years ago

...which makes the distinction even harder in node, because it is a callback based language. Nearly everything is based on my code being called.

Sticking with the example of express.js, for me it feels more like a library since I'm still in control of the program flow, even though I need to adhere to certain interfaces.

undecisive3• 5 years ago

Yeah. I'd also say if it significantly changes the way you code, it's a framework. So I wouldn't consider jQuery a framework, because you could replace any jQuery call with one or more lines of vanilla javascript.

I would call react or backbone.js or angular etc frameworks, because you would have to completely restructure your codebase in most cases - or, at least, create compatible clones of those libraries.

bckr4• 5 years ago

Most helpful comment of the day goes to...!

jiriknesl• 5 years ago

I think this movement comes approximately 10 years late. Microservices led to the growth of devstacks that has replaced frameworks a lot. I don't know a lot of people who start new projects with big frameworks (maybe Java guys), it's all devstacks around me. In some cases, it's sad because frameworks often have things that have to be reimplemented.

kasperni• 5 years ago

Microservices led to the growth of devstacks that has replaced frameworks a lot.

You are just replacing one framework with another (Kubernetes).

js82• 5 years ago

Maybe frameworks are simply operating systems, and Kubernetes is just a distributed extension of Unix. So people should ask a question, is that operating system extension well-designed?

Xeronate2• 5 years ago

How do microservices replace web frameworks at all? Every microservice I've seen uses some web framework (django, flask, asp .net core, spring boot, etc).

abunuwas2• 5 years ago

I don't think microservices replace frameworks. Building a microservice is no different from building a monolith. The difference is in how you architect the system, not how you implement the components

fuzzy2• 5 years ago

Please read the article before complaining…

Key point IMHO:

They [frameworks] are very powerful tools, written in plain vanilla language and in a very generic way, a fact that makes them great learning tools which can help anyone learn how to code without them. In order to know how and when you should use a particular framework you have to understand how frameworks work. Understanding the strengths and the constraints of each framework will enable you to make the right choice of a framework. Even more, it will be very clear when you don't need one at all. Grasping the concepts of how frameworks work behind the scenes will deepen your knowledge about the language itself. Knowing the framework's rationale will enable you to write better code for each specific problem you encounter.

I very much support this. Know your tools!

undecisive3• 5 years ago

I think the problem is that the site seems a little confused about what it wants. I'd consider:

[we are] interested in developing applications without frameworks.

... and ...

nor we will ever create campaigns against frameworks

to be in direct contradiction, yet these are in the very first paragraph.

Reading this page, I'd take it as a rallying cry against useless libraries that could be replaced with a few of lines in your codebase that can be understood and changed and adapted, rather than depending on a generic unchangable external source.

Reading the manifesto itself (following the github link) it sounds like a rallying cry against something else entirely - management-dictated technical decisions.

But maybe the confusion is intentional. People will read into it what they want to see.

o_p• 5 years ago

This is like applied Dunning-Kruger

the-dude• 5 years ago

This year I picked up Rails again after a 7 year hiatus ( I didn't have the need ).

I am grateful for all the batteries and their maturity. And if it doesn't scale anymore, I am having other problems.

iveqy• 5 years ago

A dependency (and that includes a framework) always comes with a cost. When using only a small part of the dependency, it's often better to roll your own than to use the dependency.

When you are able to use large parts of the dependency, then it's often better to use it than to roll your own.

jpxw• 5 years ago

This site is very sparse, and frankly mealy-mouthed. It doesn’t give any examples of what “frameworks” it would like us to reconsider.

When I read articles like this (why <insert technology> is “bloat”), I often feel there’s a level of arrogance behind it. Like the writer is just assuming that the readers haven’t considered the pros and cons of the frameworks they’ve chosen.

Since the article gives no examples of its own, let’s tak JS/React as an example. IMO, the upside of using React is absolutely enormous, and far exceeds the risks (especially given React’s excellent level of adoption, good ecosystem, etc). If we didn’t use React, we’d basically end up creating our own, shittier “framework” of informal conventions and abstractions, which would never be anywhere near as efficient/useful.

dindresto• 5 years ago

Good thing then that React is a library and not a framework. :) (only slight sarcasm)

undecisive3• 5 years ago

Exactly!

The problem is, when do you consider a library more than a library though? And when do you consider yourself more bound to the "framework" than not?

I'd say given the way that react completely inverts the way you structure the code you write, that's more of a framework packaged in a library. It's not a library you can just move away from (unless you like writing DOM compilers in your spare time, or you plan to move to one of the clones written by people who like writing DOM compilers in their spare time).

Do we consider Ruby on Rails a framework? And if so (because the site makes the distinction...) is it the kind we should only use until we can "code without it"? What about in Java-land, Spring or Struts or Hibernate (or even Swing, though that comes packaged with Java so maybe isn't included in the question) - should these be avoided or embraced? (for reasons other than the horror show that each might be)? And then there's PHP frameworks - too numerous to number, but given the pain of trying to write secure PHP code definitely worth considering - do the security benefits outweigh the risks?

I feel like the summary of the original post is "Know your stack" - and that's a great message - but the page conflates Frameworks (which are generally a good thing to use at least until you reach guru status) with spurious libraries that do next to nothing yet introduce another attack vector.

I'm all for developing apps with fewer dependencies - libraries or frameworks. Totally against developing apps without frameworks.

choeger• 5 years ago

Most frameworks aren't, at least not in the literal sense.

By definition a framework is mostly transparent. You can see through it, look at it and think "whoa, I am glad that it is already there" or you can conclude "hmm, I think this part over there will not allow me to do that. I might need a different shape of framework or maybe even build it myself."

Most so-called frameworks hide the complexity and do not explain their architectural choices. In consequence, you end up with suboptimal applications quite regularly. They do this by mixing useful tools instead of providing orthogonal features, for instance a specific language for writing templates tangled together with a MVC base.

stdbrouw• 5 years ago

That sounds like a cute analogy, but even though the wooden framework of a house is mostly see-through and somewhat modular, it would actually be quite cumbersome and effortful to say "okay, but for this particular wall I'm going to do something entirely different", and if you do, then it might turn out that some of the other things you'd like to have on top of it, say, insulation or drywall, no longer fit very well or no longer do their job as intended. In that sense, the word "framework" in programming actually maps quite nicely to the original meaning of the term.

globular-toast2• 5 years ago

Let's create more work for ourselves! Reinvent the wheel for every project!

void_mint3• 5 years ago

I think every dev should try to build a substantial codebase without any frameworks or libraries. You have to go way way beyond the "Hello, world" concept in whatever you're trying to build, ie if you're building a REST API you have to care about request/response headers, caching, middleware, auth, concurrency, dependency injection, etc. You also have to document all of it to the point that another developer could sit down at a workstation and build something substantial in your custom non-framework.

In my experience (both having done this and watched many devs do it), you find out relatively quickly how much a framework was handling for you, and you find out quickly how much you don't actually want to handle yourself. The fun part about doing it all on your own is you have the supreme knowledge of how everything works - there's no guessing and there's no magic. You wrote it, you know exactly what it does. On the flipside, you're on the hook for building it, even the boring parts. Even the parts you don't really care about but have to implement. Even the stuff you actively dislike.

heax• 5 years ago

I think they mainly employ a JavaScript perspective where a frameworks lifetime is measured in minutes.

Sure many classical backend frameworks use a central database technology which limits their scalability, but the mature frameworks with sufficient backing behind them still do the job and save a ton of time. With those you will end up with a maintainable application on the long term. Think of django, heck even JavaEE if done right.

Most of you are not Google ;)

pkrefta• 5 years ago

I've started using React.js in 2014 and I'm still using it today. That's probably quite a lot of minutes TBH.

Month ago I've started another project - again React + Redux. I don't think React.js will disappear from the scene anytime soon.

Cthulhu_• 5 years ago

They name it frameworks, but they seem to rail against libraries instead. A framework is for application development, gives you a handhold and should solve 80% of non-functional problems like idk, API access, escaping, data(base) management, etc.

But a lot of the resources are of the 'you may not need jquery/underscore' variant, which is a different discussion.

jillesvangurp• 5 years ago

I've used a few light weight frameworks (e.g. re-dom, which is pretty nice) and recently a kotlin-js framework called fritz2. My observation is that even "heavy" frameworks like react are not all that complicated or particularly big. The reality is that most websites don't actually pull in a lot of external code in any case even if they do include a framework. There are a lot of build time dependencies but not a lot that ends up running in a browser with typical frameworks like react, vue, angular, etc.

So, the difference between using a framework and not using a framework in terms of the amount of code you need to write is not that large. Mostly frameworks are just about getting you to structure your code in a particular way. In react's case most of what it does is getting you to generate html via their templating language and having a thin DOM facade to make DOM updates less of a PITA to manage. That thin DOM facade is very easy to replace with something else. E.g. the re-dom code base is tiny and most of it is just some best practices around using the DOM api. React is a bit more elaborate in what it does but most of that is strictly speaking just nice to have and not really required with modern browsers.

Fritz2 is a Kotlin framework that emulates a lot of good stuff in other frameworks. It uses a Kotlin DSLs instead of templates, Kotlin's co-routines and StateFlows for managing state and handling events. Otherwise, it works more or less directly against the DOM. Seems to work and scale fine.

continuational• 5 years ago

I mostly agreed with this sentiment, but how do you get composable, declarative DOM components without a framework?

js82• 5 years ago

When writing a software system, you face engineering tradeoffs, such as, how performant or reliable the system must be, how easy it must be to configure, how well documented it must be, under what conditions it needs to work, and so on. Furthermore, different components might have different requirements.

I think main problem with frameworks is that the engineering tradeoffs involved are not clearly stated. Many frameworks aim to solve all of them, and just let you "configure it as you need", but that is foolish. It's like when a scientific theory tries to explain everything, it cannot provide any prediction, because it cannot generalize at all from the data, as every deviation needs to be explained somehow. In the same way, a "universal framework" is an empty shell that, while it can be configured to do anything you want, the configuration itself becomes the work you would have to do, to tie the specific things you want to do in your system together. However, now you're doing it in framework's DSL and not the same language in which you wrote the specific things. This is a trap that many frameworks seem to fall into.

So if the framework you use is too universal, it doesn't add much value, which has to come from dealing with product-specific problems. Some contrast frameworks with libraries, where it is much harder to fall into this trap. If you add a library to your system, you have a good reason, it has to provide some value to justify itself. But framework is by definition the thing on which everything is supposed to stand on, so it's much easier for a kind of inversion happening and instead of framework supporting your software, it's your program that supports the framework.

I think what frameworkless movement wants is to have every product/system have its own framework, in the sense, the system's purpose determine what will the framework look like. I.e. your system is the one tying everything together (it just calls libraries for things), not some framework "alienated" from the problem you're trying to solve.

I am not sure I entirely agree but I think they have a point. I suspect it is possible to create a framework, but one has to be extremely aware of the interoperability requirements. Creating a framework is like creating an operating system, an environment where application programs run. And it's very good question, then, why use framework, as another layer from the operating system? Why not integrate with the OS itself? What does it bring to the table?

lars-b2018• 5 years ago

I read the article and the GitHub page, looking for specific examples that characterize their objectives. I believe they are on to something, but without specific illustrations, it is too abstract. Context matters in decisions, and I believe they are trying to say: just don't default to using a framework based on what you know (everything is React or Rails or...) but ask yourself "do I really need this for this project based on scope and maintainability?" Everything has a cost to it in a project and over time, and the bigger picture must be considered.

One itch I think it is trying to scratch is that often times frameworks stand in for a gap between what the core language and standard libraries support and what is required by the application. For example, web delivered applications have shifted from the traditional server rendered web interface, to single page applications. Web apps that act like applications have requirements that browsers out of the box don't support: often you need to have tables that can be sorted and shifted for example. There are not "native" javascript/DOM mechanisms for this. So enter third party code to facilitate. Which to choose from? In desktop applications, this facility is handled by the UI layer running on the OS. The JS/DOM doesn't provide it and so if you need it: roll your own, use a third party app, etc. But that has baggage you may not want: dependencies, potential security risks, and maintainability. So I think, at least in the web area, there is a gap in what people need for SPAs, and what the underlying JS/DOM provides.

yellowapple2• 5 years ago

One thing I've found over the years (particularly after pivoting away from web dev for awhile and toward ERP and WMS development) is that the data is ultimately what's going to drive everything. Consequently, my philosophy has kinda shifted away from a "let's build an app and bolt some DB onto it with an ORM" and more toward "let's build a DB (schema) and build the app around it". This has some implications:

- An ORM is rarely necessary or even desirable. If I'm using a SQL database, I'm very much inclined to stick with SQL (or maybe a thin ORM if it gives a lot of bang for my buck and stays true to SQL's semantics).

- I only really need or want about 10% of a web framework, and that's primarily routing and templates. Once I'm using SQL directly, it's pretty straightforward to just... query directly for exactly what I want to feed into a template, or feed (sanitized!) input directly into a prepared statement. Consequently, the "controllers" are basically just there for access control and maybe some caching.

- The database ends up being the thing driving business logic. This means actually writing triggers, functions/sprocs, etc. and letting the DB be in control of its data and the manipulation thereof.

- Hell, any SQL DB worth its salt these days can query and generate JSON directly. This means a REST API can exist almost entirely as sprocs, and the "web" part boils down entirely to "receive request, feed into sproc, return output".

The main downside of this (besides needing to be really comfortable with SQL) is that this approach puts more strain on the DB servers. Easy to fix, though: shift resources away from the web servers (ain't like they need it) and toward the DB servers.

sbayeta• 5 years ago

This is also what I do, working in the same business space (MRP for manufacturing) . I think it's a nice approach that let's you focus on the business problems at hand.

merricksb• 5 years ago

Discussed here 10 month ago:

https://news.ycombinator.com/item?id=23357921

dang• 5 years ago

There was also this—not sure if related:

Frameworkless JavaScript - https://news.ycombinator.com/item?id=7030628 - Jan 2014 (188 comments)

Frameworkless Movement

Related Stories