7 ms·

Did you try React before switching over? How did you enjoy data-bindings after working setState() ?

by seivan 11y ago

david-given 11y ago
No, I've never touched React (mostly because it seems to require precompilation). I've been meaning to check it out at some point but the barrier of having to set up a Javascript toolchain has, so far, been too high to be worth it. Before the Polymer rewrite the trivial amount of interactive stuff on my site was raw jquery.
- mbrock 11y ago
  FYI, React doesn't require any precompilation. You only need to include a JavaScript file. The JSX stuff is entirely optional, although almost everyone uses it. I share your fear and loathing of JavaScript compilation toolchains, and I successfully avoided all of them on a medium-sized React project. After we had a good working prototype, we started using some more tooling, but we kept it extremely simple to start with. 1. JSX tags simply compile to calls like React.createElement("a", { href: url }, ["content"]) and if you just create a short alias for that function, you don't need JSX at all. 2. If you're anything like me, things like Flux scare you by being weirdly ideological and requiring unnecessary boilerplate. You can ignore it and just use a single object to store all your state, according to the "keep it simple, stupid" philosophy. That said, I would recommend that you look at the Redux library, which is a simple and rational approach to the nebulous "Flux" concept. Redux is simple—it's just a certain design pattern that makes sense in the React context. 3. I find React.addons.update to be the most obvious and simple way of doing immutable updates to nested structures—which is what most React programs are doing all the time. People have come up with various libraries for more sophisticated immutable data structures, but you're unlikely to need them, and React.addons.update gives you 90% of the bang. Next time I have a bit of non-stressed free time, I'd like to make a repository with an example React application that's extremely simple, requiring no tooling and as much as possible avoiding "lockin" to various newfangled libraries and paradigms...
  - bsimpson 11y ago
    I shared your fear of toolchains, but with Webpack, Babel, and Hot Module Replacement, I've been won-over. Those tools make it painless to sculpt out a UI in real-time, using the latest ES sugars and a sane module system. Webpack has Uglify built-in, so you can target a minified file for production. With Babel and JSX, you're still writing idiomatic JS, so you don't have the same lock-in problems you might with something like CoffeeScript. In my mind, it's a clear value-add with no observed downside. What's your hesitation?
    - mbrock 11y ago
      Yeah, those things are nice and compelling. I've used them, often happily! Some of the new language features are hard to live without once you're used to them; I especially like async/await and the destructuring syntax. The flip side is simply that it's more technology, more stuff to learn, more stuff to keep running on your computers, and more potential bugs and strange interactions to run into. I don't like to talk about it in a negative way, because it can sound like I'm disparaging the technology. But, there are nice things about having your project be written in the actual language that the browser already supports. Like simply never having to think about transpilers. Of course once you've learned about tools like Webpack and Babel, you can use them to your heart's content if they make you more productive. I just wanted to emphasize to the person I replied to that you don't NEED any of them. Especially not to just get started. You don't need minifying until there's a problem with your page load time and until you actually know that minifying will help with that -- until then, it's strictly speaking a premature optimization. (Writing less complex code may be more important!) And so on. And "no observed downside" is not strictly true if you consider the cost of added complexity. For someone who is overwhelmed by infrastructural proliferation, it should be nice to hear that you can develop actual applications with just plain JavaScript and maybe a small Makefile.
      - bsimpson 11y ago
        By "no observed downside", I meant once the toolchain is set up. Now, I get Hot Module Replacement and JS Harmony sugars for free, without having to worry about which browsers natively support which new features. Your point about perceived complexity/intimidation is a good one, but for me, removing cross browser inconsistencies simplifies development more than Webpack complicates it.
