[HN Gopher] Swc4j: SWC for Java
___________________________________________________________________
Swc4j: SWC for Java
Author : stefankuehnel
Score : 67 points
Date : 2025-01-03 23:52 UTC (23 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| timcobb wrote:
| What are some use cases for this?
| olavgg wrote:
| Javascript bundling for Spring Boot applications?
| timcobb wrote:
| Seeing this also
| https://news.ycombinator.com/item?id=42592524
| lemming wrote:
| Oh my word, there may finally be a Typescript parser for the JVM?
| I have wanted this for the longest time, and it's been on my
| radar to take on as a project in the near future. If this is a
| reasonably complete parser, this will save me a ton of time. My
| use case is parsing Typescript type definitions.
|
| Edit: unfortunately, this seems to be a JNI bridge to the Rust
| code in SWC, I was hoping for a JVM-native solution.
| AdieuToLogic wrote:
| > My use case is parsing Typescript type definitions.
|
| > Edit: unfortunately, this seems to be a JNI bridge to the
| Rust code in SWC, I was hoping for a JVM-native solution.
|
| Maybe tree-sitter[0] TypeScript support[1] could do the trick?
| Tree-sitter is a parser generator tool and an incremental
| parsing library. It can build a concrete syntax tree for a
| source file and efficiently update the syntax tree as the
| source file is edited.
|
| HTH
|
| 0 - https://tree-sitter.github.io/tree-sitter/
|
| 1 - https://github.com/tree-sitter/tree-sitter-typescript
| zamalek wrote:
| Tree sitter has a C runtime, and often a C scanner.
| lemming wrote:
| Right, that would be another native bridge solution.
| AdieuToLogic wrote:
| See my peer comment for another option. :-)
| AdieuToLogic wrote:
| If the tree-sitter runtime requirements are prohibitive and
| a pure JVM solution (IOW, no JNI) mandatory, then I'd
| recommend using antlr[0] with its representative grammar[1]
| as a starting point. See here[2] for more details.
|
| 0 - https://www.antlr.org/
|
| 1 - https://github.com/antlr/grammars-v4/blob/master/javasc
| ript/...
|
| 2 - https://github.com/antlr/grammars-v4/wiki
| sjtucaocao wrote:
| I'm the maintainer of swc4j. I had been using Antlr for
| many years, but was deeply disappointed by Antlr. So I
| created swc4j.
|
| Why Antlr is not the one? Hope the following blog I wrote
| may explain.
|
| https://blog.caoccao.com/hello-swc4j-goodbye-
| antlr-f9a63e45a...
| lemming wrote:
| I agree that the Antlr Typescript grammar is
| underwhelming, and I also agree with the difficulty of
| not having a well defined owner of the project to
| interact with. My main use case is parsing TS type
| definitions, and the grammar from the grammars-v4 repo
| doesn't parse anything starting with 'declare', which is
| pretty fundamental.
| maxdamantus wrote:
| I get the sense that treesitter is more for syntax
| highlighting than for real parsing, since I raised this
| issue[0] a while ago and I don't think anyone's really
| interested in it (not really interested enough myself in
| tree-sitter to see if it can be fundamentally solved; solving
| it involves making almost all production rules in the grammar
| parametric over two booleans).
|
| Admittedly I haven't tested the TypeScript treesitter
| grammar, but I'd be surprised if the issue is fixed there.
| I've put together a sample file[1] that demonstrates various
| cases of these context dependencies. If I remember correctly,
| Sublime's highlighter was the best at handling these cases
| out of various editors I tried, though it still failed at
| some of the ones at the bottom involving multi-line function
| expressions within object literal keys. GitHub/gist uses
| treesitter, so you'll notice that sometimes the "REGEX" and
| "DIVISION" blocks are inconsistently coloured, but a correct
| parser should associate a colour consistently to them. Not
| demonstrated here, but inserting a multi-line comment in a
| file that is parsed incorrectly will throw the entire thing
| off.
|
| [0] https://github.com/tree-sitter/tree-sitter-
| javascript/issues...
|
| [1] https://gist.github.com/Maxdamantus/a11b41675fcde25ffc9b7
| ef0...
| aclatuts wrote:
| Just curious as to why you would want that?
| lemming wrote:
| I want to use Typescript types to improve IDE support for a
| compile-to-JS language (ClojureScript).
| sjtucaocao wrote:
| I'm the maintainer of swc4j. I'd like to share some of my
| thoughts for your reference.
|
| Before swc4j was born,
|
| 1. I was deeply disappointed by Antlr. My blog
| https://blog.caoccao.com/hello-swc4j-goodbye-antlr-f9a63e45a...
| explains why. 2. I could use Babel in Node.js on JVM (using
| another project Javet created by me) to meet the business
| requirements, but Babel's performance is 10x-100x worse than
| swc's. 3. There was nothing else better. 4. swc is one of the
| best solutions in front-end toolchain. It's well maintained.
| Its community is healty. It is being used by Node.js and Deno.
|
| So I decided to try to embed swc in JVM. After a month of
| intensive development from scratch, swc4j was alive. In my
| opinion, its design has to be a genuine swc library bridged by
| JNI or other native interop mechanisms on JVM for the following
| reasons.
|
| 1. The dev cost of reinventing the wheels on JVM is unbearable
| to me. Tracking the JS / TS / JSX / TSX / ... specs from time
| to time requires a dedicated team. 2. The performance overhead
| is subtle. 3. The behavior is identical to the genuine swc.
| That brings confidence to the swc4j users.
|
| Hope these make sense.
| lemming wrote:
| Thanks for the reply, I think your reasons make total sense
| for your use case and I was also underwhelmed by Antlr, or at
| least the TS grammar for it. But I don't need the vast
| majority of what SWC offers, I just need a type declaration
| parser - that seems like it should be much more tractable to
| keep up to date, especially since there's a massive test
| suite in DefinitelyTyped.
| sgammon wrote:
| elide has a typescript layer for graaljs
___________________________________________________________________
(page generated 2025-01-04 23:01 UTC)