Earlier quoted context omitted.
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…
That's a terrible argument my dude. Do me a solid, what do ya'lls variable names look like right now? Or just real quick, LOC on the smallest file you got.
Removing User Interface Complexity, or Why React is Awesome
131–140 of 228 posts
Re: Removing User Interface Complexity, or Why React is Awesome
#132Earlier quoted context omitted.
Agreed, I really like the demo area but it's a bit of a shock when it first shows up.
Heh, it's been mixed reactions. I will probably tweak the initial experience, but will need some time because I can't leave it open on load because it blocks the header.
WTF? I don't like reading things on the left side of my monitor, so I make the window wider to try and put the text back in the middle. Except now the demo area gets even wider (why? you don't use it for anything but tiny things?).
As I scroll, the various iframe loads create annoying jank, and to top it off, there's a bug at the end of the post where it moves horizontally for no good reason.
If you're going to do stuff like this, you need to polish it waaay better. This reminds me of the UI animations in the new Firefox. A good idea ruined by implementation, would've been better to leave them out.
Re: Removing User Interface Complexity, or Why React is Awesome
#133Earlier quoted context omitted.
if you are going to update the DOM 60 times per second no databinding/reactive whatever framework makes sense. there is so much overhead with these solutions performances would just be bad. However it would be interesting to extract the virtual DOM from React to use it in the context DOM based games, being able to mark elements as dirty in order to redraw them is a usefull feature.One just doesnt need all the JSX/dat…
JSX is a build step and is completely optional. If by "databinding stuff" you mean React's setState and friends, almost all of React's code deals with the actual diffing and browser handling. Components are not much more than functions from props to a virtual DOM output. It's easy to use React without ever calling React.createClass (just pass the output of React.DOM to renderComponent). Still, we're looking at separa…
Re: Removing User Interface Complexity, or Why React is Awesome
#134Earlier quoted context omitted.
So if i may ask, what do you use? Just raw DOM manipulations? I feel like your argument is partially valid, but your argument also sounds like it effectively argues for pure Assembly. Anything ontop of that costs you a ton at the 10% mark. Now, i understand there's a difference between a Framework and a Language, but i hope you can understand my point. I feel like you're going to one extreme, and arguing against anot…
I prefer libraries. I'm partial to jQuery[1] for DOM manipulation, simple effects, and AJAX. I love Underscore. Both libraries allow me to pick and choose which parts of them I can use without imposing on me to do it The $FrameworkName Way. That said, when I can use pure JS I do. Lastly, what are your thoughts on code maintenance? I feel like there is something to be said for "Get it done" thinking and "Make it maint…
The result of all this is code that is harder to maintain, even for those who know how to use said framework.
While I'm not against frameworks myself (in fact I argued in favor of them in this very conversation), I have become much more weary of them. In fact, after a brief affair with CoffeeScript I've even come to be more hesitant about using that or other 'transpilers', as I recently ran into the problem where I had to revert to plain js and I discovered that I'd lost some proficiency.
That said, it depends partly on the developers, and partly on the amount of structure the framework forces you into.
And that said, I suspect using a framework often serves more to alleviate managers' concern about maintainability than anything else.
There's one case where I would strongly suggest someone use a framework though, especially an opinionated one such as Rails. By following the Rails Tutorial by Michael Hartl, I learned a lot about best practices that I wouldn't have learned had I cobbled together a bunch of libraries. So for beginning developers, a framework might help them get started with their prototypes and whatnot.
Then again, maybe that worked for me because I can't help but want to look behind the curtain... I've certainly met my share of developers who never seen to wonder what's behind the magic.
Re: Removing User Interface Complexity, or Why React is Awesome
#135I'm honestly really, really wary of minimalistic front-end frameworks after two years of working on single page web apps. All that ends up happening in practice is untested, messy code with deadlines up your ass and 0 developer ergonomics. Zero.
Re: Removing User Interface Complexity, or Why React is Awesome
#136Earlier quoted context omitted.
I think a lot of people see frameworks like Ember and Angular and get scared by their vastness. You don't "get" them in one evening. I have spent many hours poring over documentation, articles and videos for both Angular and Ember and I still feel that there's more to learn. But things like routing, data persistence and controllers will be a part of your app even if you use React. What I find good about Ember/Angular…
That's a very good point. I've currently settled on Backbone to give my stuff a bit more structure, but I suspect some of the complication of construction might actually disappear when using React. Not all of it, of course, but some of it.
Re: Removing User Interface Complexity, or Why React is Awesome
#137I think this post is missing something in its description of Web Components: the fundamental difference between a JS-based framework like React and a Web Components-based framework like Polymer is that the former takes JS objects as primitives and the DOM as an implementation artifact, while the latter takes the DOM as a primitive and JS as an implementation artifact. You cannot wrap your head around Web Components a…
And the second you start doing conditional elements (like the tabbed example), Web Components gets pretty complex. In React, it's just `if(shown) { renderItem(); }`.
If you make HTML smart enough, sure, you don't have to manually wire up anything. But then you're left with `x-if`, `x-ajax`, and so on tags. Why not just use JavaScript?
Re: Removing User Interface Complexity, or Why React is Awesome
#138Great read, by the way.
Re: Removing User Interface Complexity, or Why React is Awesome
#139Earlier quoted context omitted.
That's a terrible argument my dude. Do me a solid, what do ya'lls variable names look like right now? Or just real quick, LOC on the smallest file you got.
What kind of useful metric could variable names and lines of code possibly provide?
If your average LOC is ever more than 200 lines or so, you've got a messy app.
Re: Removing User Interface Complexity, or Why React is Awesome
#140As mostly an outsider to the web front end development, React.js is probably the easiest one for me to understand among the typical "frameworks", especially Angular and Ember. After all the excitement about Angular for example, I went to learn about it and just got lost with new concepts: DOM transclusion, scopes, services, directives, ng-apps, controllers, dependency inversion and so on. I can use it but need someon…
I've been doing Angular for about a year now and am pretty comfortable with it, but I definitely remember going through that brick wall and see it every time I try to explain it to someone new. React looks much more straightforward to pick up but I am curious whether someone who has "mastered" both would find one or the other more powerful or maintainable.