@troch
Nothing here yet.
Nothing here yet.
No blogs yet.
@EisenbergEffect although I understand your concerns, I think what you are mostly describing are issues around organisations, and using the right technologies for the right problems. It is very unfair to blame it on React. The complexity of web applications is growing in general, with more complex business needs and everywhere across the full stack there is more specialization. What about full-stack developers who would find SPAs or distributed systems too complicated so they wouldn't want anyone to use them because they wouldn't be able to work on them? My point is: there are multiple business needs from basic websites to complex web applications, with different organisations, and there are different profiles of professionals with various levels of specialisation.
@aniforprez yes, sure. React doesn't force you to write HTML in JS, because there is no HTML in React (see my answer here: https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-file-cil3bn5hj0011a65347rsdut0 ). I think you are confusing JSX with HTML, if you don't like JSX, it is not mandatory in React. React doesn't encorage dumpin CSS in JS, there is a vast number of techniques people use to bind a component and its stylesheet together, but not many of them result in writing CSS in JavaScript. As for Angular, I don't see how directives can negatively impact code organisation.
Callbacks on their own don't give you a control flow, and create what you just referred as "Callback hell". What promises offer is a control flow of success / error callbacks. They are able to pass values from callbacks to callbacks, and that is where the main difference is between a callback and a stream or promise callback: they return a value. So it is not about calling back, it is about returning something back. You then don't have an inversion of control callbacks usually give you ("callback hell" is not just an indentation issue).
The only one which can excel at code organisation is the developer. That said some frameworks / libraries make a good job of restricting choices. I have not used Aurelia beyond playground for commenting on it, but you can achieve good code organization with React or Angular.
Like for everything else, the horrors of ReactJS are seen when: you use it and do not need it you use it but very naively As for the biggest limitations: I can't answer that question, I have not met significant limitations in the way I use React. It doesn't mean it is perfect, and there are other projects solving similar problems more elegantly. React is not a framework, there is a very wide ecosystem around it. You can write applications where React only plays a small role (taking care of the view), and therefore can hardly become the limiting factor.
I think there are already long answers. I'll keep mine short. React does not put HTML and JS in a single file. There is no HTML in React, JSX is no HTML, it makes look like HTML (virtual) DOM elements creation. HTML is a markup language to represent a DOM (or portions of). React components output (virtual) DOM elements, and don't need HTML. The way React and friends work is dictated by functional programming. Data is transformed by JavaScript to DOM elements, there is no HTML. I wrote an article about this: http://blog.reactandbethankful.com/posts/2015/09/15/understanding-the-functional-revolution/ You can fail to have separation of concern in React, by putting together (without structure) logic for: getting data, keeping hold of it, updating it, representing it. React ecosystem came with Flux and Redux. You can also look at Elm's Model-Update-View pattern, Cycle's Model-View-Intent pattern, the State-Action-Model pattern (SAM).
Hi Simon, Juho Vepsäläinen asked for an interview end of last year and I try to explain what motivated me: http://survivejs.com/blog/react-router5/. The two main motivations were: - I don't like routing to be tightly coupled to frameworks / libraries, and that it triggers view updates for you. I think it is an old habit due to wrongly perceived complexity. - I wanted to treat routing like any other piece of data your application depends upon. The nice surprise is that any integration with functional / functional and reactive architectures has been fairly straight forward. The difference with react-router is what router5 main objective is: not rendering components, not updating your URL, not caring about loading data... only outputting state updates and providing a set of tools to react to route transitions. The massive benefit of that approach is: you can compose route updates with anything else.