Hacker News new | past | comments | ask | show | jobs | submit login

This is very cool, but the nagging issue I have with React is this desire to reimplement everything in JavaScript and bypass the Browser, DOM, CSS, etc. I've lost track of what benefits this really offers?



Could you elaborate? All React.js "reimplements" are components for DOM elements and custom event dispatcher that allows you to don't worry about browser quirks and differences in handling events.

There's also large difference between what DOM and VDOM mean and VDOM's not DOM reimplementation.


Why write every component in 3 different languages artificially forcing it split into multiple sections when you can just develop it in one cohesive unit using the most powerful one?


Well partly because React is not that fast, and things like incorporating CSS animations are not particularly easy.

I appreciate FB is working on improving these areas, but original point is that maybe a lot of this optimization would be unnecessary if worked with the browser capabilities vs outside it in JS.


Its batch DOM writes of virtual DOM diffs ends up being a lot faster than previous SPA development models which can be further optimized with Pure Renderer. It has room for improvements but that doesn't invalidate React's approach.


Its batch DOM writes of virtual DOM diffs ends up being a lot faster than previous SPA development models which can be further optimized with Pure Renderer.

Sorry, but that isn't necessarily so. React is a lot faster than many of the other front-end frameworks, but that's because most front-end frameworks are horribly, horribly slow. However, all that rerendering and DOM diffing isn't free, and React can easily still be much slower than applying manual DOM updates if you have the patience and accuracy to write the code to do them, even if you use pure renderers and write shouldComponentUpdate everywhere.


They're taking a comprehensive look at how imperative (React) or declarative-autotranslated-into-imperative (JSX) code for describing a View actually becomes that View (which is currently either (V)DOM, or some native UI toolkit with React Native).

This process occurs in browsers, libraries, and UI toolkits today; React gives you an alternative. This means that you can render in the client, render on the server, render wherever starting from the same code.


I believe the ultimate goal is web apps with 60 fps gestures and animations.


I agree. All in the name of writing code that makes it easier to do what? Not lose track of your own javascript?


As if "losing track of your own Javascript" is something that:

a) does not happen

or:

b) is OK?

Might as well have written your sneer like: "All in the name of writing code that makes it easier to do what? Simplify development?"


Well it doesn't simplify development and that's the point, it's not a clean separation of concerns. It defies the whole purpose of using CSS, the DOM API and keeping your javascript's structural patterns cohesive. This is why Webcomponents are now part of the living standard. The browser runtime nullifies whatever React was trying to achieve.


>Well it doesn't simplify development and that's the point, it's not a clean separation of concerns.

On the contrary, it's very clean.

The real separation of concerns is between business logic and view code, and React does that perfectly.

Not between HTML, CSS, DOM etc which are artificial inflated concerns due to how the browser ended up as an ad-hoc application coding platform (from it's "document" viewer beginnings, which is where the "D" in the DOM comes from).

(And of course nothing stops you from using CSS and external styles with React, separating style from behavior).

>This is why Webcomponents are now part of the living standard.

Web components only solve the non-interesting parts of what React does. Namely, isolated components. All the state and management mess for the entire app is still yours to deal with. Even React alone does more, nevermind React+Redux/FLUX etc.

Which is also the reason React caught like wildfire, and nobody much cares for Webcomponents (e.g. not any statistically significant numbers).


I generally agree with your position here, but I think you're giving React a bit too much credit for separating business logic and view code. In practice, anything complicated probably requires shouldComponentUpdate for acceptable performance. Writing reasonably efficient shouldComponentUpdate in turn requires underlying data that can be compared quickly, hence for example the current interest in immutable data structures that can be tested for equality by checking a single reference. And so the choice to use React for rendering does have implications for how the underlying data is stored as well, which undermines any claims about truly separating the view logic from the business logic.


Sure, all abstractions are leaky one way or another, but in the end React gives you much better separation than what we had before.

Having to deal with shouldComponentUpdate is a blessing compared to having to juggle 4-5 different concepts and web technologies, plus manage state, plus separate logic yourself, etc.

Heck, in Backbone, which is as bare as it gets, and you needed to wrap your data in specific classes...

And that's IF (and it's a big IF) you have some very complex performance case. In most cases I never needed it, and tons of stuff can just be a pure render function.


