12 ms·

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the

by skewart 11y ago

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps the most valuable thing about frameworks is that they are common languages. They make it easier for developers to dive into a new code base and quickly understand what's going on. It's not entirely about functionality. I think this is partly why framework usage seems to be so trend and style driven; everyone wants to be using what everyone else is using.

andreasklinger 11y ago
imo: frameworks are materialized expectations given that software development is mainly about managing expectations this is of huge value
- skewart 11y ago
  "frameworks are materialized expectations" I like that. It's a nice way to put it.
- sebastianconcpt 11y ago
  Nice synthesis, you nailed it there
- k__ 11y ago
  Yes, they are like forced coding style guides.
stevewilhelm 11y ago
imo: frameworks are materialized experience, opinions, and testing.
- pluma 11y ago
  Specifically, code other people have written is code you don't have to write yourself. It's based on the experience of mistakes other people have made. If you write it yourself, you also have to make the same mistakes yourself (or have already made them in the past). If writing a framework is not a goal of the project, don't write your own framework. And few projects have the clear goal of writing a new framework (especially in addition to any other goals like creating a product).
capkutay 11y ago
This. If you are doing your own side project, building your own framework is a great way to sharpen your core software engineering skills. If you are architecting a product meant to scale, choosing a framework with significant mindshare, great documentation, and tons of learning materials and blogs supporting it is the right way to go. Frameworks are also supported by other frameworks. React/Redux has popular tools for debugging, logging, asynchronous operations, server-side rendering. I'm sure there are similar angular ecosystem frameworks as well.
- danbolt 11y ago
  The mindshare bit is an interesting one. I once read an article [1] that argued Lisp did not reach the same level of industrial popularity as other programming languages due to the fact that Lisp enables you to program in a lot of different ways for different reasons. I'm admittedly not very familiar with Lisp, and I don't know if I fully agree with the article, but it made me wonder if ease-of-collaboration can be considered a useful perk for languages/frameworks. [1] http://locklessinc.com/articles/why_lisp_failed/ http://locklessinc.com/articles/why_lisp_failed/
  - ashearer 11y ago
    I see parallels to PHP initially taking off for web development instead of Python via mod_python. Paradoxically, it was so much fun to build your own web framework in Python that everyone did, so none got enough traction. By the time Django finally broke through, PHP (with a good-enough mini-framework baked in) already dominated Python for web development, and the fragmentation of the Python world was arguably a contributing factor. Others adopted a third language because of a single mindshare-heavy framework, Rails.
    - basch 11y ago
      php was explicitly designed as a way to make dynamic web pages. it evolved from effort to achieve that goal. mod_python didnt come around until 2000. by then php4 was already out
cies 11y ago
I came here to say exactly this. I think that one thing to distinguish is: pick small yet popular libraries/frameworks that solve few and clearly defined problems and do that well. For comparison: I think React is (currently) still in the small category, I think Angular is waaay to big. This way you'll have tutorials, courses, books, stackexchange, educated talent, new features and bug fixes -- it all comes your way if you pick a popular-enough library.
- Bahamut 11y ago
  FWIW, Angular 2 will ultimately be a lot smaller than React - the Angular team seems to believe they can get the core library (similar to React in pure components, but allowing the user to access the AST itself for more flexibility for custom rendering engines for different platforms with less overhead) to under 10 KB minified & gzipped. This is probably since the dependency injection, router, http, web worker, service worker, and testing modules will be properly split off at some point, as well as the polyfills. That leaves the necessary polyfills as zone.js (as of a couple of days ago a presented Stage 0 proposal), rx.js (the ES7 Observables proposal), reflect-metadata (ES7 decorator proposal), & an ES6 shim, and the necessary non-polyfill dependency of DI - all of these are pretty light. Otherwise, I pretty much agree with the benefits of choosing a popular library/framework. The homebrewed HTML generation in the original article was quite painful to read, and if all someone is interested in is to figure out the HTML structure and how CSS interplays with it to style it appropriately, this pattern will fail fast. Angular, Ember, and React (or whatever popular/semi-popular library/framework) allow for much better template expression than this. In addition, typing out all of that is tedious - repeating stuff like document.createElement every time will get old fast. One will then want to create a custom HTML rendering method that generates the appropriate DOM node depending on the string passed to the function. Then one will start trying to figure out optimizations since it turns out raw DOM generation/manipulation has surprising performance issues in some situations...at which point, one encounters what Angular 2, React, and virtual-dom have all encountered & largely solved. This doesn't even get into various other optimizations, such as using document.createDocumentFragment, creating a caching strategy, avoiding unnecessary node generation, etc., or writing the components such that they cannot be optimized by leveraging web workers. It may be a fun academic exercise to create a rendering library, but in practice it is difficult to create a robust solution, especially one that works for a team. Doing a rough cost-benefit analysis, this path is seldom a fruitful use of one's time, unless one enjoys such forays & solving these problems.
