I think your opinion on putting weird stuff in your HTML attributes vs. putting weird HTML-like stuff in your JavaScript is enough to make an early call on whet

I think your opinion on putting weird stuff in your HTML attributes vs. putting weird HTML-like stuff in your JavaScript is enough to make an early call on whether you'll prefer React-like libraries or Vue-like libraries. As a programmer, React has been my go-to UI library for quite a while because I see always being in JavaScript mode as a benefit (no invented scope to learn or inject things into, no invented logic to learn, everything is lintable, easy-to-follow state change flow) that's worth the drawbacks (un-pretty conditionals in render(), manually handling form input), but I can also echo the feedback in this article when it comes to having designers working on your components. > JSX is also the reason when you have to keep splitting your 15-lines-of-html-code component to 3 components, 5-lines-of-code-in-each. > ...this approach of splitting components into super-dumb components because of JSX restrictions will always put you out of flow when you are solving real business task I don't understand what this has to do with JSX without an example. > ...now you have to create 10 functions to get input from 10 inputs. 80% of these functions will contain single line with this.setState() call Working with forms is definitely one of the most painful parts of React, and one of the differences I most enjoyed when porting our sample app to Vue.js 1.x for inputs which only affect the value they bind (most interesting thing I learnt: the React component structure the original was written with mapped almost verbatim to Vue.js components, the main difference was in flexiblity of what you can pass down the tree - e.g. React components as props, but I believe Vue.js 2.x is now closer to React's flexibility), but most of this section comes across as hyperbolic. Writing onChange handlers which are as generic as you can get away with for the current form is key, but it generalises to setting state based on input names, which can as be simple as the name of the state variable, or a path in state which should be set for simple form input even in deeply-nested forms, plus the appropriate value based on the input type. e.g. if you're doing a simple form with text inputs, selects, radios etc. where checkboxes always correspond to boolean state, you could use this for every field (you don't even have to put it on each input, you can let onChange bubble up to a form with onChange={this.handleChange}): handleChange(e) { let {name, type} = e.target let valueProp = type === 'checkbox' ? 'checked' : 'value' this.setState({[name]: e.target[valueProp]}) } (It's game over for simplicity once you want to do proper, user-friendly form validation, but that's a truth universally acknowledged :))