5 ms·

Tester: The UI is wrong right here... Developer: Hmm...I wonder how long it's going to take me to figure out where that HTML was generated in my javascript.

polskibus 12y ago
Did you see this tool ? I find it quite helpful for debugging JSX and finding the root of the problem. http://facebook.github.io/react/blog/2014/01/02/react-chrome-developer-tools.html http://facebook.github.io/react/blog/2014/01/02/react-chrome...
Zelphyr 12y ago
You hit the nail on the head why these things are bad. You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality. These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of code together. Or you can become a master software developer and build something of quality without needing a crutch like a framework. Now, if the needs of the project are such that a framework will suffice then by all means, use a framework. Chances are, if you're doing more than building a working prototype then at some point a framework is going to fail you. If you enjoy building apps using frameworks then by all means, do it. But to my mind you're doing your customer a disservice. Contrast that with great software developers (and I've been fortunate to have worked with some really great developers) who abhor these frameworks. They can get more done with less code and ultimately deliver the project faster without frameworks. The tradeoff is that it takes time and dedication to achieve that level of mastery. I personally would prefer that path.
- aquark 12y ago
  Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors. The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.
  - Zelphyr 12y ago
    I disagree that its frameworks all the way down. There is a distinction between frameworks and libraries. React, Angular, et al are frameworks in the truest sense of the word. Things like jQuery and Underscore on down to stdio.h are libraries. You can pick and choose from what they contain but they're not so tightly coupled that they get in your way. They're a tool belt with tools that do one thing and do it really well. Frameworks are like having a tool belt with a hammer that also has a saw on the end but in order to use the saw you have to grab the screwdriver even if you're not actually using it.
    - saraid216 12y ago
      I'm curious which part of React you consider the hammer and which part you consider the screwdriver.
    - wickchuck 12y ago
      I would argue that React is closer to a library than a framework. It's a small library with some useful functions for making web components. It helps by removing a bunch of boilerplate code that you would have to re-write with each new app. The thing that it doesn't do is hold you hand and tell you exactly the way things should be done as some of the other frameworks do.
    - mercer 12y ago
      Thanks for pointing out the distinction. I forget about that sometimes. That said, React is a "A Javascript Library for Building User Interfaces." And to me me it does feel more like a library than a framework.
    - modarts 12y ago
      React is a library, plain and simple. It has literally no opinions on even basic stuff like routing, or how to manage application data. It takes your data as an input and by some mechanism lays out a visual representation of it defined by your components render methods, being sure to update the visual representation as the data changes. The rest are implementation details.
  - 12y ago
- mercer 12y ago
  I never quite understand arguments like yours. As aquark pointed out, it's 'frameworks all the way down' anyways. Unless you're a one-of-a-kind master, you're always relying on multiple levels of abstraction. I don't know who pointed it out, but I find that a good rule of thumb is to master at least one layer of abstraction below the 'current' one. So in the case of React, you'd first make sure you are proficient with javascript, the DOM, and how the web works. If your point is to underline that using frameworks without understanding them is a bad thing, I fully agree. But arguing that 'these things' (frameworks) are bad just seems silly. Clearly some clever people at Facebook found it useful to abstract certain things in a certain way, and many other people (some clever) like their approach. They've actively considered IanDrake's problem (in fact, they talk about this in their talk on React), and felt that their solution was good. If I can build a performant client-side-heavy web-app in half the time because of React, I'm doing the client a service, not a disservice.
  - Zelphyr 12y ago
    Here's my experience with frameworks: They're really good at getting you to 80% completion really fast. The next 10% takes a little work but its doable. But that last 10%... its like pulling teeth. With tweezers. Covered in grease. That last 10% is the thing you need done to successfully deliver the project but which the framework designers didn't consider. In my experience you always run into that last 10%. The net result is that all those speed gains you realized early on are completely lost (and then some) because you're fighting with the framework. So sure, understanding the framework might help you with that last 10%. But I personally think you're better served mastering JS, the DOM, and how the web works. Which really isn't that hard by the way! And anyway, if frameworks were so great why are there so many? It seems like a new framework gets announced every week here on HN. The shear tonnage of frameworks alone makes me question their value[1]. Now if none of that can convince you, consider this; the company I work for got rid of all their framework programmers and replaced them with me and a couple other software developers who have experience building products without using frameworks. And they pay us more money than they paid the framework programmers. Why? Because we did more work with better quality in the first six months than those other guys could do in 2 years of gluing framework code together. That last 10% hit them HARD and cost them their damn jobs! 1: I do recognize that frameworks provide value. My argument is that they are way overused. Great for building working or semi-working prototypes in order to test an idea in the market. Terrible for building anything that needs to be continuously maintained.
- chenglou 12y ago
  React is a paradigm with only one existing implementation. Ranting against frameworks represented by React is a strawman here. It doesn't include a router, nor a model layer, nor the traditional controller. It's a miracle that it's even compared to Angular and Ember, but I guess that's the extent of the power of View + solid declarative nature, so we'll take it as a compliment. We also don't want to turn it into a huge framework, so if that's your only concern here, then please feel free to give it a try =).
runaway 12y ago
I think tools like React actually make debugging situations like this easier. Instead of trying to figure out what actions a user took that manipulated the DOM with jQuery n times, I can take an exact snapshot of the state of the application and walk through how it is being rendered.
baddox 12y ago
Your comment implies that you recommend web apps never do any DOM generation or manipulation using JavaScript, and are instead purely static HTML documents. For that matter, your argument would logically extend to opposing backend HTML generation as well, like Rails templates.
- IanDrake 12y ago
  >you recommend web apps never do any DOM generation Full stop right there and you're correct. I really prefer to limit code that looks like: element.innerHTML = '<div>Do you really like content in your JS like this?<div>'; I'd rather have the HTML loaded as one file and have the javascript in another acting on that HTML. Right now my favorite library to use for this is Knockoutjs.
  - baddox 12y ago
    Knockout has HTML-esque template too, not unlike Ember or even React.
rdtsc 12y ago
Developer: use React.js. Events go one way only, no funky feedback loops between views, models and controllers.

polskibus 12y ago

Did you see this tool ? I find it quite helpful for debugging JSX and finding the root of the problem. http://facebook.github.io/react/blog/2014/01/02/react-chrome-developer-tools.html http://facebook.github.io/react/blog/2014/01/02/react-chrome...

Zelphyr 12y ago

You hit the nail on the head why these things are bad. You can either build something on a mass production line, where you're just screwing the same bolt in day in and day out, or become a master craftsman and build it with proper care, design, and quality. These frameworks are nothing more than a factory floor and if all you do is build apps with a framework you're little more than a paid glue stick piecing bits of code together. Or you can become a master software developer and build something of quality without needing a crutch like a framework. Now, if the needs of the project are such that a framework will suffice then by all means, use a framework. Chances are, if you're doing more than building a working prototype then at some point a framework is going to fail you. If you enjoy building apps using frameworks then by all means, do it. But to my mind you're doing your customer a disservice. Contrast that with great software developers (and I've been fortunate to have worked with some really great developers) who abhor these frameworks. They can get more done with less code and ultimately deliver the project faster without frameworks. The tradeoff is that it takes time and dedication to achieve that level of mastery. I personally would prefer that path.

aquark 12y ago
Of course it really is frameworks all the way down. Unless maybe you're building systems by laying out your own transitors. The trick is to understand the strengths and weaknesses of any given framework and match those with the constraints of your project.
- Zelphyr 12y ago
  I disagree that its frameworks all the way down. There is a distinction between frameworks and libraries. React, Angular, et al are frameworks in the truest sense of the word. Things like jQuery and Underscore on down to stdio.h are libraries. You can pick and choose from what they contain but they're not so tightly coupled that they get in your way. They're a tool belt with tools that do one thing and do it really well. Frameworks are like having a tool belt with a hammer that also has a saw on the end but in order to use the saw you have to grab the screwdriver even if you're not actually using it.
  - saraid216 12y ago
    I'm curious which part of React you consider the hammer and which part you consider the screwdriver.
  - wickchuck 12y ago
    I would argue that React is closer to a library than a framework. It's a small library with some useful functions for making web components. It helps by removing a bunch of boilerplate code that you would have to re-write with each new app. The thing that it doesn't do is hold you hand and tell you exactly the way things should be done as some of the other frameworks do.
  - mercer 12y ago
    Thanks for pointing out the distinction. I forget about that sometimes. That said, React is a "A Javascript Library for Building User Interfaces." And to me me it does feel more like a library than a framework.
  - modarts 12y ago
    React is a library, plain and simple. It has literally no opinions on even basic stuff like routing, or how to manage application data. It takes your data as an input and by some mechanism lays out a visual representation of it defined by your components render methods, being sure to update the visual representation as the data changes. The rest are implementation details.
- 12y ago
mercer 12y ago
I never quite understand arguments like yours. As aquark pointed out, it's 'frameworks all the way down' anyways. Unless you're a one-of-a-kind master, you're always relying on multiple levels of abstraction. I don't know who pointed it out, but I find that a good rule of thumb is to master at least one layer of abstraction below the 'current' one. So in the case of React, you'd first make sure you are proficient with javascript, the DOM, and how the web works. If your point is to underline that using frameworks without understanding them is a bad thing, I fully agree. But arguing that 'these things' (frameworks) are bad just seems silly. Clearly some clever people at Facebook found it useful to abstract certain things in a certain way, and many other people (some clever) like their approach. They've actively considered IanDrake's problem (in fact, they talk about this in their talk on React), and felt that their solution was good. If I can build a performant client-side-heavy web-app in half the time because of React, I'm doing the client a service, not a disservice.
- Zelphyr 12y ago
  Here's my experience with frameworks: They're really good at getting you to 80% completion really fast. The next 10% takes a little work but its doable. But that last 10%... its like pulling teeth. With tweezers. Covered in grease. That last 10% is the thing you need done to successfully deliver the project but which the framework designers didn't consider. In my experience you always run into that last 10%. The net result is that all those speed gains you realized early on are completely lost (and then some) because you're fighting with the framework. So sure, understanding the framework might help you with that last 10%. But I personally think you're better served mastering JS, the DOM, and how the web works. Which really isn't that hard by the way! And anyway, if frameworks were so great why are there so many? It seems like a new framework gets announced every week here on HN. The shear tonnage of frameworks alone makes me question their value[1]. Now if none of that can convince you, consider this; the company I work for got rid of all their framework programmers and replaced them with me and a couple other software developers who have experience building products without using frameworks. And they pay us more money than they paid the framework programmers. Why? Because we did more work with better quality in the first six months than those other guys could do in 2 years of gluing framework code together. That last 10% hit them HARD and cost them their damn jobs! 1: I do recognize that frameworks provide value. My argument is that they are way overused. Great for building working or semi-working prototypes in order to test an idea in the market. Terrible for building anything that needs to be continuously maintained.
chenglou 12y ago
React is a paradigm with only one existing implementation. Ranting against frameworks represented by React is a strawman here. It doesn't include a router, nor a model layer, nor the traditional controller. It's a miracle that it's even compared to Angular and Ember, but I guess that's the extent of the power of View + solid declarative nature, so we'll take it as a compliment. We also don't want to turn it into a huge framework, so if that's your only concern here, then please feel free to give it a try =).

runaway 12y ago

I think tools like React actually make debugging situations like this easier. Instead of trying to figure out what actions a user took that manipulated the DOM with jQuery n times, I can take an exact snapshot of the state of the application and walk through how it is being rendered.

baddox 12y ago

Your comment implies that you recommend web apps never do any DOM generation or manipulation using JavaScript, and are instead purely static HTML documents. For that matter, your argument would logically extend to opposing backend HTML generation as well, like Rails templates.

IanDrake 12y ago
>you recommend web apps never do any DOM generation Full stop right there and you're correct. I really prefer to limit code that looks like: element.innerHTML = '<div>Do you really like content in your JS like this?<div>'; I'd rather have the HTML loaded as one file and have the javascript in another acting on that HTML. Right now my favorite library to use for this is Knockoutjs.
- baddox 12y ago
  Knockout has HTML-esque template too, not unlike Ember or even React.

rdtsc 12y ago

Developer: use React.js. Events go one way only, no funky feedback loops between views, models and controllers.