brightball 11y ago
100% agree on the common language front. The real challenge is when you're dealing with a language that has framework saturation, so there isn't really a "common" framework. Ruby and Python have Rails and Django which goes a LOOOOONG way in fixing this problem. Not many languages have that one, dominant framework and usually that's because people keep inventing new ones to deal with shortcomings of current ones OR that the frameworks do so little on top of what the language already offers that it's easy to create your own. Javascript and PHP are clear cut cases for the latter since both languages are out of the box built for the web. jQuery was the last real unification in the Javascript world. I don't entirely care which framework becomes dominant as much as I just want A framework to become dominant. React looks like it is gaining that momentum, but you immediately see the problem play out when there's a thread about how great React is followed by 100 "X is better because it doesn't handle Y the way that React does" followed by another post about how "X is worse because of the way it handles Y". There's something about the Javascript world that seems ready to create new frameworks instead of contributing to existing ones. I took a sales class years ago and the biggest takeaway from it was "People buy pain relief". jQuery was dominant because it solved a huge pain point, cross browser compatibility, in a way that made natural sense for people working in the browser by using CSS references...AND it was built to run side by side with any other JS library (Prototype, Mootools, etc) so you could safely invest in learning it and know you'd be able to use it on any project that came along. During a time when IE6 compatibility was a big deal this was huge. During a time when a lot of people were trying to solve the problem and you'd inevitably end up on a project that chose one of the other dozen options, side by side compatibility was huge. These were major points of pain relief that jQuery brought to the table and that's how it won.
- m0dc 11y ago
  The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and micro-libs are introduced every couple of months. I'm really hoping that one of these React dialects will win out soon, as it's not really a "common language" until everything is mutually intelligible.
Tloewald 11y ago
Some frameworks let you stand on the shoulders of giants; others are kind of like being stood on by giants. Many of the Javascript frameworks I've seen seen -- especially those written by people who prefer Java to Javascript -- seem to be in the latter category.
up_and_up 11y ago
> Instead of learning a new framework I wrote my own. Hands down, the worst code I have ever inherited from another developer is in a scenario like this. Happened to me a bunch of times. Worst ever was a former boss who didnt "trust" Prototype.js nor jQuery and decided to write his own version. Pure hell. Please be kind to your fellow programmer brethren. Unless the problem you are trying to solve is uber simple and obvious or you are just "doing it for fun/knowledge/etc", find a well-adopted framework, with good documentation and get to work.
- mstade 11y ago
  I don't know, I think this "use what's out there" mentality gets out of hand at times, and at least makes me kind of depressed. For sure, I think you should use whatever is available if the only reasons you want to roll your own tooling basically comes down to syntax or "but it feels nicer" kind of arguments – that's like reinventing screwdrivers because the handle of one gave you a blister that one time when you were using it wrong. But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. That's how we progress, by challenging the status quo. Apologies for the incoherent rant, I hope the point gets across anyway.
  - cloverich 11y ago
    > But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. My view on this is that generally if you haven't extensively used at least a couple of existing frameworks, it seems unlikely you'll do anything than re-invent existing stuff (at best) in a slightly different fashion. But otherwise I definitely agree the "use whats out there" gets way out of hand -- but for me this is mostly for relatively straight forward stuff.
BurningFrog 11y ago
OTOH, another common trap is to grab a framework for everything. If you only need 2% of what a major framework offers, you are probably better off writing your own code that does exactly what you need. "...and in the future, we can use all these other parts of the framework" is the mental error. This is YAGNI in minor disguise!

by skewart 11y ago

andreasklinger 11y ago

