5 ms·

If you aren't using a public framework and you use any JavaScript in your app then you are creating your own framework. Nothing wrong with that. The real value

by taotau 4y ago

If you aren't using a public framework and you use any JavaScript in your app then you are creating your own framework. Nothing wrong with that. The real value of public frameworks comes into play when you have more than one generation of developers working on your project. It's much easier to onboard a new developer onto a react app than it is to get them to understand the weird bespoke nuances of the conventions you came up with while hacking on your site at 3am 5 years ago.

Donckele 4y ago
Your last paragraph is not a logical conclusion to your first two paragraph statements.
bin_bash 4y ago
> If you aren't using a public framework and you use any JavaScript in your app then you are creating your own framework. Sorry but a “framework” used by one project (especially not broken out into a separate subproject) is not a framework. That’s just infra code. I think your point still stands that the value is developers understanding a framework can more quickly get to work—I’m just triggered by your exceedingly liberal usage of the word “framework”.
- biorach 4y ago
  > Sorry but a “framework” used by one project (especially not broken out into a separate subproject) is not a framework. That’s just infra code. Infra code that over time, as your app grows, takes on more and more of the features of a framework
mg 4y ago
This might hold true when the application in question does a lot of stuff covered by a framework. For example if it does routing, then it is nice to have common ground on how routing is done. If the application mostly does custom stuff, not covered by the framework, then the framework might harm more due to the added complexity. That is why I proposed a discussion based on real life examples. The other thing is that frameworks change. You picked React for your example. A currently popular framework. Chances are, the next developer will not come on in 5 years, but in 15 years. And does not know anything about React. Or about React as it is today. Then they might have a harder time understanding React than to understand a well written, minimalistic piece of Javascript.
- bluefirebrand 4y ago
  > Chances are, the next developer will not come on in 5 years, but in 15 years. That doesn't seem likely to me at all. More likely in the next 6 months than in 15 years. Why are you planning for 15 years out? The company you are working for might not be around in 15 years. Code might not even be recognizable in 15 years. All of our programs might be written by AI in 15 years. Optimizing for the short term makes way more sense to me. 2 or 3 years out, not 15.
  - Hackbraten 4y ago
    Human labor is expensive. Companies aren’t going to throw away a perfectly good asset they poured tens of millions in, unless they have to. I don’t see why a well-written, time-tested piece of software shouldn’t still be around 15 years down the road.
    - bluefirebrand 4y ago
      The initial comment was not about software quality but about "the popular framework now might not be popular in the future" I don't see any contradiction between creating well written, time tested software and also choosing currently popular frameworks to work in. If your React app is well written and stable and well tested, I see no reason it shouldn't be available in 15 years. And if you can't find React Developers to hire in 15 years to work on it, that's tough. Pay to have some trained. It is a similar situation to COBOL is today.
      - Hackbraten 4y ago
        Except that unlike React, COBOL doesn’t bring along 10000 dependencies written by 5000 different authors, randomly abandoned a few months later but teeming with unpatched vulnerabilities. Sure, somehow I’m going to find React developers 15 years from now to maintain my line-of-business React app but how secure will it be? One could argue that I can rewrite the framework-dependent parts. But rewrites cost money, too. I love new stuff but I still think that, depending on the app, it may make good economic sense to plan ahead for it to be useful after a decade or two.

by taotau 4y ago

Donckele 4y ago

Your last paragraph is not a logical conclusion to your first two paragraph statements.

bin_bash 4y ago

> If you aren't using a public framework and you use any JavaScript in your app then you are creating your own framework. Sorry but a “framework” used by one project (especially not broken out into a separate subproject) is not a framework. That’s just infra code. I think your point still stands that the value is developers understanding a framework can more quickly get to work—I’m just triggered by your exceedingly liberal usage of the word “framework”.

biorach 4y ago
> Sorry but a “framework” used by one project (especially not broken out into a separate subproject) is not a framework. That’s just infra code. Infra code that over time, as your app grows, takes on more and more of the features of a framework

mg 4y ago

This might hold true when the application in question does a lot of stuff covered by a framework. For example if it does routing, then it is nice to have common ground on how routing is done. If the application mostly does custom stuff, not covered by the framework, then the framework might harm more due to the added complexity. That is why I proposed a discussion based on real life examples. The other thing is that frameworks change. You picked React for your example. A currently popular framework. Chances are, the next developer will not come on in 5 years, but in 15 years. And does not know anything about React. Or about React as it is today. Then they might have a harder time understanding React than to understand a well written, minimalistic piece of Javascript.

bluefirebrand 4y ago
> Chances are, the next developer will not come on in 5 years, but in 15 years. That doesn't seem likely to me at all. More likely in the next 6 months than in 15 years. Why are you planning for 15 years out? The company you are working for might not be around in 15 years. Code might not even be recognizable in 15 years. All of our programs might be written by AI in 15 years. Optimizing for the short term makes way more sense to me. 2 or 3 years out, not 15.
- Hackbraten 4y ago
  Human labor is expensive. Companies aren’t going to throw away a perfectly good asset they poured tens of millions in, unless they have to. I don’t see why a well-written, time-tested piece of software shouldn’t still be around 15 years down the road.
  - bluefirebrand 4y ago
    The initial comment was not about software quality but about "the popular framework now might not be popular in the future" I don't see any contradiction between creating well written, time tested software and also choosing currently popular frameworks to work in. If your React app is well written and stable and well tested, I see no reason it shouldn't be available in 15 years. And if you can't find React Developers to hire in 15 years to work on it, that's tough. Pay to have some trained. It is a similar situation to COBOL is today.
    - Hackbraten 4y ago
      Except that unlike React, COBOL doesn’t bring along 10000 dependencies written by 5000 different authors, randomly abandoned a few months later but teeming with unpatched vulnerabilities. Sure, somehow I’m going to find React developers 15 years from now to maintain my line-of-business React app but how secure will it be? One could argue that I can rewrite the framework-dependent parts. But rewrites cost money, too. I love new stuff but I still think that, depending on the app, it may make good economic sense to plan ahead for it to be useful after a decade or two.