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.
https://facebook.github.io/react/docs/react-without-jsx.html
- 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.
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
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.
I'm still amazed people argue that statically typed languages don't make you more productive compared to dynamically typed languages.
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.
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?
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.
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.
Shame it came with such an unwieldy deployment model that it never gained more traction.
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.
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.