6 ms·

Vue.js is a step backwards, relative to React, in my opinion. What I love about React is JSX (or TSX if using TypeScript). JSX is a combination of JavaScript an

Vue.js is a step backwards, relative to React, in my opinion. What I love about React is JSX (or TSX if using TypeScript). JSX is a combination of JavaScript and HTML syntaxes. You don't need to learn a new syntax in order to incorporate loops and conditionals in the view layer, thanks to JSX: you just use JavaScript. More importantly, you get compile-time verification. If you use a JavaScript variable in JSX and someone deletes that variable you find out about this issue at compile time. This is very important for large projects that multiple developers are working on together. Angular and View.js don't have this capability and that's a very serious shortcoming for large projects.

indreklasn 9y ago
I love React but you're completely wrong here. Vue has JSX support as well https://github.com/vuejs/babel-plugin-transform-vue-jsx https://github.com/vuejs/babel-plugin-transform-vue-jsx. JSX isn't a React thing anymore. Most Virtual DOM solutions offer JSX. Styling React components is a huge pain. What I like about Vue is the awesome styles, HTML and js in one file for each component. With React projects I have a completely seperate styles folder.
- petilon 9y ago
  The documentation for view.js seems to highlight a custom syntax that cannot be verified at compile-time: https://vuejs.org/v2/guide/#Conditionals-and-Loops https://vuejs.org/v2/guide/#Conditionals-and-Loops If you are interested in HTML, JavaScript and Styles in one component you really want Web Components. React and view.js support components but they are brittle. W3 Web Components (implemented by Chrome and Safari) solve this problem. More on that here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
  - yunyu 9y ago
    Vue templates are verified at compile time (don't know where you got that from), and static analysis is planned for the future (which isn't directly possible with JSX): https://medium.com/@youyuxi/pretty-good-comparison-overall-but-a-few-points-id-like-to-discuss-e4f6460e75d5 https://medium.com/@youyuxi/pretty-good-comparison-overall-b... There are two distributions of Vue, one in which templates are precompiled (this is the default and recommended build), and one bundling the runtime template compiler. You are most likely thinking of the latter.
  - deleted 9y ago
    [deleted]
- emn13 9y ago
  He's definitely not wrong. Vue.js supports and promotes templates (e.g. right on the very "get started" page the homepage links to: https://vuejs.org/v2/guide/#Conditionals-and-Loops https://vuejs.org/v2/guide/#Conditionals-and-Loops) with yet another NIH looping and conditional syntax. Perhaps it's possible to avoid - but that kind of flexibility simply encourages messy codebases.
  - sgustard 9y ago
    JSX is not a requirement for React. React has the same kind of flexibility you are criticizing. https://facebook.github.io/react/docs/react-without-jsx.html https://facebook.github.io/react/docs/react-without-jsx.html
    - jolux 9y ago
      Not a requirement per se, sure, but it's strongly suggested and other usages are not idiomatic.
    - tehbeard 9y ago
      That is simply skipping the transpiling of JSX, the structure/nesting is the exact same, not some DSL crafted for templating.
    - cjalmeida 9y ago
      React without JSX is very clunky at best.
    - emn13 9y ago
      That's not at all the same, for (at least) 2 reasons. - Defaults matter; templates as defaults means most examples, support, tools, extensions, etc. will assume templating. - React without JSX doesn't actually affect the code structure or flow. Looping, conditionals, composition etc. all stay the same; and that shouldn't be surprising since JSX is essentially no more than a slightly different syntax for nested method calls and object literals; which is quite unlike templates in vue; those have actual semantics too. I've used react without jsx before (some time ago for a coffeescript based project), and it affects little. If you do that, you'll want to introduce some alternative shorthand to avoid all those repetitive "React.createElement" calls, but doing so is trivial - after all, it's just method calls and object literals. I'm not a huge fan of custom languages like JSX in general, and indeed JSX too (I believe) was a mistake. However, with sufficient support and a small enough target to support, it's less of an issue. Still, even extremely well funded projects like razor are clearly much less well supported by tooling than the language they're based on, even many years later. Vue's templates? Completely hopeless.
- siliconwrath 9y ago
  Styled components solves this problem very nicely https://github.com/styled-components/styled-components https://github.com/styled-components/styled-components
