3 ms·

If you are not on a team and don't have any budget requirements, then sure. Do it all from scratch and in your own arbitrary flavored-way in your basement, then

If you are not on a team and don't have any budget requirements, then sure. Do it all from scratch and in your own arbitrary flavored-way in your basement, then write documentation later and put it on hacker news as the next great js framework to use out of plethora already there, then someone writes an article like this and places it on hacker news, then repeat the process again.

jwdunne 9y ago
I think we've had some of this on the backend too. I've seen "you don't need a framework" a few times outside of the current JS atmosphere. Seems like the easier it is to get going, the more frameworks you'll get. PHP is similar - a good whack of frameworks. The community has banded together, producing a group of developers, one from each major library or framework just so they can figure it out. It's called the Framework Interoperability Group and is responsible for the PSRs which have done a lot of good for the PHP ecosystem. JavaScript, I'm not sure you'd have the same luck simply because any interoperability group would need an arena or virtual equivalent just to start. That's ignoring the communication issues and length of decision making time.
- sebringj 9y ago
  I actually prefer coding by myself as I get to do my own thing but when it comes to working with teams, I strongly prefer a framework because its kind of like how religion helped form alliances or like how a river flows in the same direction. Its all arbitrary bullshit but helps reduce collisions and arguments. After all, highly documented, well tested bullshit, is much better than highly untested, no-documented bullshit.
  - jwdunne 9y ago
    Oh I agree. It's a good way to learn how something works. How do you become "good enough" to build production ready libraries that solve particular problems without practice solving said problems?
- LoSboccacc 9y ago
  That’s one of the reason I prefer libraries to franework and if at all possible core libraries get wrapped in access objects or delegates abd such - a library can be replaced if it gets discontinued or some issues arise down the road, a framework intwrtwine with your code too much and it’s a risky proposition for anything you plan to maintain for more than five years, i.e. devs who bet on angular. Don’t get me wrong I like the react structure for example and I see the value in having the whole foundations laid out and a strict structure to follow and they seem stable enough for a project, but there’s no way to use it and still maintain control over your code, they become one and if anything happens it’s either a rewrite or one of the purported drop in replacement or you have to get in the code or provide a bug report and wait for a release... and all that is incompatible with enterprise softwares with a sla.
- bpicolo 9y ago
  I'm not confident the PSRs have been all that great (Caching / HTTP in particular). They really lend themselves towards creating leaky abstraction. It didn't actually replace the adapter pattern anywhere, now you just get PSRX adapters for everything

jwdunne 9y ago

I think we've had some of this on the backend too. I've seen "you don't need a framework" a few times outside of the current JS atmosphere. Seems like the easier it is to get going, the more frameworks you'll get. PHP is similar - a good whack of frameworks. The community has banded together, producing a group of developers, one from each major library or framework just so they can figure it out. It's called the Framework Interoperability Group and is responsible for the PSRs which have done a lot of good for the PHP ecosystem. JavaScript, I'm not sure you'd have the same luck simply because any interoperability group would need an arena or virtual equivalent just to start. That's ignoring the communication issues and length of decision making time.

sebringj 9y ago
I actually prefer coding by myself as I get to do my own thing but when it comes to working with teams, I strongly prefer a framework because its kind of like how religion helped form alliances or like how a river flows in the same direction. Its all arbitrary bullshit but helps reduce collisions and arguments. After all, highly documented, well tested bullshit, is much better than highly untested, no-documented bullshit.
- jwdunne 9y ago
  Oh I agree. It's a good way to learn how something works. How do you become "good enough" to build production ready libraries that solve particular problems without practice solving said problems?
LoSboccacc 9y ago
That’s one of the reason I prefer libraries to franework and if at all possible core libraries get wrapped in access objects or delegates abd such - a library can be replaced if it gets discontinued or some issues arise down the road, a framework intwrtwine with your code too much and it’s a risky proposition for anything you plan to maintain for more than five years, i.e. devs who bet on angular. Don’t get me wrong I like the react structure for example and I see the value in having the whole foundations laid out and a strict structure to follow and they seem stable enough for a project, but there’s no way to use it and still maintain control over your code, they become one and if anything happens it’s either a rewrite or one of the purported drop in replacement or you have to get in the code or provide a bug report and wait for a release... and all that is incompatible with enterprise softwares with a sla.
bpicolo 9y ago
I'm not confident the PSRs have been all that great (Caching / HTTP in particular). They really lend themselves towards creating leaky abstraction. It didn't actually replace the adapter pattern anywhere, now you just get PSRX adapters for everything