imo: frameworks are materialized expectations given that software development is mainly about managing expectations this is of huge value

skewart 11y ago
"frameworks are materialized expectations" I like that. It's a nice way to put it.
sebastianconcpt 11y ago
Nice synthesis, you nailed it there
k__ 11y ago
Yes, they are like forced coding style guides.

stevewilhelm 11y ago

imo: frameworks are materialized experience, opinions, and testing.

pluma 11y ago
Specifically, code other people have written is code you don't have to write yourself. It's based on the experience of mistakes other people have made. If you write it yourself, you also have to make the same mistakes yourself (or have already made them in the past). If writing a framework is not a goal of the project, don't write your own framework. And few projects have the clear goal of writing a new framework (especially in addition to any other goals like creating a product).

capkutay 11y ago

This. If you are doing your own side project, building your own framework is a great way to sharpen your core software engineering skills. If you are architecting a product meant to scale, choosing a framework with significant mindshare, great documentation, and tons of learning materials and blogs supporting it is the right way to go. Frameworks are also supported by other frameworks. React/Redux has popular tools for debugging, logging, asynchronous operations, server-side rendering. I'm sure there are similar angular ecosystem frameworks as well.

danbolt 11y ago
The mindshare bit is an interesting one. I once read an article [1] that argued Lisp did not reach the same level of industrial popularity as other programming languages due to the fact that Lisp enables you to program in a lot of different ways for different reasons. I'm admittedly not very familiar with Lisp, and I don't know if I fully agree with the article, but it made me wonder if ease-of-collaboration can be considered a useful perk for languages/frameworks. [1] http://locklessinc.com/articles/why_lisp_failed/ http://locklessinc.com/articles/why_lisp_failed/
- ashearer 11y ago
  I see parallels to PHP initially taking off for web development instead of Python via mod_python. Paradoxically, it was so much fun to build your own web framework in Python that everyone did, so none got enough traction. By the time Django finally broke through, PHP (with a good-enough mini-framework baked in) already dominated Python for web development, and the fragmentation of the Python world was arguably a contributing factor. Others adopted a third language because of a single mindshare-heavy framework, Rails.
  - basch 11y ago
    php was explicitly designed as a way to make dynamic web pages. it evolved from effort to achieve that goal. mod_python didnt come around until 2000. by then php4 was already out

cies 11y ago

I came here to say exactly this. I think that one thing to distinguish is: pick small yet popular libraries/frameworks that solve few and clearly defined problems and do that well. For comparison: I think React is (currently) still in the small category, I think Angular is waaay to big. This way you'll have tutorials, courses, books, stackexchange, educated talent, new features and bug fixes -- it all comes your way if you pick a popular-enough library.

Bahamut 11y ago
FWIW, Angular 2 will ultimately be a lot smaller than React - the Angular team seems to believe they can get the core library (similar to React in pure components, but allowing the user to access the AST itself for more flexibility for custom rendering engines for different platforms with less overhead) to under 10 KB minified & gzipped. This is probably since the dependency injection, router, http, web worker, service worker, and testing modules will be properly split off at some point, as well as the polyfills. That leaves the necessary polyfills as zone.js (as of a couple of days ago a presented Stage 0 proposal), rx.js (the ES7 Observables proposal), reflect-metadata (ES7 decorator proposal), & an ES6 shim, and the necessary non-polyfill dependency of DI - all of these are pretty light. Otherwise, I pretty much agree with the benefits of choosing a popular library/framework. The homebrewed HTML generation in the original article was quite painful to read, and if all someone is interested in is to figure out the HTML structure and how CSS interplays with it to style it appropriately, this pattern will fail fast. Angular, Ember, and React (or whatever popular/semi-popular library/framework) allow for much better template expression than this. In addition, typing out all of that is tedious - repeating stuff like document.createElement every time will get old fast. One will then want to create a custom HTML rendering method that generates the appropriate DOM node depending on the string passed to the function. Then one will start trying to figure out optimizations since it turns out raw DOM generation/manipulation has surprising performance issues in some situations...at which point, one encounters what Angular 2, React, and virtual-dom have all encountered & largely solved. This doesn't even get into various other optimizations, such as using document.createDocumentFragment, creating a caching strategy, avoiding unnecessary node generation, etc., or writing the components such that they cannot be optimized by leveraging web workers. It may be a fun academic exercise to create a rendering library, but in practice it is difficult to create a robust solution, especially one that works for a team. Doing a rough cost-benefit analysis, this path is seldom a fruitful use of one's time, unless one enjoys such forays & solving these problems.

