5 ms·

> 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. Happ

> 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.
  - Chris_Newton 11y ago
    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. If your background is mainly in modern JS development, that’s probably true. I don’t think it holds more widely, though. Modern JS lives a little bit in its own world, and the state of the art in that world is sometimes decades behind the wider programming industry. With the interest in things like React and Flux there has been a lot of discussion in the JS community recently about unidirectional data flow. However, the same sort of separation of input interactions from output rendering goes back to at least the 1970s and 1980s when ideas like MVC were being developed. Similarly, React and similar libraries get a lot of attention for the declarative way you can specify rendering and the relatively efficient way they update the DOM, but again we’ve had declarative UI libraries on the desktop for decades, and anyone who was doing graphics programming in the last millennium will be all too familiar with doing batched updates. It’s not much of a stretch to think that someone with a background building UIs in some of these other contexts might have different ideas to the current JS community about the architecture they want for their UI code, nor that some of those different ideas might be better for some projects than the mainstream today.
    - true_religion 11y ago
      I'm curious what peoples reaction would be to a framework/library that borrowed from Smalltalk's principles. With the current lineup of frameworks, there's a lot of effort made to remove state from the system in order to make it understandable and performant (which is reminiscent of how people talked about Haskel a few years ago). Yet with Smalltalk the entire language and tool base embraced the existence of state and gave you a lot of tooling to help make it manageable. To me, the main problem with frameworks such as Backbone/Angular 1 is that state was bidirectional and that anyone could attach event listeners on anything so your webpage was a network of state flow with none of that being transactional, nor guaranteeing that the system would come into a consistent/valid state. React is great with their unidirectional approach for rendering, but when a deeply embedded component makes a state change for itself it may logically have to effect the entire system. The current practice is to have top-down handling with Dispatchers/Stores (Flux), or pure reducers (Redux). Another approach would be to compartmentalize each component so actions can automatically bubble upwards where they are handled by whomever in the VirtualDOM tree can take up the task. This would do away with global dispatch, and make it easier to mix and match components. I think this approach has merit.
jwiley 11y ago
I second that emotion. I inherited an entire ecommerce platform built around Yahoo Store's proprietary RHTML language. The only documentation was a single comment: "RHTML turing complete?" I never did find out the answer to that, because I only lasted one month at the job. I'm sure it was a great learning exercise / psychotic breakdown for the original author.

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.
- Chris_Newton 11y ago
  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. If your background is mainly in modern JS development, that’s probably true. I don’t think it holds more widely, though. Modern JS lives a little bit in its own world, and the state of the art in that world is sometimes decades behind the wider programming industry. With the interest in things like React and Flux there has been a lot of discussion in the JS community recently about unidirectional data flow. However, the same sort of separation of input interactions from output rendering goes back to at least the 1970s and 1980s when ideas like MVC were being developed. Similarly, React and similar libraries get a lot of attention for the declarative way you can specify rendering and the relatively efficient way they update the DOM, but again we’ve had declarative UI libraries on the desktop for decades, and anyone who was doing graphics programming in the last millennium will be all too familiar with doing batched updates. It’s not much of a stretch to think that someone with a background building UIs in some of these other contexts might have different ideas to the current JS community about the architecture they want for their UI code, nor that some of those different ideas might be better for some projects than the mainstream today.
  - true_religion 11y ago
    I'm curious what peoples reaction would be to a framework/library that borrowed from Smalltalk's principles. With the current lineup of frameworks, there's a lot of effort made to remove state from the system in order to make it understandable and performant (which is reminiscent of how people talked about Haskel a few years ago). Yet with Smalltalk the entire language and tool base embraced the existence of state and gave you a lot of tooling to help make it manageable. To me, the main problem with frameworks such as Backbone/Angular 1 is that state was bidirectional and that anyone could attach event listeners on anything so your webpage was a network of state flow with none of that being transactional, nor guaranteeing that the system would come into a consistent/valid state. React is great with their unidirectional approach for rendering, but when a deeply embedded component makes a state change for itself it may logically have to effect the entire system. The current practice is to have top-down handling with Dispatchers/Stores (Flux), or pure reducers (Redux). Another approach would be to compartmentalize each component so actions can automatically bubble upwards where they are handled by whomever in the VirtualDOM tree can take up the task. This would do away with global dispatch, and make it easier to mix and match components. I think this approach has merit.

jwiley 11y ago

I second that emotion. I inherited an entire ecommerce platform built around Yahoo Store's proprietary RHTML language. The only documentation was a single comment: "RHTML turing complete?" I never did find out the answer to that, because I only lasted one month at the job. I'm sure it was a great learning exercise / psychotic breakdown for the original author.