4 ms·

The issue I have with this is that these apps are not all doing the same thing. You are not required to use models in Backbone, especially for such a trivial e

by TrisMcC 12y ago

The issue I have with this is that these apps are not all doing the same thing. You are not required to use models in Backbone, especially for such a trivial example. You aren't using an equivalent of models in the vanilla JS example. You aren't required to listen to change events to render anything. Here is a simple Backbone view doing an equivalent to what the vanilla JS example is doing: http://jsfiddle.net/TrisMcC/DKB27/ http://jsfiddle.net/TrisMcC/DKB27/

untog 12y ago
This is the fundamental flaw in comparisons like this that take frameworks designed for huge projects and demonstrate them with a mini-project. Of course the Backbone example looks over the top. And compared to all of them the vanilla JS looks like an example of beautiful simplicity. But try making a full webapp using vanilla JS and you'll find things get very messy, very fast. Never mind the fact that the entire point of frameworks like React is that they're performant with a lot of DOM changes being made frequently. Making a demo that shows it altering one text box isn't really very useful.
- dharbin 12y ago
  I disagree. You can write robust, clean, modular, and scalable code without a framework. If you need a framework to help you "stay within the lines" or speed up development, then by all means. But I've built large JS systems with vanilla js + jquery + requirejs just fine.
  - untog 12y ago
    Easier for a single person to do. But with decent sized group you're going to find yourself having to establish all sorts of patterns anyway... which are exactly the patterns a framework provides.
  - lomnakkus 12y ago
    Are you familiar with the idea of the Turing Tarpit? We have a similar thing here: The issue isn't whether you can do X with/without framework Y. It's whether framework X is more cost effective vs. framework Z (or no framework): Does it require less/more boilerplate? Is it less/more error-prone? Does it mean that more/less experience is needed to do the right thing? Does it mean that testing becomes harder/easier? &c.
  - Joeri 12y ago
    Any non-trivially sized software system will use a framework to avoid code duplication. You can either choose someone else's framework, or roll your own, but unless you're a framework design wizard you're unlikely to build an all-purpose web dev framework which beats the well known ones. Which is to say that I definitely recommend that everyone at some point develop their own all-purpose framework, because it's a great learning experience, but if they're doing production work they should stick to one of the existing ones, even if it's just so other developers will have an easier time understanding the codebase.
    - mattgreenrocks 12y ago
      How do you explain the mountains of code written before the great frameworks saved us all? Is it all bad? Is it all an ad-hoc framework? On all of the framework-less projects I've worked on, what emerged was significantly better than a framework: it was a real domain model that was decoupled from all of the irrelevant technical details. I know, nobody does that cause it's hard. The frameworks certainly don't help. You can write great software without MVC, or frameworks, or OOP. Frameworks are often crutches for people's anemic design skills. They're not nearly as important as everyone thinks. You can easily coordinate multiple people working by, you know, sketching out an architecture amenable to he division of labor.
      - Joeri 12y ago
        Yes, it is all an ad-hoc framework. There are no large frameworkless projects. Programming languages don't come with enough abstraction to model a large domain (unless you're using a 4gl, but those are semi-frameworks). You always end up building or reusing additional abstractions, and those collectively are a framework. The framework can be procedural, functional, declarative, oop, mvc, or any of dozens of additional buzzwords, but you cannot avoid having one. Anyway, my point is that if you're working on a non-trivial solution in a problem domain that other people with good design skills have built frameworks for (like web dev, the most oversolved domain in software, aside from text editing), it doesn't make economic sense to roll your own. Even if you have the rare trait of good design, the productivity benefit for yourself by having a more closely adapted framework is washed away by the cost of building it and having to bring other people up to speed on it. I've had the experience of lots of home-grown framework code, and rolled my own quite a few times, and the longer i've had to observe other developers working on that code the more convinced i've become of NIH being a programming anti-pattern. It can make sense to roll your own, but for the majority of web dev programming it doesn't. There may be categories of software dev where the statement inverts though, i'm not going to generalize too far. What i however also think is that many of today's frameworks are overengineered and force you to write too much code to solve a problem. They suffer from tdd-induced design damage, as dhh would describe it (the recent discussion between fowler, beck and dhh was enlightening). Many frameworks have optimized for secondary goals like orthogonality or compliance to design patterns instead of primary goals like fitness for purpose, speed of development, maintainability, and usability of the resulting product. However, i'm of the opinion that even given all that, for general web dev and for most people, it's better to use one of the common ones than to roll their own. They'll build a more maintainable solution in less time.