Again, I generally agree with your comments here. I just think it's important to point out that this particular leak exists, because a lot of React advocacy completely glosses over the point. The need to have a data model that supports quick diffs one way or another has profound implications for the scalability of your front-end code and it's an architectural decision that will be expensive to change later if you get it wrong initially and learn that the hard way.


Not lose track of your own javascript?

No, not lose track of the current state of your DOM.


[flagged]


Your rant says nothing of substance other than a wall of text asserting it's "a horrible, horrible idea" without backing it up with any technical merit. React has proven simplicity and performance benefits and its one-way data flow architecture is optimal for developing large, complex web apps as it just lets you focus on what your App should look like for a given state and React takes care of batching the most optimal batched DOM mutations to transition your App into the next state.

Working directly with the DOM means imperatively mutating it in-line that forces you to become a manual book keeper to make sure your App state and DOM mutations stay in-sync. It's slower, forces flow/layout thrashing at inopportune times, more tedious to maintain, harder to debug and visualize your App's state, etc. There's a reason why the world and all major SPA fx's has moved on from jQuery, you're clinging on to the past JS development model.

> Use ES6, look at how to properly use HTTP, browser networking and server-side events

You're dropping technology labels that has absolutely nothing to do whether you're using React or not. I suggest you learn React before asserting it as "the dumbest idea any frontend architect" - it's likely the future development model for any UI fx with React Native the most popular Github project last year and Microsoft and Ubuntu adopting it for their latest native UI fx's. It continues to be adopted by large tech companies which they're using to rewrite their large code-bases for the development and end-user benefits it provides over previous development models.


Wow. I am clinging to the past JS development model? I said nothing of technical substance? If you want to develop a large and "simple" application look at Aurelia. The whole point of a web app, large or small is to keep it simple.

What you're misunderstanding is the basic foundations of solid software principles. Popularity does not equal tried and true. That's not logical. I understand React, or else how could I possibly nail it to the wall? You assume I use some sort of JQuery paradigm to develop UI applications, that a pretty presumptive claim on your part and it is absolutely not true.

>Working directly with the DOM means mutating it in-line and your state and you have to become a manual book keeper to make sure your App state and DOM mutations stay in-sync. It's slower, more tedious to maintain, harder to debug and visualize your App's state, etc. There's a reason why the world and all major SPA fx's has moved on from jQuery, you're clinging on to the past JS development model.

No, this is not what it means, this is your opinion. What do you think you're doing when you manage the state of a React component? If you cannot debug your app and understand its and runtime state, you need to look at your complexity bottlenecks. The browser runtime is an event-driven framework. Custom events avoid implicit calls and runtime race conditions.

What I am clinging to is the living standard and a clean separation of concerns in software development. I am standing on the shoulders of giants. I cannot help what choices developers make and what shortcuts they make to understand the browser's inherent technology. I've actually built enterprise SPAs and I have been doing it for the last 16 years, since the DOM was actually introduced.

Decompose React yourself. I've laid out my argument. It's not a rant, it's reality. React may have attractive advantages, but I don't think its adoptees understand the seriousness of the trade-offs they're making.


Sorry, you haven't laid out any argument.

You need to look into what separation of concerns really is and isn't. Switching back and forth between your highly coupled data model and view is not separation of concerns.


> Wow. I am clinging to the past JS development model? I said nothing of technical substance?

Yes and this reply hasn't got any better, which mainly consists of dumping meaningless cliche's that are meant to sound clever but have very little connection in justifying any of your assertions.