- seivan 11y ago
  You know what, the barrier is fucking shit, that's true. I had issues myself and I'm not sure I am doing it right. However don't knock it off because of the precompilation stuff. Mostly because I'd like a nice comparison by someone, heh :) I personally hate bindings now, apart for using them with forms, but React offers a mixin for that. What I am interested is if Polymer is worth it or not.
  - tracker1 11y ago
    If you like a discrete control flow, then Polymer is a valid approach. TBH, if your application isn't beyond moderately complex, it doesn't matter too much which framework you choose as long as you have relatively clean separation of logic and control flows. React (with a flux-like control flow library, such as Redux) has a higher cognitive load to start. Where it shines is as additional features are added, there is very little additional complexity. Where with Polymer (or Angular) your application as will see a curve of additional complexity as features are added. I started a pretty basic setup for React + Webpack with hot reloading[1]. I'm going to add in Redux next, then Router... At which point I'm planning on adding in material-ui[2]. From there, I'll try to keep it updated or forked to use as a base application. I started it off by following te SurviveJS book[3], but my direction is a bit different. I'd also recommend reading the full stack redux tutorial[4]. [1] https://github.com/tracker1/r3k-example https://github.com/tracker1/r3k-example [2] http://material-ui.com/#/ http://material-ui.com/#/ [3] http://survivejs.com/ http://survivejs.com/ [4] http://survivejs.com/ http://survivejs.com/
- RussianCow 11y ago
  JSX isn't mandatory, so you can just write plain old JS if you want. And if you want to use JSX but don't want to use a full-blown toolchain for development, there is an in-browser JSX transform library[0] that you can include to do the compilation on the client side. [0]: https://facebook.github.io/react/docs/tooling-integration.html#in-browser-jsx-transform https://facebook.github.io/react/docs/tooling-integration.ht...
  - seivan 11y ago
    To be fair React without JSX is pretty bad. I did that for a while with TypeScript before it got JSX support.
    - cloverich 11y ago
      I agree with you but to provide some more context, some people seem to prefer the non-JSX approach. Here is a (random) example of what that looks like: https://github.com/littlebits/react-popover/blob/master/examples/basic/index.js https://github.com/littlebits/react-popover/blob/master/exam...
      - seivan 11y ago
        Oh yeah, I remember seeing that with coffee-script without the parentheses.
    - malandrew 11y ago
      React with JSX is pretty bad. A library like https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript solves the verbosity with not using JSX.
- k__ 11y ago
  I made a quick tutorial with this in mind. Most of it is JSX based, but it has 3 lessons without it. Maybe this helps :) https://github.com/kay-is/react-from-zero https://github.com/kay-is/react-from-zero

Did you try React before switching over? How did you enjoy data-bindings after working setState() ?

by seivan 11y ago

Did you try React before switching over? How did you enjoy data-bindings after working setState() ?

No, I've never touched React (mostly because it seems to require precompilation). I've been meaning to check it out at some point but the barrier of having to set up a Javascript toolchain has, so far, been too high to be worth it. Before the Polymer rewrite the trivial amount of interactive stuff on my site was raw jquery.

mbrock 11y ago
FYI, React doesn't require any precompilation. You only need to include a JavaScript file. The JSX stuff is entirely optional, although almost everyone uses it. I share your fear and loathing of JavaScript compilation toolchains, and I successfully avoided all of them on a medium-sized React project. After we had a good working prototype, we started using some more tooling, but we kept it extremely simple to start with. 1. JSX tags simply compile to calls like React.createElement("a", { href: url }, ["content"]) and if you just create a short alias for that function, you don't need JSX at all. 2. If you're anything like me, things like Flux scare you by being weirdly ideological and requiring unnecessary boilerplate. You can ignore it and just use a single object to store all your state, according to the "keep it simple, stupid" philosophy. That said, I would recommend that you look at the Redux library, which is a simple and rational approach to the nebulous "Flux" concept. Redux is simple—it's just a certain design pattern that makes sense in the React context. 3. I find React.addons.update to be the most obvious and simple way of doing immutable updates to nested structures—which is what most React programs are doing all the time. People have come up with various libraries for more sophisticated immutable data structures, but you're unlikely to need them, and React.addons.update gives you 90% of the bang. Next time I have a bit of non-stressed free time, I'd like to make a repository with an example React application that's extremely simple, requiring no tooling and as much as possible avoiding "lockin" to various newfangled libraries and paradigms...
- bsimpson 11y ago
  I shared your fear of toolchains, but with Webpack, Babel, and Hot Module Replacement, I've been won-over. Those tools make it painless to sculpt out a UI in real-time, using the latest ES sugars and a sane module system. Webpack has Uglify built-in, so you can target a minified file for production. With Babel and JSX, you're still writing idiomatic JS, so you don't have the same lock-in problems you might with something like CoffeeScript. In my mind, it's a clear value-add with no observed downside. What's your hesitation?
  - mbrock 11y ago
    Yeah, those things are nice and compelling. I've used them, often happily! Some of the new language features are hard to live without once you're used to them; I especially like async/await and the destructuring syntax. The flip side is simply that it's more technology, more stuff to learn, more stuff to keep running on your computers, and more potential bugs and strange interactions to run into. I don't like to talk about it in a negative way, because it can sound like I'm disparaging the technology. But, there are nice things about having your project be written in the actual language that the browser already supports. Like simply never having to think about transpilers. Of course once you've learned about tools like Webpack and Babel, you can use them to your heart's content if they make you more productive. I just wanted to emphasize to the person I replied to that you don't NEED any of them. Especially not to just get started. You don't need minifying until there's a problem with your page load time and until you actually know that minifying will help with that -- until then, it's strictly speaking a premature optimization. (Writing less complex code may be more important!) And so on. And "no observed downside" is not strictly true if you consider the cost of added complexity. For someone who is overwhelmed by infrastructural proliferation, it should be nice to hear that you can develop actual applications with just plain JavaScript and maybe a small Makefile.
    - bsimpson 11y ago
      By "no observed downside", I meant once the toolchain is set up. Now, I get Hot Module Replacement and JS Harmony sugars for free, without having to worry about which browsers natively support which new features. Your point about perceived complexity/intimidation is a good one, but for me, removing cross browser inconsistencies simplifies development more than Webpack complicates it.