NVI 12y ago
Article author here. Good point. I could use better wording. The message that I was trying to convey was: You can use Backbone models but please don’t do it like this. Backbone doesn’t do DOM diffing like React; you’ll shoot yourself in a foot.

by TrisMcC 12y ago

untog 12y ago

This is the fundamental flaw in comparisons like this that take frameworks designed for huge projects and demonstrate them with a mini-project. Of course the Backbone example looks over the top. And compared to all of them the vanilla JS looks like an example of beautiful simplicity. But try making a full webapp using vanilla JS and you'll find things get very messy, very fast. Never mind the fact that the entire point of frameworks like React is that they're performant with a lot of DOM changes being made frequently. Making a demo that shows it altering one text box isn't really very useful.

dharbin 12y ago
I disagree. You can write robust, clean, modular, and scalable code without a framework. If you need a framework to help you "stay within the lines" or speed up development, then by all means. But I've built large JS systems with vanilla js + jquery + requirejs just fine.
- untog 12y ago
  Easier for a single person to do. But with decent sized group you're going to find yourself having to establish all sorts of patterns anyway... which are exactly the patterns a framework provides.
- lomnakkus 12y ago
  Are you familiar with the idea of the Turing Tarpit? We have a similar thing here: The issue isn't whether you can do X with/without framework Y. It's whether framework X is more cost effective vs. framework Z (or no framework): Does it require less/more boilerplate? Is it less/more error-prone? Does it mean that more/less experience is needed to do the right thing? Does it mean that testing becomes harder/easier? &c.
- Joeri 12y ago
  Any non-trivially sized software system will use a framework to avoid code duplication. You can either choose someone else's framework, or roll your own, but unless you're a framework design wizard you're unlikely to build an all-purpose web dev framework which beats the well known ones. Which is to say that I definitely recommend that everyone at some point develop their own all-purpose framework, because it's a great learning experience, but if they're doing production work they should stick to one of the existing ones, even if it's just so other developers will have an easier time understanding the codebase.
  - mattgreenrocks 12y ago
    How do you explain the mountains of code written before the great frameworks saved us all? Is it all bad? Is it all an ad-hoc framework? On all of the framework-less projects I've worked on, what emerged was significantly better than a framework: it was a real domain model that was decoupled from all of the irrelevant technical details. I know, nobody does that cause it's hard. The frameworks certainly don't help. You can write great software without MVC, or frameworks, or OOP. Frameworks are often crutches for people's anemic design skills. They're not nearly as important as everyone thinks. You can easily coordinate multiple people working by, you know, sketching out an architecture amenable to he division of labor.
    - Joeri 12y ago
      Yes, it is all an ad-hoc framework. There are no large frameworkless projects. Programming languages don't come with enough abstraction to model a large domain (unless you're using a 4gl, but those are semi-frameworks). You always end up building or reusing additional abstractions, and those collectively are a framework. The framework can be procedural, functional, declarative, oop, mvc, or any of dozens of additional buzzwords, but you cannot avoid having one. Anyway, my point is that if you're working on a non-trivial solution in a problem domain that other people with good design skills have built frameworks for (like web dev, the most oversolved domain in software, aside from text editing), it doesn't make economic sense to roll your own. Even if you have the rare trait of good design, the productivity benefit for yourself by having a more closely adapted framework is washed away by the cost of building it and having to bring other people up to speed on it. I've had the experience of lots of home-grown framework code, and rolled my own quite a few times, and the longer i've had to observe other developers working on that code the more convinced i've become of NIH being a programming anti-pattern. It can make sense to roll your own, but for the majority of web dev programming it doesn't. There may be categories of software dev where the statement inverts though, i'm not going to generalize too far. What i however also think is that many of today's frameworks are overengineered and force you to write too much code to solve a problem. They suffer from tdd-induced design damage, as dhh would describe it (the recent discussion between fowler, beck and dhh was enlightening). Many frameworks have optimized for secondary goals like orthogonality or compliance to design patterns instead of primary goals like fitness for purpose, speed of development, maintainability, and usability of the resulting product. However, i'm of the opinion that even given all that, for general web dev and for most people, it's better to use one of the common ones than to roll their own. They'll build a more maintainable solution in less time.

NVI 12y ago

Article author here. Good point. I could use better wording. The message that I was trying to convey was: You can use Backbone models but please don’t do it like this. Backbone doesn’t do DOM diffing like React; you’ll shoot yourself in a foot.