71–80 of 81 posts
I really liked the article. I know that plenty of people are going to rip on it but I prefer ideas that stand out based more on individual insight than what the herd thinks (as the herd is usually wrong). p.s. what is the platform/library used to create this website? it's nice and clean.
There seems to be issues with some mobile clients that I cannot replicate on my ipad and galaxy s3
Earlier quoted context omitted.
That's funny, because in my opinion, the functionality of the model, data without display logic, is obvious, and the view is obvious, layout for data. but the line between the controller and the view seems very nebulous. At which point is the data general enough to warrant a new view, or specific enough to need only a controller to marshal between the view and the data... It seems to me that a Model->Controller->Widg…
i am not sure why this is downvoted. I also find model to be the easiest to wrap my head around. At one my pervious jobs we took the 'model' out of a desktop app and put a web front on it.
No, I'm not being sarcastic and I'm not being funny. The regard it is held in in some communities is radically out of proportion to any rational basis for it, especially the modern meaning of "MVC" which has been loosened to the point of near meaninglessness.
I've been doing a broad survey of these JavaScript frameworks for a month or so now. I've looked primarily at Ember, Angular, React, and Knockout. One thing is for sure: React has the community that feels the most "enlightened." I've watched several videos and read several posts similar to this one that express this sentiment of "when I finally understood it, it just clicked , and now I realize it's the best thing in…
I'd be interested to hear what you think of ChaplinJS - it's very small, but it does this kind of compartmentalized event thing really well. You can listen for events using @delegate in each view and subview, which is just a map to $.on using that view's DOM container.
I've been doing a broad survey of these JavaScript frameworks for a month or so now. I've looked primarily at Ember, Angular, React, and Knockout. One thing is for sure: React has the community that feels the most "enlightened." I've watched several videos and read several posts similar to this one that express this sentiment of "when I finally understood it, it just clicked , and now I realize it's the best thing in…
> "when I finally understood it, it just clicked, and now I realize it's the best thing in the world." There's very little to understand, it's really really simple. With React, I don't really see the point of Ember or Angular, they're basically zombie projects now. I wonder how their devs feel about React. React is an evolutionary leap enabled by their shadow DOM technology. Being able to rerender the whole page in a…
Even if I choose react for my view layer, I'm still going to need infrastructure for managing application state. View layer concerns are probably less than 30% of what I get out of Ember. The rest is bidirectional routing between URLs and models, meaningful controller hierarchies, etc.
React is simple because it ignores all that. But any significant app will still need to deal with those things.
I've always been a fan of eventful programming. If something interesting happens, broadcast an event. If you care about a particular thing happening, listen for the corresponding event. It completely decouples all your components so long as the event API is consistent. React is composable. Cool. Why is it considered a best-practice to have ancestors pass callbacks to their descendants to modify state? I'd much rather…
This is a good summary of what is nonobvious to me, even as a full time JavaScripter. I generally try to stick to the ethos "Bubble events up, invoke down" wrt the object tree. I've never heard the 'pass callbacks to descendants to modify state' considered as a best practice, but I don't think that's bad either. It's a tool in the tool box. But it's not more of a best practice than other tools. DOM Event bubbling is…
a) It's in their official tutorial: http://facebook.github.io/react/docs/tutorial.html#callbacks... , and
b) My friends who turned me on to React (as well as the StackOverflow that came up after a quick Googling) confirmed that you aren't supposed to create custom events in React, and should instead follow the callbacks-as-props model.
If I've misunderstood something, I'd love to know the better way.
Earlier quoted context omitted.
> "when I finally understood it, it just clicked, and now I realize it's the best thing in the world." There's very little to understand, it's really really simple. With React, I don't really see the point of Ember or Angular, they're basically zombie projects now. I wonder how their devs feel about React. React is an evolutionary leap enabled by their shadow DOM technology. Being able to rerender the whole page in a…
Your comparison makes no sense. React isn't really competing with something like Ember -- the more direct comparison would be React vs HTMLBars (the low level view layer library being used in next generation Ember). Even if I choose react for my view layer, I'm still going to need infrastructure for managing application state. View layer concerns are probably less than 30% of what I get out of Ember. The rest is bidi…
Thanks for this article. When I started playing with React (and seriously, I'm just playing right now), it felt to me like the whole MVC concept wasn't necessary , because I could just move state changes around to the correct places via the virtual DOM. But I'm not a front end guy at heart. I don't have the deep knowledge that the world of MVC masters do. I have a rule of thumb that when I find myself disagreeing wit…
It's nice to see people are finding React solves their problems, but keep in mind it's still very new tech. Be wary when you read things like this: "It took me a short time to get it and as soon as I got it, I felt like there is no problem that cannot be modeled decently with this system." I've been working with React for several months now, and do not have the same opinion. React solves some problems very well, but…
Again, not much of a front end guy. Last time I did serious front end was several years ago, when I spent 3 months coding in Sencha (and arguing with sloppy coders who liked the pretty Sencha widgets but didn't see the value of using the MVC pattern, grrr).
I just want to be able to build a nice, modern front end with minimal grief, learning curve, or dogma. Is that so much to ask?
Earlier quoted context omitted.
This is a good summary of what is nonobvious to me, even as a full time JavaScripter. I generally try to stick to the ethos "Bubble events up, invoke down" wrt the object tree. I've never heard the 'pass callbacks to descendants to modify state' considered as a best practice, but I don't think that's bad either. It's a tool in the tool box. But it's not more of a best practice than other tools. DOM Event bubbling is…
I called it a best practice because: a) It's in their official tutorial: http://facebook.github.io/react/docs/tutorial.html#callbacks... , and b) My friends who turned me on to React (as well as the StackOverflow that came up after a quick Googling) confirmed that you aren't supposed to create custom events in React, and should instead follow the callbacks-as-props model. If I've misunderstood something, I'd love to…
I generally deploy these modules together to the web, and I want to keep the file size of my base layer small. I think React looks cool but I haven't gotten to the point where I want to send my users 30k more code when
It does seem promising for new projects. I hope to give it a go soon.
Earlier quoted context omitted.
> "when I finally understood it, it just clicked, and now I realize it's the best thing in the world." There's very little to understand, it's really really simple. With React, I don't really see the point of Ember or Angular, they're basically zombie projects now. I wonder how their devs feel about React. React is an evolutionary leap enabled by their shadow DOM technology. Being able to rerender the whole page in a…
Are most folks using ReactJS on production running NodeJS to render the first view on the server, or just server the JS and generate everything client side? (I'm not a particular fan of JS on the server-side yet..)
I wrote a book on Struts MVC, and I agree that MVC in DOM is counter productive.
Also 'my' answer is event buss similar to E/S: https://github.com/puppetMaster3/ModuleBU