> What you're misunderstanding is the basic foundations of solid software principles. Popularity does not equal tried and true. That's not logical.

Case-in-point, this is a very weak and transparent argumentative style. Focus on technical merits not dumping meaningless cliches which only adds negative value to your argument. I can already tell the rest of your comment is going to have very little substance.

> I understand React, or else how could I possibly nail it to the wall?

You haven't done anything of the sort, your baseless points shows the exact opposite that you have no idea how React works or the benefits it provides.

> You assume I use some sort of JQuery paradigm to develop UI applications, that a pretty presumptive claim on your part and it is absolutely not true.

Then show something else where modifying the DOM directly offers a better programming paradigm as you've claimed. jQuery at least made DOM mutations bearable, which was a much better improvement than what was available before it.

> If you want to develop a large and "simple" application look at Aurelia.

Yeah that's an example of another non-jQuery modern SPA that saves you from modifying the DOM directly.

> The whole point of a web app, large or small is to keep it simple.

No the point of a web app is to deliver value for its intended purpose, the benefit of a FX is to manage complexity which React's declarative one-way data flow architecture lets you do by leaving you to just focus on how your App looks for any given state instead of handling all the imperative mutations for implementing your App's functionality and all its interim DOM state, which is what old-school development of modifying the DOM directly forces you to do. This doesn't scale for large Web Apps and is one of the reasons why React has become so popular.

> What do you think you're doing when you manage the state of a React component?

Exactly what it says, you're just managing your Apps state, React takes care of batching the required DOM mutations so the DOM matches the declarative view of your App's component.

> If you cannot debug your app and understand its and runtime state.

You can absolutely inspect your Component state at any point in time, which React excels at as you only need to look at your App's state and not the state of the DOM which is much harder to debug/analyze/maintain.

> you need to look at your complexity bottlenecks

You need to lookup complexity bottlenecks

> The browser runtime is an event-driven framework. Custom events avoid implicit calls and runtime race conditions.

More factoids that does nothing to serve your argument. Seems you're just looking for spaces to shove meaningless points in.

> What I am clinging to is the living standard and a clean separation of concerns in software development.

Imperatively mutating the DOM suggests otherwise. You come off as clinging on to old school development and are fearful of any new development paradigm that threatens your existing knowledge.

React separation of state and view and easy encapsulation offers the ideal componentization model. Encapsulation and easy composition are vital in building large Apps composed of isolated and reusable components.

> I am standing on the shoulders of giants.

Another disconnected cliche, you're now resorting to using blind faith to guide your thoughts rather than any sound technical points or are able to offer any alternatives that show where something else is comparatively better - deflecting it now as: it's different to what was built before, so must be bad.

> I cannot help what choices developers make and what shortcuts they make to understand the browser's inherent technology.

You should make an effort to understand what value a technology provides before you can discount it and you should definitely have in-depth knowledge about something before you can discredit it.

> I've actually built enterprise SPAs and I have been doing it for the last 16 years, since the DOM was actually introduced.

Doesn't sound like you know what an SPA is, which was only coined in 11 years ago that only became popularized and a viable choice after JS VM's got fast. "Enterprise SPAs" would be the last place they were being adopted in any meaningful way. The years you've spent using old-school technologies is likely contributing to your fear of considering alternative development models.

> Decompose React yourself.

I've already developed several React Apps after having tried all leading JS FX's - I consider React by far the best development paradigm for building large SPAs (and UIs in general) as I have a preference for its small, but very powerful surface area. React/Redux lets you focus on a higher class of abstraction making it trivial to build certain classes of Apps that would otherwise take an order of magnitude more effort, leaving you with a much more complicated and harder to reason about code-base.

It may not be your preference which is fine, but you should have actual reasons before discrediting it.

> I've laid out my argument. It's not a rant, it's reality.

You've really not laid out any arguments, just baseless statements without justification.

> React may have attractive advantages, but I don't think its adoptees understand the seriousness of the trade-offs they're making.