rightnow 9y ago
Wrong. Vue has jsx aswell.
jankiel 9y ago
Vue does have JSX backend, so your argument is not really valid
evmar 9y ago
FWIW, Angular templates are also checked at compile time. (But you're not wrong about the advantages of JSX -- as you observe Angular has its own syntax for looping etc.)
unclebucknasty 9y ago
Funny to read this--talk about the benefits of strong-typing, etc. The dynamic nature of JS was once a benefit. Granted, it wasn't initially purposed for full-out browser facing SPAs, etc. Still, strong-typing has been with us forever and, in general, I feel like we've solved this problem. I'd like to see a light-weight VM framework that supports Java code compiled down to JS, with an in-browser Swing-like component framework (no, not applets). But a lot of the tenents of async, event-driven Swing style dev (including using workers to keep i/o off the event thread), actually overlay nicely with the challenges that modern JS frameworks are attempting to solve. I know there's not a lot of Java-love around here, but, pick any language that has modeled out this problem and has a cadre of seasoned developers. Then, rather than re-invent the wheel, just port that to the browser.
- abalashov 9y ago
  It's funny: I'm not even a web developer by trade, and perhaps precisely because of that fact, every other day at least I have a conversation with a colleague that goes something like, "Wouldn't it be great if there were Swing for browsers?" The idea of pre-styled and easily laid-out widgets holds a great deal of appeal. Vue and Bootstrap come close to giving me that, but not quite.
  - unclebucknasty 9y ago
    Yeah, Swing is actually fun to write. Possibly because its paradigm is elegant and such a natural fit for the problem that you don't spend time fighting to fit a square peg in a round hole. Shame it came with such an unwieldy deployment model that it never gained more traction.
    - abalashov 9y ago
      For me personally, the biggest selling point is not having to evolve the skill set of design and layout. I'm a developer, not a designer, and the ROI on me learning the fine points of CSS is very low. I already know the bottom 80% of CSS, but who doesn't? It's the top 20% where the "magic" happens, as with so many things. Pre-styled, if unremarkable componentry is what I need to deliver business outcomes. Bootstrap is made for people like me, but something like Swing would make it even easier.
deleted 9y ago
[deleted]
amelius 9y ago
How you write the elements really isn't a very important aspect of an application. It's just convenience.
seanwilson 9y ago
> More importantly, you get compile-time verification. If you use a JavaScript variable in JSX and someone deletes that variable you find out about this issue at compile time. This is very important for large projects that multiple developers are working on together. I'm still amazed people argue that statically typed languages don't make you more productive compared to dynamically typed languages.
- yunyu 9y ago
  Vue templates are checked at compile time with the default runtime-only distribution, and the DSL it uses is arguably more checkable than JSX.
  - seanwilson 9y ago
    Sure, I'm just saying I don't understand how people that like dynamic typing can't see the productivity value in being told e.g. a variable isn't defined or a function call is missing arguments at compile time.
    - julianmarq 9y ago
      You don't understand? Just read the thousands, probably millions, of explanations on that and other advantages and disadvantages of both dynamic and static languages in the thousands, probably millions, of discussions that have been about it for the past sixty years. What? You thought dynamic languages were a new fad? They have existed as long as computer science has, exactly like static languages. For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones.
      - seanwilson 9y ago
        > You don't understand? Just read the thousands, probably millions, of explanations on that and other advantages and disadvantages of both dynamic and static languages in the thousands, probably millions, of discussions that have been about it for the past sixty years. I've worked a lot with static and dynamic types, read a lot about both and in my opinion static typing has clear and obvious advantages. > For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones. Why is being a "good coder" a factor? Everyone makes mistakes and teams will always consist of a mixture of skill levels. On large code bases especially, getting compile time errors on basic problems like referring to non-existent variables and calling functions with wrongly type arguments is undeniable time saving in my opinion. Types also enable better refactoring automation and autocomplete. All of these are great for small projects and even better for big projects with lots of team members. What advantages does dynamic typing have that could outweigh those factors?
tyrw 9y ago
It's hard to take anyone seriously who doesn't even spell the name of the thing they're opining on correctly. I'd venture to say you've never used Vue in a meaningful way so probably aren't qualified to make a comparison.
doublerebel 9y ago
Jade/Pug templates (been around for years, and are the ExpressJS default) also offer the same feature of being just "a combination of JavaScript and HTML elements". I haven't been convinced yet that JSX is better, because I can do all the same things in Pug (client or server-side rendering, compile to Hyperscript, compile to Javascript) yet with cleaner syntax.

indreklasn 9y ago

I love React but you're completely wrong here. Vue has JSX support as well https://github.com/vuejs/babel-plugin-transform-vue-jsx https://github.com/vuejs/babel-plugin-transform-vue-jsx. JSX isn't a React thing anymore. Most Virtual DOM solutions offer JSX. Styling React components is a huge pain. What I like about Vue is the awesome styles, HTML and js in one file for each component. With React projects I have a completely seperate styles folder.

petilon 9y ago
The documentation for view.js seems to highlight a custom syntax that cannot be verified at compile-time: https://vuejs.org/v2/guide/#Conditionals-and-Loops https://vuejs.org/v2/guide/#Conditionals-and-Loops If you are interested in HTML, JavaScript and Styles in one component you really want Web Components. React and view.js support components but they are brittle. W3 Web Components (implemented by Chrome and Safari) solve this problem. More on that here: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder
- yunyu 9y ago
  Vue templates are verified at compile time (don't know where you got that from), and static analysis is planned for the future (which isn't directly possible with JSX): https://medium.com/@youyuxi/pretty-good-comparison-overall-but-a-few-points-id-like-to-discuss-e4f6460e75d5 https://medium.com/@youyuxi/pretty-good-comparison-overall-b... There are two distributions of Vue, one in which templates are precompiled (this is the default and recommended build), and one bundling the runtime template compiler. You are most likely thinking of the latter.
- deleted 9y ago
  [deleted]
emn13 9y ago
He's definitely not wrong. Vue.js supports and promotes templates (e.g. right on the very "get started" page the homepage links to: https://vuejs.org/v2/guide/#Conditionals-and-Loops https://vuejs.org/v2/guide/#Conditionals-and-Loops) with yet another NIH looping and conditional syntax. Perhaps it's possible to avoid - but that kind of flexibility simply encourages messy codebases.
- sgustard 9y ago
  JSX is not a requirement for React. React has the same kind of flexibility you are criticizing. https://facebook.github.io/react/docs/react-without-jsx.html https://facebook.github.io/react/docs/react-without-jsx.html
  - jolux 9y ago
    Not a requirement per se, sure, but it's strongly suggested and other usages are not idiomatic.
  - tehbeard 9y ago
    That is simply skipping the transpiling of JSX, the structure/nesting is the exact same, not some DSL crafted for templating.
  - cjalmeida 9y ago
    React without JSX is very clunky at best.
  - emn13 9y ago
    That's not at all the same, for (at least) 2 reasons. - Defaults matter; templates as defaults means most examples, support, tools, extensions, etc. will assume templating. - React without JSX doesn't actually affect the code structure or flow. Looping, conditionals, composition etc. all stay the same; and that shouldn't be surprising since JSX is essentially no more than a slightly different syntax for nested method calls and object literals; which is quite unlike templates in vue; those have actual semantics too. I've used react without jsx before (some time ago for a coffeescript based project), and it affects little. If you do that, you'll want to introduce some alternative shorthand to avoid all those repetitive "React.createElement" calls, but doing so is trivial - after all, it's just method calls and object literals. I'm not a huge fan of custom languages like JSX in general, and indeed JSX too (I believe) was a mistake. However, with sufficient support and a small enough target to support, it's less of an issue. Still, even extremely well funded projects like razor are clearly much less well supported by tooling than the language they're based on, even many years later. Vue's templates? Completely hopeless.
siliconwrath 9y ago
Styled components solves this problem very nicely https://github.com/styled-components/styled-components https://github.com/styled-components/styled-components

rightnow 9y ago

Wrong. Vue has jsx aswell.

jankiel 9y ago

Vue does have JSX backend, so your argument is not really valid

evmar 9y ago

FWIW, Angular templates are also checked at compile time. (But you're not wrong about the advantages of JSX -- as you observe Angular has its own syntax for looping etc.)

unclebucknasty 9y ago

Funny to read this--talk about the benefits of strong-typing, etc. The dynamic nature of JS was once a benefit. Granted, it wasn't initially purposed for full-out browser facing SPAs, etc. Still, strong-typing has been with us forever and, in general, I feel like we've solved this problem. I'd like to see a light-weight VM framework that supports Java code compiled down to JS, with an in-browser Swing-like component framework (no, not applets). But a lot of the tenents of async, event-driven Swing style dev (including using workers to keep i/o off the event thread), actually overlay nicely with the challenges that modern JS frameworks are attempting to solve. I know there's not a lot of Java-love around here, but, pick any language that has modeled out this problem and has a cadre of seasoned developers. Then, rather than re-invent the wheel, just port that to the browser.

abalashov 9y ago
It's funny: I'm not even a web developer by trade, and perhaps precisely because of that fact, every other day at least I have a conversation with a colleague that goes something like, "Wouldn't it be great if there were Swing for browsers?" The idea of pre-styled and easily laid-out widgets holds a great deal of appeal. Vue and Bootstrap come close to giving me that, but not quite.
- unclebucknasty 9y ago
  Yeah, Swing is actually fun to write. Possibly because its paradigm is elegant and such a natural fit for the problem that you don't spend time fighting to fit a square peg in a round hole. Shame it came with such an unwieldy deployment model that it never gained more traction.
  - abalashov 9y ago
    For me personally, the biggest selling point is not having to evolve the skill set of design and layout. I'm a developer, not a designer, and the ROI on me learning the fine points of CSS is very low. I already know the bottom 80% of CSS, but who doesn't? It's the top 20% where the "magic" happens, as with so many things. Pre-styled, if unremarkable componentry is what I need to deliver business outcomes. Bootstrap is made for people like me, but something like Swing would make it even easier.

deleted 9y ago

[deleted]

amelius 9y ago

How you write the elements really isn't a very important aspect of an application. It's just convenience.

seanwilson 9y ago

> More importantly, you get compile-time verification. If you use a JavaScript variable in JSX and someone deletes that variable you find out about this issue at compile time. This is very important for large projects that multiple developers are working on together. I'm still amazed people argue that statically typed languages don't make you more productive compared to dynamically typed languages.

yunyu 9y ago
Vue templates are checked at compile time with the default runtime-only distribution, and the DSL it uses is arguably more checkable than JSX.
- seanwilson 9y ago
  Sure, I'm just saying I don't understand how people that like dynamic typing can't see the productivity value in being told e.g. a variable isn't defined or a function call is missing arguments at compile time.
  - julianmarq 9y ago
    You don't understand? Just read the thousands, probably millions, of explanations on that and other advantages and disadvantages of both dynamic and static languages in the thousands, probably millions, of discussions that have been about it for the past sixty years. What? You thought dynamic languages were a new fad? They have existed as long as computer science has, exactly like static languages. For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones.
    - seanwilson 9y ago
      > You don't understand? Just read the thousands, probably millions, of explanations on that and other advantages and disadvantages of both dynamic and static languages in the thousands, probably millions, of discussions that have been about it for the past sixty years. I've worked a lot with static and dynamic types, read a lot about both and in my opinion static typing has clear and obvious advantages. > For what it's worth, the "productivity value" is demonstrably minimal if we're talking about good coders. And it's not like bad coders wouldn't run into roadblocks with static languages that don't exist in dynamic ones. Why is being a "good coder" a factor? Everyone makes mistakes and teams will always consist of a mixture of skill levels. On large code bases especially, getting compile time errors on basic problems like referring to non-existent variables and calling functions with wrongly type arguments is undeniable time saving in my opinion. Types also enable better refactoring automation and autocomplete. All of these are great for small projects and even better for big projects with lots of team members. What advantages does dynamic typing have that could outweigh those factors?

tyrw 9y ago

It's hard to take anyone seriously who doesn't even spell the name of the thing they're opining on correctly. I'd venture to say you've never used Vue in a meaningful way so probably aren't qualified to make a comparison.

doublerebel 9y ago

Jade/Pug templates (been around for years, and are the ExpressJS default) also offer the same feature of being just "a combination of JavaScript and HTML elements". I haven't been convinced yet that JSX is better, because I can do all the same things in Pug (client or server-side rendering, compile to Hyperscript, compile to Javascript) yet with cleaner syntax.