4 ms·

I'm a little worried on behalf of the "Python Language Tooling Team" at Meta, because uv has been so popular, and I wouldn't be surprised if ty wins out in this

by lacker 1y ago

I'm a little worried on behalf of the "Python Language Tooling Team" at Meta, because uv has been so popular, and I wouldn't be surprised if ty wins out in this space. So watch out, or this will become like Atom or Flow, an internal competitor of a technology that is surpassed by the more popular external open source version, leaving the directors/vps muttering to themselves "It's too bad that this team exists at all. Could we get rid of them and just switch to the open source stuff?" Perhaps just something for the manager (Aaron Pollack?) to keep an eye on....

90s_dev 1y ago
JSX is my favorite thing to come out of Facebook (also the only good thing).
- owebmaster 1y ago
  I feel bad for that people that love JSX and don't know about lit-html yet.
  - 90s_dev 1y ago
    JSX supports * Autocompletion * Type checking * Syntax highlighting * Lack of runtime string parsing Tagged template literals don't.
    - owebmaster 1y ago
      JSX does not support any of these, it was coded by others. tagged template literals can have all of these, some already exist¹ and doesn't need a build step. 1. https://marketplace.visualstudio.com/items?itemName=bierner.lit-html https://marketplace.visualstudio.com/items?itemName=bierner....
      - 90s_dev 1y ago
        Matt, who works pretty high level on VS Code, has written some amazing plugins. But they still don't have all the first-class features of JSX. I don't think this plugin works with type checking for instance.
        ffsm8 1y ago
        I believe the argument was that jsx doesn't support that either, which should be correct as far as I know. They're all features in the jsx ecosystem that are provided by other libs, which are often preconfigured with projects utilizing jsx. I did miss a lot of the tooling I've gotten used to the last time I made a weekend project utilizing lit webcomponents for sure, but I believe the people advocating for it usually rejoice in having less tooling in their development pipeline - it's just a fundamental disconnect between people that have learned and gotten used to current frontend development and people that don't really want to bother with it, looking for simpler solutions with less moving parts.
      - 90s_dev 1y ago
        The only inherent feature of JSX is compile time "parsing" whereas tagged literals inherently require runtime string parsing. But yeah other than that you're right. I'm just talking about first-class VS Code support. Which to me means a lot.
        nine_k 1y ago
        Of course tagged string literals can be compiled down to a form where no string parsing occurs. This is a really old technique; I implemented it, like many others, in PHP in late 1990s. Vut inside an IDE or an LSP, tagged literal strings need quite a bit more special support than JSX, AFAICT.
        90s_dev 1y ago
        Do you mean at runtime but only once at startup, like parsing a Lua program into bytecode? Or do you mean at true compile time like Zig and Rust format strings?
      - nsonha 1y ago
        JSX has a constrained interface that is a tree of objects with some properties on each. I guess you can have a lsp for lit-html but it will inherit the unconstrained nature of html, which is everything being string, and therefore useless as a programming interface.
  - troupo 1y ago
    > and don't know about lit-html yet. You mean strings with custom non-standard syntax and weird rules of hooks, sorry, directives?
  - deleted 1y ago
    [deleted]
- deleted 1y ago
  [deleted]
samwgoldman 1y ago
Hey Kevin, we overlapped for a bit during your time at FB when I was working on Flow. Nice to hear from you! I’m working on Pyrefly now, but worked on Flow for many years before. For what it’s worth, we are taking a different approach compared to Flow and have explicitly prioritized open source and community building, something I know we both care a lot about. Of course, nothing is guaranteed and we’ve seen plenty of volatility in bigco investments to infra lately, but I do believe we’re starting this journey on the right foot. Cheers, Sam
- lacker 1y ago
  Best of luck!
theptip 1y ago
Meta seems to place a pretty high premium on controlling its open source projects, especially dev tooling. I guess dating back at least to the git maintainers telling them they were doing things wrong with their monorepo and refusing to upstream scale fixes, which precipitated their migration to mercurial (who were more than happy to take the contributions). Given the change velocity of internal tooling you can understand why owning your own project makes sense here.
simlevesque 1y ago
Like Angular.

by lacker 1y ago

90s_dev 1y ago

JSX is my favorite thing to come out of Facebook (also the only good thing).

owebmaster 1y ago
I feel bad for that people that love JSX and don't know about lit-html yet.
- 90s_dev 1y ago
  JSX supports * Autocompletion * Type checking * Syntax highlighting * Lack of runtime string parsing Tagged template literals don't.
  - owebmaster 1y ago
    JSX does not support any of these, it was coded by others. tagged template literals can have all of these, some already exist¹ and doesn't need a build step. 1. https://marketplace.visualstudio.com/items?itemName=bierner.lit-html https://marketplace.visualstudio.com/items?itemName=bierner....
    - 90s_dev 1y ago
      Matt, who works pretty high level on VS Code, has written some amazing plugins. But they still don't have all the first-class features of JSX. I don't think this plugin works with type checking for instance.
      - ffsm8 1y ago
        I believe the argument was that jsx doesn't support that either, which should be correct as far as I know. They're all features in the jsx ecosystem that are provided by other libs, which are often preconfigured with projects utilizing jsx. I did miss a lot of the tooling I've gotten used to the last time I made a weekend project utilizing lit webcomponents for sure, but I believe the people advocating for it usually rejoice in having less tooling in their development pipeline - it's just a fundamental disconnect between people that have learned and gotten used to current frontend development and people that don't really want to bother with it, looking for simpler solutions with less moving parts.
    - 90s_dev 1y ago
      The only inherent feature of JSX is compile time "parsing" whereas tagged literals inherently require runtime string parsing. But yeah other than that you're right. I'm just talking about first-class VS Code support. Which to me means a lot.
      - nine_k 1y ago
        Of course tagged string literals can be compiled down to a form where no string parsing occurs. This is a really old technique; I implemented it, like many others, in PHP in late 1990s. Vut inside an IDE or an LSP, tagged literal strings need quite a bit more special support than JSX, AFAICT.
        90s_dev 1y ago
        Do you mean at runtime but only once at startup, like parsing a Lua program into bytecode? Or do you mean at true compile time like Zig and Rust format strings?
    - nsonha 1y ago
      JSX has a constrained interface that is a tree of objects with some properties on each. I guess you can have a lsp for lit-html but it will inherit the unconstrained nature of html, which is everything being string, and therefore useless as a programming interface.
- troupo 1y ago
  > and don't know about lit-html yet. You mean strings with custom non-standard syntax and weird rules of hooks, sorry, directives?
- deleted 1y ago
  [deleted]
deleted 1y ago
[deleted]

samwgoldman 1y ago

Hey Kevin, we overlapped for a bit during your time at FB when I was working on Flow. Nice to hear from you! I’m working on Pyrefly now, but worked on Flow for many years before. For what it’s worth, we are taking a different approach compared to Flow and have explicitly prioritized open source and community building, something I know we both care a lot about. Of course, nothing is guaranteed and we’ve seen plenty of volatility in bigco investments to infra lately, but I do believe we’re starting this journey on the right foot. Cheers, Sam

lacker 1y ago
Best of luck!

theptip 1y ago

Meta seems to place a pretty high premium on controlling its open source projects, especially dev tooling. I guess dating back at least to the git maintainers telling them they were doing things wrong with their monorepo and refusing to upstream scale fixes, which precipitated their migration to mercurial (who were more than happy to take the contributions). Given the change velocity of internal tooling you can understand why owning your own project makes sense here.

simlevesque 1y ago

Like Angular.