3 ms·

Personally, I prefer more web-component like frameworks. Vue.js is more usable, and easier to understand than React, but stuff like React Native is why React.js

Personally, I prefer more web-component like frameworks. Vue.js is more usable, and easier to understand than React, but stuff like React Native is why React.js is worth learning. I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I would like my to write my components as dom nodes, like with Vue.js, Riot. The way that react.js handles css, is also messy. I would rather just defined a <style> tag like in Vue.js.

madeofpalk 11y ago
What is it that you don't like about react and css? React actually has nothing to do with CSS - 'by default', you just include a stylesheet as normal. If you want to upgrade, you can just something like CSS Modules with webpack's css-loader to make per-component stylesheets a lot better.
matroosberg 11y ago
React does not require you to use JSX. Writing views with React.DOM is actually a quite nice alternative. This article gives an explanation: https://www.packtpub.com/books/content/using-reactjs-without-jsx https://www.packtpub.com/books/content/using-reactjs-without... However, newer React and Babel versions no longer compile JSX to React.DOM methods as the article shows, but other methods. Example for Babel: https://babeljs.io/repl/#?experimental=false&evaluate=true&loose=false&spec=false&code=React.renderComponent(%0A%3Ch1%3EHello%2C%20world!%3C%2Fh1%3E%2C%0Adocument.getElementById('example')%0A)%3B%0A%0A https://babeljs.io/repl/#?experimental=false&evaluate=true&l...
mercurial 11y ago
> I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I've read quite a few criticism of JSX but "difficult to read" is a first. It's not significantly different than any templating system out there (eg, ERB). It's just XML with interpolated code, what's confusing about it?
- BinaryIdiot 11y ago
  > what's confusing about it? In my opinion the confusing part is mostly the fact that taking a markup language and embedding it into a scripting language is really awkward. You have two completely different types of syntax not only existing together but working together. Also I've worked on multiple teams where designers will re-style and even change the markup of pages but trying to get non-developers to do this with JSX is just painful. I find HTML and the DOM API awkward at times but since that's the final state I just prefer to work with that.
- tragic 11y ago
  Well, now. Firstly: context switching is an inevitable inconvenience, but in JSX you're context-switching line by line between two radically different syntaxes. Secondly: switching into what? It's not HTML (Angular templates, for instance, are not going to win any beauty contests, but they are technically valid HTML). XML? No, not that either. So ... something that looks kinda like HTML/XML, but which isn't really. It's perfectly legitimate to sacrifice aesthetic elegance for the sake of adhering to well-understood standards. But if you're not going to adhere to that, then why pick something that is merely similarly ugly? I don't get it. Thirdly: templating/view layers always face a trade-off - either they are embedded within the host language, or they use an external DSL which is parsed/compiled by the host language. The trade-off is: better change of 'correctness' and cleaner interop with the rest of the language if it's an internal DSL; on the other hand, with eternal DSLs, at least the possibility that non-engineers will be able to work on things. With JSX, you end up grafting an 'internal' DSL simply by adding a whole pile of syntax to the core language. You don't have the advantages of the separate template language, and you lose some of the advantages of the other by requiring a whole pile of extra tools. JSX is an attempt not to choose, in a situation where compromise is basically impossible. Hence its extreme awkwardness - just like E4X before it. React has done some good things: it's put performance on everyone's agenda in a big way (Hallelujah!), and it has acted as a testbed for interesting front-end architectures. JSX, however, I feel is a serious mistake. I actually enjoy writing React code through Reagent or similar, but in native JS and especially JSX, it just feels awful. I just don't want that in my editor window.
  - 11y ago
girvo 11y ago
I'm a massive fan of Vue, and have been using it since v0.10 (IIRC); one thing I find React does better than Vue however, is large applications. Vue maps brilliantly to dynamic components that are rendered in your page (no matter where said page comes from, be it Rails or PHP or nginx serving static HTML), and while Vue.extend() and the new props/component hierarchy that v1 gave us moves us a long way towards handling larger apps, I still find it somewhat lacking at times. That's likely just a function of the sheer traction and community support React has, mind you.