Yes React's development model has several advantages, and I'd expect the teams putting in the effort and investment to rewrite their large JavaScript code-bases know exactly the benefits it provides, given their experience with short-fall of existing technologies.


lol dude, you're a riot. Have a discussion. How far you want to drift away from the issues that have been laid it is not a discussion. Everything you write is just one big red-herring and the proof of that is laid out right on this thread.


There are direct responses to each of your baseless assertions. You've provided no proof and its your meaningless cliches that are the red-herring, likely used to cover up your lack of knowledge about React and SPAs in general. Walls of text that's not close to demonstrating one iota of proof.


I couldn't care less what's going on under the hood. I use React because it's a delight to work with. It has completely changed the way I write web apps. You should try it.


That's why we write in C# or Java instead of C and machine code. We accept abstractions at the cost of more computations in exchange for maintainability and reduced complexity.

React is similar to how innerHTML became more popular than appendChild and createElement.

In fact, I could almost say React is innerHTML for the web, without the negative effects.


Have you actually used React to create a web application?


React's popularity makes it popular target for (sometimes uneducated) criticism. JSX is one of common targets. Library's size is other. Misconception that its just VDOM is another. And then there's popular FUD about how FB may nuke your project on a whim due to patent clause in its license.


It's hard to believe people say so much random bad stuff about React when it actually has a really good track record with developers and companies and various scales.


Do you actually understand how it really works?


I'm curious, answer my question. You sound like someone who's making a argument based on zealotry instead of pragmatism.


You mean besides the one where I learned it and realized I would never use it in production? No, and here is why:

1. There is no adherence to the living standard

2. Web components are meant for this exact purpose

3. The added complexity and burden on the browser runtime will only create headaches as the application begins to scale.

4. There is no clean separation of concerns.

5. Writing HTML in js files is an anti-pattern.

6. The browser runtime, CSS and DOM obviate what React is trying to accomplish, especially with web components being added to the living standard.

7. Browser networking, workers and server-side events are much more powerful ways to scale complexity.

8. CSS3 is not hard to understand.

9. There is no way to bypass the browser's rendering engine.

10. The business scenarios for our software product did not align with the use of React after a very thorough ATAM.

11. Much better technologies exist that do not cross-cut concerns the way React does. Aurelia is what I ultimately recommended because it did not violate points 1-10.

React isn't pragmatic and if anything, the lack of examination of its internals distinctly reflects the zealotry of arguments that oppose reasonable points. Every dissenting argument I have ever encountered, especially the ones on this thread are rationalizations and opinions. I haven't seen one technical advantage that solid software engineering, the browser API, and HTTP do not already provide.

Discussions like this are meant to become arguments based on facts, zealous or not. As always, fact trumps opinion.


> 1. There is no adherence to the living standard

Do you mean the HTML living standard? Why would a javascript library be concerned with the HTML standard? What do you mean with this? The HTML output from React certainly complies with the living standard, and it doesn't even have any artifacts now that react-ids have been removed.

If you meant the javascript rolling standards, React pioneered the use of many ES2015 features.

> 2. Web components are meant for this exact purpose

Web components are meant for encapsulation, a problem that React handles fairly poorly. Meanwhile, React's alleged purpose is to handle developing large applications, a problem that web components do not really address.

> 3. The added complexity and burden on the browser runtime will only create headaches as the application begins to scale.

Practically every abstraction adds complexity and "burden" on the runtime - even Web Components! This is an assertion without evidence. There's a contention line between performance and development time that, for web applications, is usually skewed heavily towards the development side. You need to deliver your web applications in a short time frame, and also continually update them. These are the things React alleges it excels at, while also delivering acceptable performance.

> 4. There is no clean separation of concerns.

React has three clearly separated parts, component definitions, VDOM rendering and reconciliation. Which concerns aren't separated?

> 5. Writing HTML in js files is an anti-pattern.

