Hacker News Reader

Comment by petilon | Hacker News Reader

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.

View on HN

I love React but you're completely wrong here. Vue has JSX support as well 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.

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

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

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-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.

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) with yet another NIH looping and conditional syntax. Perhaps it's possible to avoid - but that kind of flexibility simply encourages messy codebases.

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

Not a requirement per se, sure, but it's strongly suggested and other usages are not idiomatic.

That is simply skipping the transpiling of JSX, the structure/nesting is the exact same, not some DSL crafted for templating.

React without JSX is very clunky at best.

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.

Styled components solves this problem very nicely

https://github.com/styled-components/styled-components

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.

> 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.

Vue templates are checked at compile time with the default runtime-only distribution, and the DSL it uses is arguably more checkable than JSX.

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.

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.

> 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?

... What was the point of this reply? It doesn't change or refute anything I said before. All this has been discussed millions of times, why would I engage in a discussion that has been happening for sixty years?

You can read on advantages of dynamic languages everywhere, I was just pointing out that your point of view, and the point of view disagreeing with you, isn't anything close to new, making the attempt to start a flamewar in your first post, and trying to continue it here, all the more pointless.

BTW: Good coders are factor because no amount of "you have to write 'string' or 'int' before the name of the variable" is going to save a bad coder from producing bad code.

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

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.

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.

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.

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.

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.

Yeah, that's true. Devs spend too much time pixel-wrangling in the minutae of CSS.

But, for me, it's not just the styling, but the architecture and componentry for modeling out async, event-driven web apps in a more natural way. And, I think that's the piece you're referencing that Swing can add to Bootstrap-alone.

I would agree that the deep inheritance hierarchies in verbose OO environments like Java actually do make sense for UI work. I think that's the one area in which they actually do make sense. Otherwise, it's all mostly a fantastical contrivance that leads to far too much boilerplate.

Checkout Element [0], in my opinion it comes very near to a "Swing for browsers". There is a version for Vue.js and React.

[0] http://element.eleme.io/#/en-US

Check Vaadin. Might suit your taste.

Just took a glance. Great tip. Looks promising. Thanks!

You can sort of do this with Emscripten + webasm, though I don't think async is supported yet.

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.)

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

Reply on news.ycombinator.com