madeofpalk 11y ago

What is it that you don't like about react and css? React actually has nothing to do with CSS - 'by default', you just include a stylesheet as normal. If you want to upgrade, you can just something like CSS Modules with webpack's css-loader to make per-component stylesheets a lot better.

matroosberg 11y ago

React does not require you to use JSX. Writing views with React.DOM is actually a quite nice alternative. This article gives an explanation: https://www.packtpub.com/books/content/using-reactjs-without-jsx https://www.packtpub.com/books/content/using-reactjs-without... However, newer React and Babel versions no longer compile JSX to React.DOM methods as the article shows, but other methods. Example for Babel: https://babeljs.io/repl/#?experimental=false&evaluate=true&loose=false&spec=false&code=React.renderComponent(%0A%3Ch1%3EHello%2C%20world!%3C%2Fh1%3E%2C%0Adocument.getElementById('example')%0A)%3B%0A%0A https://babeljs.io/repl/#?experimental=false&evaluate=true&l...

mercurial 11y ago

> I strongly dislike the JSX syntax as well. Its messy, and difficult to read. I've read quite a few criticism of JSX but "difficult to read" is a first. It's not significantly different than any templating system out there (eg, ERB). It's just XML with interpolated code, what's confusing about it?

BinaryIdiot 11y ago
> what's confusing about it? In my opinion the confusing part is mostly the fact that taking a markup language and embedding it into a scripting language is really awkward. You have two completely different types of syntax not only existing together but working together. Also I've worked on multiple teams where designers will re-style and even change the markup of pages but trying to get non-developers to do this with JSX is just painful. I find HTML and the DOM API awkward at times but since that's the final state I just prefer to work with that.
tragic 11y ago
Well, now. Firstly: context switching is an inevitable inconvenience, but in JSX you're context-switching line by line between two radically different syntaxes. Secondly: switching into what? It's not HTML (Angular templates, for instance, are not going to win any beauty contests, but they are technically valid HTML). XML? No, not that either. So ... something that looks kinda like HTML/XML, but which isn't really. It's perfectly legitimate to sacrifice aesthetic elegance for the sake of adhering to well-understood standards. But if you're not going to adhere to that, then why pick something that is merely similarly ugly? I don't get it. Thirdly: templating/view layers always face a trade-off - either they are embedded within the host language, or they use an external DSL which is parsed/compiled by the host language. The trade-off is: better change of 'correctness' and cleaner interop with the rest of the language if it's an internal DSL; on the other hand, with eternal DSLs, at least the possibility that non-engineers will be able to work on things. With JSX, you end up grafting an 'internal' DSL simply by adding a whole pile of syntax to the core language. You don't have the advantages of the separate template language, and you lose some of the advantages of the other by requiring a whole pile of extra tools. JSX is an attempt not to choose, in a situation where compromise is basically impossible. Hence its extreme awkwardness - just like E4X before it. React has done some good things: it's put performance on everyone's agenda in a big way (Hallelujah!), and it has acted as a testbed for interesting front-end architectures. JSX, however, I feel is a serious mistake. I actually enjoy writing React code through Reagent or similar, but in native JS and especially JSX, it just feels awful. I just don't want that in my editor window.
- 11y ago

girvo 11y ago

I'm a massive fan of Vue, and have been using it since v0.10 (IIRC); one thing I find React does better than Vue however, is large applications. Vue maps brilliantly to dynamic components that are rendered in your page (no matter where said page comes from, be it Rails or PHP or nginx serving static HTML), and while Vue.extend() and the new props/component hierarchy that v1 gave us moves us a long way towards handling larger apps, I still find it somewhat lacking at times. That's likely just a function of the sheer traction and community support React has, mind you.