I still don't understand why they had to introduce a proprietary file format. It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format. Unfortunately, developing those takes time – apparently more than 10 years: To this day (I set up a new Vue project just a few days ago) there are countless bugs in vue-tsc and Volar.
What's worse, type checking was largely an afterthought in the development of Vue. Can we, as an industry, please finally agree that languages & frameworks with proper (tools for) static type checking are infinitely better than those without, instead of having to painfully re-learn that lesson time and again? Heck, even Python devs are using type hints these days!
> It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format.
React has (but does not require) JSX. It introduced a new file format: jsx or tsx. JSX is not valid JavaScript syntax. Hence, tooling needs explicit support for JSX. For an editor/IDE, that means it needs to add a relatively easy new syntax and a couple of custom React attributes. Obviously, there is a little more to add React support to an IDE, but this is the very first step.
Vue has (but does not require) single-file components. It introduced a new file format: vue. Vue files are already valid HTML syntax. For an editor/IDE, that means it does not need new syntax but only a couple of custom Vue attributes. Obviously, there is a little more to add Vue support to an IDE, but this is the very first step.
Sure but that is as helpful as saying a Word document (.docx) is a valid ZIP file. The tags in Vue files are merely containers of the actually interesting stuff.
What matters for most (all?) tools is that the file is a valid HTML syntax. Most (all?) tools don’t care if the document it self is valid HTML. I don’t think I’ve used a single developer tool which stops working if I remove the <title> tag, nest <a> elements or even insert a self closing <div /> tag.
Vue uses @:[]. in their attributes and these are valid HTML attribute syntax. HTML attribute syntax only disallows SPACE"'>/= and some specific code points. Everything else is valid syntax.
> What's worse, type checking was largely an afterthought in the development of Vue
I'm not sure what you mean. For Vue 3 it was a priority and extensive work went into exposing types that would make it easier for IDE tooling to integrate. Features like the `defineProps` macro are specifically designed to make TS development easier.
Right, for version 3. And type checking & IDE support still don't work glitch-free.
> Features like the `defineProps` macro are specifically designed to make TS development easier.
As you say, in more recent Vue versions, defineProps is a compiler macro, no longer something you `import […] from 'vue'`. So IDE developers had to put in effort to support it.
Couldn't agree more. We've been having good luck working with TSX-templated Vue components (using "render functions"[1]) after getting fed up with gaps in VTI back in the day – most of https://radiopaper.com is built in this way and we're closing in on it all being so. We haven't run into any issues with Vue's (alleged) lack of ability to optimize TSX templates in certain ways as opposed to traditional Vue templates – maybe comes down to the nature of our use cases – but our view is that this trades off against many other benefits:
- File extensions are all .tsx, and thus work with bog-standard editor tooling and syntax highlighting
- We're more confident about typechecking in templates, because template code is 1 minor transformation away from raw typescript, and basic `tsc` has understood TSX well for years now. Up and down the component stack, it feels like we understand typings better without "gaps" at each template layer.
- Scoping of values in templates is easier to understand. Everything you write is what it says it is, it's just whatever's in the same scope as the template. There are no transformations, no omissions of various words, no magic.
- It's easier to compose templates from small easy-to-understand parts in the same file, without fragmenting code across many small components. Not everything needs to live in a `<template>` tag separate from your `<script>` tag.
- When React folks have joined the team they've had no problem ramping up.
- By the way, in Vue TSX you just say "class" not "className" which is refreshing.
Feel free to email me at evan at radiopaper dot com if any of this interests you – we're currently working on expanding the team and looking for like-minded people interested in contributing.
Hi Evan! That sounds really interesting! Would you have a short code example for me, demonstrating what your typical Vue component looks like? Is it similar to the examples at the end of https://vuejs.org/guide/extras/render-function.html ?
I'd also be interested in how you write (S)CSS for your components – do you use some form of CSS-in-JS?
CSS-in-JS has been a challenge – we're currently using https://github.com/astroturfcss/astroturf which seemed the simplest zero-runtime-cost option back when we were looking, but the library is starting to feel a bit under-maintained (if the author of Astroturf reads this, we love your work and will do whatever we can to support you in it!). But it's worked well for us over the last 2 years.
Happy to share a component example. We also use a small library for managing CSS classes in a typed fashion, which can also be used by our UI test code to target various elements. So that does add a bit of cryptic boilerplate, but the repo README has an example component with syntax highlighting:
https://github.com/evnp/namespace.style#usage
You still need a full JS(x) parser (and lexer) though since / symbols are contextual (as are < in JSX).
/ and < in operator positions becomes operators, whilst / in plain JS in a value position becomes the start of an reg-exp and < becomes the start of an JSX tag, so to handle it there needs to be a full parser (with a pull-lexer to correctly handle the contextual part) as you cannot just do a textual replacement due to ambiguity.
Typescript supports JSX out of the box. It was once true you need custom tools for React, but JSX has proven useful enough that support is provided almost anywhere you need it. Also, as someone else mentioned, JSX is really just syntactic sugar around vanilla JS, so supporting it is much easier.
You don't, because JSX is not required for react. This isn't even just a theoretical point, but something I've actually done in the past several times; it's very convenient to just try something out by throwing react into a script tag and then just writing a small prototype or something without utilizing JSX and thus avoiding the need to set up a build system and everything else. I would still use JSX for larger projects, of course, but it is mostly just a small quality-of-life improvement, and I'd be using react even if JSX didn't exist, as the actually important parts of the library are not about JSX.
> You don't, because JSX is not required for react.
And what does this have to do with the fact that the absolute vast majority of react code is written with JSX and that you need special tools in IDEs to deal with React code (because regular JS tools would break)?
Does anyone know of a good open source syntax highlighting library for Vue SFC? That’s my biggest issue with the file format (I maintain a code review tool)
I moved away from JetBrains to VSCode a while ago because of bugs related to Vue. Now, a week ago, I moved back to JetBrains because of a bug in Volar. Sigh.
What's worse, type checking was largely an afterthought in the development of Vue. Can we, as an industry, please finally agree that languages & frameworks with proper (tools for) static type checking are infinitely better than those without, instead of having to painfully re-learn that lesson time and again? Heck, even Python devs are using type hints these days!