So, besides the virtual DOM, I feel like it's east to write React-like code in Angular. Just make directives that are real tight, with unidirectional flow of events and get passed only the values they need. Perhaps I'm missing something.
How I learned to stop worrying and love React
71–80 of 107 posts
Re: How I learned to stop worrying and love React
#72I went through something similar...and then I found Mithril ( http://lhorie.github.io/mithril/ ). I may be alone on this, but I've enjoyed working with Mithril much more than I ever did React. If you haven't given it a shot, I highly recommend you do.
I'm very interested in more modular, simpler alternatives to react / flux. Essentially I'm looking for reactive "isomorphic" component based, virtual dom solutions like react - mainly to integrate with a node.js workflow.
I was wondering if anyone had tried both Mithril as well as Deku(https://github.com/segmentio/deku) who would like to share their experience?
Re: How I learned to stop worrying and love React
#73Ugh, for my sanity as a JS newbie I have to ignore all the other JS frameworks/libs mentioned in this discussion and just master React and JS, perceived warts and all. I recommend the same thing to other newbies who come here.
Re: How I learned to stop worrying and love React
#74Wow, author here. Woke up to a lot of unexpected traffic on the blog. I hope you like this article. I took a long time to understand React and, now I do, I hope other people don't take as long as I did!
Thank you for writing that article. To me, the article is pretty much how an ideal technical article should be: it doesn't assume deep knowledge of the subject matter and uses lots of examples and comparisons to make the case. It takes a lot of work to write that sort of article, I really appreciate that you took the time to do it. Looking forward to seeing the one about Flux!
Re: How I learned to stop worrying and love React
#75Earlier quoted context omitted.
Who's stopping you from putting your jsx in a seperate file?
Build tool complexity is what I dislike - it's certainly possible, but the trend I dislike is build tooling increasing complexity of the build system of the frontend, decreasing accessibility for onboarding developers. JSX is an unnecessary offender in this department, bringing us farther away from plain HTML.
Have you seen Webpack (https://webpack.github.io/)? It's a very powerful tool, but it's quite simple to start with. I can recommend this tutorial: https://webpack.github.io/
Re: How I learned to stop worrying and love React
#76Question for experts: why Browsers do not get the idea of updating changes the way react does automatically possibly with a start, stop transaction or better without.
Whenever a change is made to the raw DOM, the change has to be immediately visible to the code running after it. React sacrifices this.
When the DOM is treated as the source-of-truth for the page's information, the synchronously-visible changes are very useful. However, getting away from treating the DOM as the source-of-truth, which React forces you to do, gets you a lot of power as changes to the DOM can be batched more efficiently automatically.
Re: How I learned to stop worrying and love React
#77Earlier quoted context omitted.
Maybe if you will read my comments more closely you will see the difference between moving parts of HTML inside component and moving components. "Moving things around" is too broad term.
The distinction you're making between "HTML" and "facility for encapsulating generated HTML" seems pretty arbitrary. I was making a simpler point, though. Some of the reactions I see to React seem to come from the notion that it's mixing application logic with view logic. That's an easy misconception to get from reading the tutorials and quick-start documentation: after all, it's using raw Javascript to generate HTML…
In my first response to you I underlined I don't mean business logic.
It's the example from "JSX in Depth" (https://facebook.github.io/react/docs/jsx-in-depth.html)
// Input (JSX):
var content = {window.isLoggedIn ? : };
// Output (JS):
var content = React.createElement(
Container,
null,
window.isLoggedIn ? React.createElement(Nav) : React.createElement(Login) );
Re: How I learned to stop worrying and love React
#78Earlier quoted context omitted.
The distinction you're making between "HTML" and "facility for encapsulating generated HTML" seems pretty arbitrary. I was making a simpler point, though. Some of the reactions I see to React seem to come from the notion that it's mixing application logic with view logic. That's an easy misconception to get from reading the tutorials and quick-start documentation: after all, it's using raw Javascript to generate HTML…
In my first response to you I underlined I don't mean business logic. It's the example from "JSX in Depth" ( https://facebook.github.io/react/docs/jsx-in-depth.html ) // Input (JSX): var content = {window.isLoggedIn ? : } ; // Output (JS): var content = React.createElement( Container, null, window.isLoggedIn ? React.createElement(Nav) : React.createElement(Login) ); And it illustrates exactly what I'm trying to say:…
I find it vastly, comically easier to edit React/JSX than templated Angular and Knockout.
Re: How I learned to stop worrying and love React
#79> However, all template languages are inherently crippled: they can never achieve the same expressiveness and power as code. Quite simply, {{# each}}, ng-repeat and databind="foreach" are all poor replacements for something that is native and trivial in JavaScript: a for loop. On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using…
> On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using JSX I need to calculate the result of a `for` loop before the actual template and it looks much more complex and cumbersome. You can inline eqivalent JavaScript statements in JSX, without typical template language limitations in terms of allowed expressions or scope: {this.p…
You've gotta admit though that inlining isn't the usual case. Especially if you're not using ES6 and the component your inlining is a few or more lines long.
Re: How I learned to stop worrying and love React
#80Earlier quoted context omitted.
> On the other hand, when using a template language I can put `foreach` loops and `if` conditions right into the template itself. And when using JSX I need to calculate the result of a `for` loop before the actual template and it looks much more complex and cumbersome. You can inline eqivalent JavaScript statements in JSX, without typical template language limitations in terms of allowed expressions or scope: {this.p…
You've gotta admit though that inlining isn't the usual case. Especially if you're not using ES6 and the component your inlining is a few or more lines long.
That's not been my experience - multiple lines nest quite nicely - but even when directly inlining isn't suitable (e.g. multiple if/else checks or rendering a list in a way which doesn't suit a straight .map()) I prefer creating another method and inlining the call to it, e.g. from my Hacker News API clone:
{this.renderItems(page.startIndex, page.endIndex)}