seivan 11y ago
You know what, the barrier is fucking shit, that's true. I had issues myself and I'm not sure I am doing it right. However don't knock it off because of the precompilation stuff. Mostly because I'd like a nice comparison by someone, heh :) I personally hate bindings now, apart for using them with forms, but React offers a mixin for that. What I am interested is if Polymer is worth it or not.
- tracker1 11y ago
  If you like a discrete control flow, then Polymer is a valid approach. TBH, if your application isn't beyond moderately complex, it doesn't matter too much which framework you choose as long as you have relatively clean separation of logic and control flows. React (with a flux-like control flow library, such as Redux) has a higher cognitive load to start. Where it shines is as additional features are added, there is very little additional complexity. Where with Polymer (or Angular) your application as will see a curve of additional complexity as features are added. I started a pretty basic setup for React + Webpack with hot reloading[1]. I'm going to add in Redux next, then Router... At which point I'm planning on adding in material-ui[2]. From there, I'll try to keep it updated or forked to use as a base application. I started it off by following te SurviveJS book[3], but my direction is a bit different. I'd also recommend reading the full stack redux tutorial[4]. [1] https://github.com/tracker1/r3k-example https://github.com/tracker1/r3k-example [2] http://material-ui.com/#/ http://material-ui.com/#/ [3] http://survivejs.com/ http://survivejs.com/ [4] http://survivejs.com/ http://survivejs.com/
RussianCow 11y ago
JSX isn't mandatory, so you can just write plain old JS if you want. And if you want to use JSX but don't want to use a full-blown toolchain for development, there is an in-browser JSX transform library[0] that you can include to do the compilation on the client side. [0]: https://facebook.github.io/react/docs/tooling-integration.html#in-browser-jsx-transform https://facebook.github.io/react/docs/tooling-integration.ht...
- seivan 11y ago
  To be fair React without JSX is pretty bad. I did that for a while with TypeScript before it got JSX support.
  - cloverich 11y ago
    I agree with you but to provide some more context, some people seem to prefer the non-JSX approach. Here is a (random) example of what that looks like: https://github.com/littlebits/react-popover/blob/master/examples/basic/index.js https://github.com/littlebits/react-popover/blob/master/exam...
    - seivan 11y ago
      Oh yeah, I remember seeing that with coffee-script without the parentheses.
  - malandrew 11y ago
    React with JSX is pretty bad. A library like https://github.com/mlmorg/react-hyperscript https://github.com/mlmorg/react-hyperscript solves the verbosity with not using JSX.
k__ 11y ago
I made a quick tutorial with this in mind. Most of it is JSX based, but it has 3 lessons without it. Maybe this helps :) https://github.com/kay-is/react-from-zero https://github.com/kay-is/react-from-zero