React discourages writing HTML in js files. The standard method of using React does not involve writing HTML, React renders that for you.

> 6. The browser runtime, CSS and DOM obviate what React is trying to accomplish, especially with web components being added to the living standard.

This is just word salad. How does the browser runtime help with developing large applications?

How does CSS? Just look at all the CSS frameworks trying to wrangle the complexity of managing CSS in a large application - from CSS parsers like less and sass to naming styles like BEM, CSS modules, and so on.

The DOM isn't concerned with writing large applications at all, however directly manipulating it is usually a minefield thanks to its API and forced re-renders. Pretty much every JS framework has run away from the DOM.

Web Components don't really tackle the problems building a large application.

> 7. Browser networking, workers and server-side events are much more powerful ways to scale complexity.

I don't know how any of these things help with complexity. They're performance optimizations.

> 8. CSS3 is not hard to understand.

This is not an argument against React, since React components use CSS..

> 9. There is no way to bypass the browser's rendering engine.

Thus, we should never write libraries and frameworks for rendering? What is this even an argument for?

> 10. The business scenarios for our software product did not align with the use of React after a very thorough ATAM.

That's fine, but that's a consideration you make for yourself. It doesn't make React "quite possibly the worst anti-pattern". This is the first reasonable argument you've made.

> 11. Much better technologies exist that do not cross-cut concerns the way React does. Aurelia is what I ultimately recommended because it did not violate points 1-10.

This is possible, I haven't used Aurelia to comment.

React is very pragmatic for me. I've been moving towards data-driven UI rendering ever since I started web development. The components have good lifecycle hooks, unlike angular 1's directives. The VDOM rendering frees me from touching the DOM(a huge plus for me), and I've never had to wrestle with its edge cases(don't really do a lot of animation). The diffing engine makes it absolutely fast enough for any app I've written. The combined coding style(don't store state in the DOM, render the UI from state, take props instead of locating data via global services) is a great fit, I've already tried to enforce all these for my team manually. The documentation is top-notch, there's tutorials for everything. The tooling for it is just great. The debug story just makes me happy. Debugging React apps is a breeze compared to any other app I've had to debug. This is probably the biggest selling point for me. I am willing to go through quite a bit more pain than React causes to get this kind of debugging.

React for me has some fundamental problems, like its small surface area(only handling the view), which means it doesn't solve all my problems. The things I use it for though, I'm really content with.


> This is possible, I haven't used Aurelia to comment.

I took a brief look at the documentation. It appears as though it's a "batteries included" framework favoring convention over configuration, with a custom templating specification a la AngularJS.

The nice thing about React - to me - is the straightforward mapping of Javascript control flow to DOM. You don't have to learn a custom templating protocol in order to render things and it's ridiculously easy to create encapsulated components.

data.map((el) => <div>{el}</div>)

var Foo = React.createClass({render: () => ...});

Gets you <Foo/>

Even less syntax noise if you take advantage of stateless functional components. [0]

Compare this to Angular's ridiculous directive declaration syntax nightmare... cringe :)

Aurelia isn't that much better in this regard [1]

There's a bunch of boilerplate that needs to be introduced for you to create simple custom elements: lots of .bind, <require> tags, separate files for each custom element. Bleh :)

Maybe it's better when you're working with a bunch of developers with bad habits, or have to grok a huge code base. There, I can see some of its conventions and structure coming in handy. Still, I don't see why OP is throwing a hissy fit over it. Everyone has their favorite tools ¯\_(ツ)_/¯

0. https://facebook.github.io/react/docs/reusable-components.ht...

1. http://aurelia.io/hub.html#/doc/article/aurelia/templating/l...


> React for me has some fundamental problems, like its small surface area(only handling the view), which means it doesn't solve all my problems.

I've occasionally, successfully repurposed React to keep track of my AJAX requests. Just create a (<div/>) component for every type and start/cancel the XHRs via componentDidMount() or componentDidUpdate().




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: