9 ms·

Frameworkless Movement

45 points by WolfOliver 6y ago

bckr 6y 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-frameworkless https://github.com/frameworkless-movement/awesome-frameworkl...
- Xeronate 6y 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.
  - bckr 6y 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 6y 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, ...
- brylie 6y 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 6y ago
    > For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead. You cannot seriously believe this.
    - brylie 6y ago
      For example, some Django projects implement only a REST interface. Since those projects don't rely on HTML templates, they don't likely incur any runtime costs from Django's template modules. In effect, you can choose which parts of the Django project you import. The parts you don't import aren't likely to get in your way. I think this is generally true for modular software.
  - setr 6y 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.
    - fermienrico 6y ago
      On the other side of the fence: Your own shitty framework owns your code, it locks you into this custom frankenstine thing that is a ball of mud that also smells bad. No one wants to look at it, it brings the best developers to their knees and the docs are impossible to relate to. One dude knows how it works and the tech debt is deep. I'll take a Django project instead, thank you very much. This is an age old discussion about appropriate abstraction.
usbzcable 6y ago
See also https://eheikes.github.io/use-the-platform-talk/ https://eheikes.github.io/use-the-platform-talk/
gherkinnn 6y ago
I see it as a good exercise to discover why frameworks make sense. And then you build stuff using a framework.
arcturus17 6y 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?
- sputr 6y 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).
  - deleted 6y ago
    [deleted]
  - omniscient_oce 6y 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)
tpetry 6y 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 6y 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 6y ago
Let's ditch the standard libraries too
ekvilibrist 6y 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 6y 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.
naranha 6y 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.
- dnautics 6y 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.
  - naranha 6y 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.
    - dnautics 6y ago
      Why is the distinction harder? Node is a framework.
  - undecisive 6y 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.
  - bckr 6y ago
jiriknesl 6y 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 6y ago
  > Microservices led to the growth of devstacks that has replaced frameworks a lot. You are just replacing one framework with another (Kubernetes).
  - js8 6y 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?
- Xeronate 6y 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).
  - abunuwas 6y 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 6y 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!
- undecisive 6y 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 6y ago
This is like applied Dunning-Kruger
the-dude 6y 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 6y 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 6y 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 6y ago
  Good thing then that React is a library and not a framework. :) (only slight sarcasm)
  - undecisive 6y 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 6y 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 6y 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-toast 6y ago
Let's create more work for ourselves! Reinvent the wheel for every project!
void_mint 6y 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 6y 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 6y 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_ 6y 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 6y 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 6y ago
I mostly agreed with this sentiment, but how do you get composable, declarative DOM components without a framework?
js8 6y 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 6y 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.
yellowapple 6y 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 6y 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 6y ago
Discussed here 10 month ago: https://news.ycombinator.com/item?id=23357921 https://news.ycombinator.com/item?id=23357921
- dang 6y ago
  There was also this—not sure if related: Frameworkless JavaScript - https://news.ycombinator.com/item?id=7030628 https://news.ycombinator.com/item?id=7030628 - Jan 2014 (188 comments)

45 points by WolfOliver 6y ago

bckr 6y 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-frameworkless https://github.com/frameworkless-movement/awesome-frameworkl...

Xeronate 6y 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.
- bckr 6y 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 6y 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, ...

brylie 6y 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 6y ago
  > For the most part, the aspects of a framework that go unused typically don't introduce runtime overhead. You cannot seriously believe this.
  - brylie 6y ago
    For example, some Django projects implement only a REST interface. Since those projects don't rely on HTML templates, they don't likely incur any runtime costs from Django's template modules. In effect, you can choose which parts of the Django project you import. The parts you don't import aren't likely to get in your way. I think this is generally true for modular software.
- setr 6y 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.
  - fermienrico 6y ago
    On the other side of the fence: Your own shitty framework owns your code, it locks you into this custom frankenstine thing that is a ball of mud that also smells bad. No one wants to look at it, it brings the best developers to their knees and the docs are impossible to relate to. One dude knows how it works and the tech debt is deep. I'll take a Django project instead, thank you very much. This is an age old discussion about appropriate abstraction.

usbzcable 6y ago

See also https://eheikes.github.io/use-the-platform-talk/ https://eheikes.github.io/use-the-platform-talk/

gherkinnn 6y ago

I see it as a good exercise to discover why frameworks make sense. And then you build stuff using a framework.

arcturus17 6y 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?

sputr 6y 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).
- deleted 6y ago
  [deleted]
- omniscient_oce 6y 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)

tpetry 6y 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 6y 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 6y ago

Let's ditch the standard libraries too

ekvilibrist 6y 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 6y 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.

naranha 6y 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.

dnautics 6y 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.
- naranha 6y 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.
  - dnautics 6y ago
    Why is the distinction harder? Node is a framework.
- undecisive 6y 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.
- bckr 6y ago

jiriknesl 6y 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 6y ago
> Microservices led to the growth of devstacks that has replaced frameworks a lot. You are just replacing one framework with another (Kubernetes).
- js8 6y 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?
Xeronate 6y 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).
- abunuwas 6y 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 6y 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!

undecisive 6y 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 6y ago

This is like applied Dunning-Kruger

the-dude 6y 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 6y 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 6y 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 6y ago
Good thing then that React is a library and not a framework. :) (only slight sarcasm)
- undecisive 6y 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 6y 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 6y 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-toast 6y ago

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

void_mint 6y 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 6y 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 6y 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_ 6y 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 6y 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 6y ago

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

js8 6y 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 6y 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.

yellowapple 6y 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 6y 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 6y ago

Discussed here 10 month ago: https://news.ycombinator.com/item?id=23357921 https://news.ycombinator.com/item?id=23357921

dang 6y ago
There was also this—not sure if related: Frameworkless JavaScript - https://news.ycombinator.com/item?id=7030628 https://news.ycombinator.com/item?id=7030628 - Jan 2014 (188 comments)