4 ms·

I wonder if I will ever use a JavaScript framework. My projects are usually either in the form of "User enters data, sends it to the server, server sends a new

by mg 5y ago

I wonder if I will ever use a JavaScript framework. My projects are usually either in the form of "User enters data, sends it to the server, server sends a new page back" Example: https://www.gnoosic.com/faves https://www.gnoosic.com/faves Or in the form of "User changes parameters on screen, Javascript updates the screen accordingly". Example: https://www.productchart.com/laptops https://www.productchart.com/laptops In both cases, I don't see the benefit I would get from a framework. If you have built a project that is public and benefits from using a framework, I would love to see it!

hnlmorg 5y ago
I never use frameworks either. In fact the last site I published didn't have any Javascript at all (it's just a static site so shouldn't need it yet that doesn't seem to stop most other sites from abusive amounts of JS).
aurora72 5y ago
gnoosic.com/faves is cool but the Allmusic.com's related artists section is the ultimate place to discover new bands.
vmception 5y ago
Sure, probably works, just don't complain about age discrimination when you bring up nonconsensus things that have been superseded, and the team isnt fond of that system design
throwaway77384 5y ago
I also started out without frameworks and still prefer to work that way. However, I have found them to come in handy when solo-ing projects that require: - transpiling JS back into the stone age for compatibility - accessibility - seamless localisation I have found I just can't keep track of all of these things as well as React does. At the same time, I think React is a huge, dependency-laden mess, very difficult to learn (because it's changed its mind on how to do things about 100x, so no responses to issues on SO apply to your version of React, Redux, React Router, etc), slow as hell and probably overkill for most projects...
klabb3 5y ago
> Or in the form of "User changes parameters on screen, Javascript updates the screen accordingly". Once this gets a bit more complicated you have a bunch of state to keep track of and you have to make sure to re-render only the parts that have changed, and deref that parts that should be GCd. I'll happily take on a reactive UI framework dep if I can avoid writing my own diff pipeline. Not endorsing react by any means though.
taotau 5y 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 5y ago
  Your last paragraph is not a logical conclusion to your first two paragraph statements.
- bin_bash 5y 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 5y 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 5y 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.
dsego 5y ago
Working with other people and agreeing on how to do things is hard. The backend and frontend roles crystalized with a natural boundary between them being HTTP, one side doing HTML stuff, and the other defining URL endpoints (everything else is basically done by the ORM).
Hammershaft 5y ago
just wanted to say gnoosic is pretty great if I'm careful about choosing bands as an outer perimeter of a type of music I want to listen more to.

by mg 5y ago

hnlmorg 5y ago

I never use frameworks either. In fact the last site I published didn't have any Javascript at all (it's just a static site so shouldn't need it yet that doesn't seem to stop most other sites from abusive amounts of JS).

aurora72 5y ago

gnoosic.com/faves is cool but the Allmusic.com's related artists section is the ultimate place to discover new bands.

vmception 5y ago

Sure, probably works, just don't complain about age discrimination when you bring up nonconsensus things that have been superseded, and the team isnt fond of that system design

throwaway77384 5y ago

I also started out without frameworks and still prefer to work that way. However, I have found them to come in handy when solo-ing projects that require: - transpiling JS back into the stone age for compatibility - accessibility - seamless localisation I have found I just can't keep track of all of these things as well as React does. At the same time, I think React is a huge, dependency-laden mess, very difficult to learn (because it's changed its mind on how to do things about 100x, so no responses to issues on SO apply to your version of React, Redux, React Router, etc), slow as hell and probably overkill for most projects...

klabb3 5y ago

> Or in the form of "User changes parameters on screen, Javascript updates the screen accordingly". Once this gets a bit more complicated you have a bunch of state to keep track of and you have to make sure to re-render only the parts that have changed, and deref that parts that should be GCd. I'll happily take on a reactive UI framework dep if I can avoid writing my own diff pipeline. Not endorsing react by any means though.

taotau 5y 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 5y ago
Your last paragraph is not a logical conclusion to your first two paragraph statements.
bin_bash 5y 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 5y 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 5y 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.

dsego 5y ago

Working with other people and agreeing on how to do things is hard. The backend and frontend roles crystalized with a natural boundary between them being HTTP, one side doing HTML stuff, and the other defining URL endpoints (everything else is basically done by the ORM).

Hammershaft 5y ago

just wanted to say gnoosic is pretty great if I'm careful about choosing bands as an outer perimeter of a type of music I want to listen more to.