Seconded, love the ability to take it camping (car, the thing weighs a ton) along with a c40, and use standard-size baskets. Current favorite is a big bang[1] which leads to a very different resulting espresso than the stock basket - both great!
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
MIT licensed work still requires attribution, which (as far as I know) current AI models / training practices are unable to handle properly. From the MIT license text:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
> In PowerShell, structured output is the default and it seems to work very well. This is probably too far for Unix/Linux, but a standard "--json" flag would go a long way to getting the same benefits.
OP has a blog post[0] which describes exactly this. `jc` is described as a tool to fill this role "in the meantime" -- my reading is that it's intended to serve as a stepping stone towards widespread `-j`/`--json` support across unix tools.
If there is to be a push to add structured data to all the unix tools, I wish they would use a format that allows embedding binary data. Yes base64 is an option, but it suffers from the issue that base64(base64(base64(data))) leads to exponential overhead.
Lovely to see. I'm especially excited to discover it also seems to work for horizontal auto-sizing of <input> elements! Have grid-hacked that one more often than textareas.
If anyone wants to play with this, the flag is called "Experimental Web Platform features" in Chrome Canary. Searching for "web experiments" (flag mentioned in post) under chrome://flags turns up nothing.
Yes, we're using Vue 3 and composition-style components over at https://radiopaper.com. My only gripe is that Vue's standard templates can't be typed as thoroughly as JSX can (IME - after mixed experiences with Vetur/VTI[1]), but we've been gradually migrating everything to TSX via render functions[2] and finding it perfectly capable. Added bonus is an ease of composition of template code – small local-use components can easily be split out within the same file for readability, in contrast with Vue SFC's. Vue even has true "function components" now! [3] (nice to have in really minimal cases)
I love Vue 3, but 99% of the reason I love it is the SFCs and not using JSX/TSX most of the time. Vue can't optimize render functions as well as it can optimize templates, and templates are significantly more approachable for people like me who come from the design/HTML/CSS world and want to contribute to the codebase (especially since most front-end devs coming from JS world suck at HMTL/CSS).
Is typing really the main issue there? Working in render functions and TSX is sooooo much more clunky for doing the same basic things, and you lose all the nice benefits of Vue's SFCs and things like built-in class array logic.
Excruciatingly contrived, but does this sort of arithmetic work in the Hack syntax? I'm genuinely curious, couldn't find any mention of modulo (or remainder) in the proposal.
> ...so only the first usage of `%` counts as a replacement?
Hopefully not because there’s no reason to: in the same way you can use + or - as prefix or infix, % as value and % as binary operator are not ambiguous.
% % %
should not be an issue, though it’s useless and not exactly sexy looking.
> I'm surprised they aren't going with an idiom like `$1`, `$2`, etc
That makes no sense, $1, $2, and $3 are different parameters.
Using your example,
|> `${$3.id}: ${$1.friendlyName} ${$2.url}`
makes absolutely no sense.
Not to mention the very minor issue that $1 is already a valid JS identifier.
> or something like in other languages that have "magic" lambda parameters.
% is one of those, it’s what closure uses for its lambda shorthand. Scalia uses `_` and kotlin uses `it`.
The latter two are ambiguous but I guess since pipes are new syntax there wouldn’t be a huge issue making them contextual keywords.
Most language with “pipelines” are curried so it’s not a concern, and in the rest it tends to be a fixed-form insertion, so it’s quite inflexible, but in both cases APIs are designed so they play well with that limitation e.g. in curried language you’d have the “data” item last (that’s obviously in Haskell), which also allows for partial application in general, while in “macro” languages, well, it depends where you decide the magical argument should be inserted (IIRC in Elixir it’s the first, so functions written for pipe compatibility should take the main operation subject first).
Clojure is cool because it has both plus a macro where you give it the name of the substituted symbol. However being a lisp the pipe macros are still prefix, not infix.
>That makes no sense, $1, $2, and $3 are different parameters.
>Using your example,
|> `${$3.id}: ${$1.friendlyName} ${$2.url}`
>makes absolutely no sense.
That's not what I was saying. I was saying that using `$1`, `$2`, and `$3` _would be different parameters, which would be good at helping disambiguate_.
That would enable this, from my example:
|> `${$1.id}: ${$1.friendlyName} ${$1.url}`
while also enabling something like this:
|> `$1.indexOf($2)`
...whereas just sticking with the single `%` means you _can't_ disambiguate, and that if they instead try to allow disambiguation by deciding that the first `%` is `$1`, and the second `%` is `$2` (and so on), then now you can't use the template-string example I gave.
Having unique "magic scope variables" at least allows you the flexibility to handle non-unary use-cases.
Either way, this is another case of "every lexer/parser has to be riddled with special cases" to handle "is this `%` a fancy-pipeline-identifier, or is it an operator?"
Enable for what? A pipeline threads a value through a sequence of operation, there is no second parameter.
> ...whereas just sticking with the single `%` means you _can't_ disambiguate
Which doesn't matter because there is nothing to disambiguate.
> Having unique "magic scope variables" at least allows you the flexibility to handle non-unary use-cases.
Which do not and can not exist.
And even if they did (which, again, they don't), you could do exactly what Clojure does with its lambda shorthand: %1, %2, %3, %4.
> Either way, this is another case of "every lexer/parser has to be riddled with special cases" to handle "is this `%` a fancy-pipeline-identifier, or is it an operator?"
There is no special case, having the same character be a unary and binary operator is a standard feature of pretty much every parser. Javascript certainly has multiple, as well as operators which are both pre and post-fix.
We've been leaning heavily into Vue3+TSX over at https://radiopaper.com which addresses some of these gripes. It's true there's more "magic" and ceremony around creating components than just a simple function, but not much – you just return what you expect to render from the `setup` component method and all is well. You also get niceties like well-typed props & emitted events, and even runtime prop data validation if desired, built right in.
Vue3 also has `FunctionalComponent` now for the cases where you really want a simple component from a function – and again props work beautifully with Typescript.
In contrast, I'm finding integrating Typescript with the largely-JS React codebase I work with on the day job to be a bit nightmarish – the amount of prop destructuring which seems to happen in every single component makes typing their signatures a repetitive, tedious affair (largely due to TS's handling of destructured arguments). I'm not sure how universal this style is in modern React but I do seem to come across it pretty frequently. To be fair, React's simplicity does make it eminently typeable, this is more of a code-stylistic issue.
All that said, appreciated reading your take on the two frameworks – it's extremely difficult to remain objective about the tools we use day in and out and these sorts of comparisons absolutely help. We all want to be moving towards systems we enjoy building with and will continue enjoying for decades - I for one am infinitely grateful to React and its community for bringing JSX/TSX into the world (which I'm sure is still a somewhat controversial stance in 2022- but for me personally, after a 6 or so months with it, the firsthand experience told me all I needed to know). Happy xmas to you!
> Vue3 also has `FunctionalComponent` now for the cases where you really want a simple component from a function – and again props work beautifully with Typescript.
This kind of reinforces my point about having to learn Vue. I personally think it's just unnecessarily building more API to memorize on top of JavaScript.
> In contrast, I'm finding integrating Typescript with the largely-JS React codebase I work with on the day job to be a bit nightmarish – the amount of prop destructuring which seems to happen in every single component makes typing their signatures a repetitive, tedious affair (largely due to TS's handling of destructured arguments).
To be fair, I find issues with this with TypeScript everything. Moreover, I think that is the natural progression for all typed systems or languages. I honestly prefer JS without TypeScript. I may use TypeScript some times for certain areas like having enums.
> All that said, appreciated reading your take on the two frameworks
Fair points. I feel the need to clarify that you don't _need_ to use `FunctionalComponent` in bare JS, it just gives you an opportunity to type your component props (all `FunctionalComponent` is is a TS interface). This works just fine, from a `.tsx` file:
```
const MyComponent = ({ greeting = 'Hello' }) => <p>{greeting} world!</p>;
```
and can be used in TSX or standard-Vue templates as
```
<MyComponent greeting="Hi" />
```
There is certainly more surface-area to learn about than React, though my feeling is that hooks have evened that equation quite a bit (one React component class vs. a whole quirky hooks toolkit; and admittedly Vue has forms of both as well). I'd argue both are far less to learn than Angular – I've had a tiny bit of experience there and recall feeling continually lost. I also think there are tradeoffs that justify extra bits of learning, but that's a subjective matter that (imo) can only be informed through some amount of firsthand experience building something complex with the frameworks.
Typescript is not everyone's cup of tea! Tradeoffs abound there – personally while I agree it can be cumbersome, I have trouble going back at this point (though I will when necessary). Interesting that you enjoy enums – I do as well but have found a distaste for them in the TS community which saddens me.
Prop destructuring isn't necessary. A lot of people changed to accessing the props via property access and this is often a better approach for conciseness. Don't force yourself to do something stylistic if it doesn't fit!
Thanks for weighing in, that's good to know. After wondering if this could be auto-refactored, I came across https://github.com/jsx-eslint/eslint-plugin-react/blob/maste..., will definitely have to give that (with `--fix`) a try in the new year and see if I can get the team on board! – desire for typescript being a compelling factor.
Personally I do like the non-destructured `props.abc` throughout component code, really helps clarify at a glance where something is coming from, whether it's locally or externally defined, etc. Code style is an endless exercise in compromises/opinions though, even _with_ tools like eslint and prettier.
reply