brightball 11y ago

100% agree on the common language front. The real challenge is when you're dealing with a language that has framework saturation, so there isn't really a "common" framework. Ruby and Python have Rails and Django which goes a LOOOOONG way in fixing this problem. Not many languages have that one, dominant framework and usually that's because people keep inventing new ones to deal with shortcomings of current ones OR that the frameworks do so little on top of what the language already offers that it's easy to create your own. Javascript and PHP are clear cut cases for the latter since both languages are out of the box built for the web. jQuery was the last real unification in the Javascript world. I don't entirely care which framework becomes dominant as much as I just want A framework to become dominant. React looks like it is gaining that momentum, but you immediately see the problem play out when there's a thread about how great React is followed by 100 "X is better because it doesn't handle Y the way that React does" followed by another post about how "X is worse because of the way it handles Y". There's something about the Javascript world that seems ready to create new frameworks instead of contributing to existing ones. I took a sales class years ago and the biggest takeaway from it was "People buy pain relief". jQuery was dominant because it solved a huge pain point, cross browser compatibility, in a way that made natural sense for people working in the browser by using CSS references...AND it was built to run side by side with any other JS library (Prototype, Mootools, etc) so you could safely invest in learning it and know you'd be able to use it on any project that came along. During a time when IE6 compatibility was a big deal this was huge. During a time when a lot of people were trying to solve the problem and you'd inevitably end up on a project that chose one of the other dozen options, side by side compatibility was huge. These were major points of pain relief that jQuery brought to the table and that's how it won.

m0dc 11y ago
The problem with coalescing around React is that it's not really a framework. The lack of a default Rails-like monolith encourages every dev to assemble their project from a la carte pieces - so every React app has a different project structure, a different data library, a different build tool, etc. Even worse: since everyone wants to build their app "the right way", there's constant churn as new best practices and micro-libs are introduced every couple of months. I'm really hoping that one of these React dialects will win out soon, as it's not really a "common language" until everything is mutually intelligible.

Tloewald 11y ago

Some frameworks let you stand on the shoulders of giants; others are kind of like being stood on by giants. Many of the Javascript frameworks I've seen seen -- especially those written by people who prefer Java to Javascript -- seem to be in the latter category.

up_and_up 11y ago

> Instead of learning a new framework I wrote my own. Hands down, the worst code I have ever inherited from another developer is in a scenario like this. Happened to me a bunch of times. Worst ever was a former boss who didnt "trust" Prototype.js nor jQuery and decided to write his own version. Pure hell. Please be kind to your fellow programmer brethren. Unless the problem you are trying to solve is uber simple and obvious or you are just "doing it for fun/knowledge/etc", find a well-adopted framework, with good documentation and get to work.

mstade 11y ago
I don't know, I think this "use what's out there" mentality gets out of hand at times, and at least makes me kind of depressed. For sure, I think you should use whatever is available if the only reasons you want to roll your own tooling basically comes down to syntax or "but it feels nicer" kind of arguments – that's like reinventing screwdrivers because the handle of one gave you a blister that one time when you were using it wrong. But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. That's how we progress, by challenging the status quo. Apologies for the incoherent rant, I hope the point gets across anyway.
- cloverich 11y ago
  > But if you have different ideas about how to structure things, come up with new abstractions that you find solve the problems at hand better than any of the abstractions available to you, then by all means do roll your own. We don't need more clones, but we do need fresh thinking and ideas that don't follow the pack. My view on this is that generally if you haven't extensively used at least a couple of existing frameworks, it seems unlikely you'll do anything than re-invent existing stuff (at best) in a slightly different fashion. But otherwise I definitely agree the "use whats out there" gets way out of hand -- but for me this is mostly for relatively straight forward stuff.

BurningFrog 11y ago

OTOH, another common trap is to grab a framework for everything. If you only need 2% of what a major framework offers, you are probably better off writing your own code that does exactly what you need. "...and in the future, we can use all these other parts of the framework" is the mental error. This is YAGNI in minor disguise!