51–60 of 140 posts
Earlier quoted context omitted.
Rome is the current capital of Italy... not a mythical or ancient thing.
Roma is the current capital of Italy. Rome was an ancient city.
https://www.merriam-webster.com/dictionary/Rome
https://www.online-latin-dictionary.com/latin-english-dictio...
I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each verti…
Your comment says to me anxiety largely just at violating conventions of popularity. Your only hesitation is an appeal to authority. There is no consideration of merit or anything technical.
As a developer, I haven't had any qualms with ESLint, so I wouldn't really have any reason to pick up Rome. Now if the full tool set offers lots of things, then I might consider replacing my current Vue template / create-react-app, but that's a big step.
All of this to say, no, it's not an appeal to authority. It's sounds like a "I'm not sure I can imagine this being worth switching to because we have something that works and is stable now, and we haven't had a great track record with tooling churn in JS world". It's a value add question.
Why a focus on frontend only? I am using Typescript, Babel, Jest and a bundler for any app/library on the frontend/backend. If you got to do it, do it all the way! I can already see the GH issues, “sorry, this is a backend use case”. So now my tooling would end up being more complex with the addition of another tool since it will never support all my use cases. Seemed promising but this alone makes me question its ut…
Why start this from scratch ? Why not build on top of TypeScript ? I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript compiler ? I'm just wondering because Microsoft has a decently sized team of paid engineers working on TS for years now - what are the odds an OSS project outperforms them at implementing their own language (which they also evolve with every release)
The TypeScript compiler API[1] is beta, underdocumented, and not really designed to support use-cases other than working with an abstract AST. It’s OK for transpiling, but would be a bit awkward for writing a linter and not at all suitable for a formatter. As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish…
Why start this from scratch ? Why not build on top of TypeScript ? I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript compiler ? I'm just wondering because Microsoft has a decently sized team of paid engineers working on TS for years now - what are the odds an OSS project outperforms them at implementing their own language (which they also evolve with every release)
I think the odds are pretty good. The TypeScript compiler's performance is not optimal: https://twitter.com/evanwallace/status/1275945317045657602 . Microsoft's TypeScript team has a lot of priorities and other things likely take precedence over performance work. Also it's pretty trivial to build a faster compiler if you don't have to worry about type checking. You can still have type checking with a bundler that ign…
Why a focus on frontend only? I am using Typescript, Babel, Jest and a bundler for any app/library on the frontend/backend. If you got to do it, do it all the way! I can already see the GH issues, “sorry, this is a backend use case”. So now my tooling would end up being more complex with the addition of another tool since it will never support all my use cases. Seemed promising but this alone makes me question its ut…
Earlier quoted context omitted.
The TypeScript compiler API[1] is beta, underdocumented, and not really designed to support use-cases other than working with an abstract AST. It’s OK for transpiling, but would be a bit awkward for writing a linter and not at all suitable for a formatter. As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish…
I get that - but since TS is also OSS you can fork and upstream, still sounds like less work than writing everything from scratch.
the prevailing consensus esp in the JS world is that 1 tool should do 1 thing. This is fine under the Unix philosophy, but challenges arise due to the combinatorial explosion of config needs, bad errors, and overhead from crossing module boundaries. There are a number of attempts at challenging this status quo: - ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go bi…
I just know that every time I revisit any JS front-end stuff, I end up punting and just manually adding script/stylesheet includes for Vue and Bootstrap or whatever so I don't need to deal with half that crap. As an outsider it's always so daunting, and I feel like whatever I learned 6-12 months ago last time I needed to do something doesn't necessarily apply anymore.
I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each verti…
Even if it somehow manages to succeed at its mission and become the defacto toolchain for all of frontend, I feel its improvements over the status quo will be short lived, and over the long run having a monolithic toolchain dominate will prove to be a net-negative for the frontend tooling ecosystem.
Having a single defacto monolithic toolchain greatly raises the barrier to entry for new competing tools, as they'd no longer be able to just compete on the merits of doing any individual task better than its direct competition to gain adoption.
Having different single purpose tools that can people can pick and choose from independently of each other is a crucial part of what has enabled rapid innovation in the JS tooling ecosystem up till now, since it keeps implementation/switching costs for any individual tool as low as it can reasonably be for that specific use-case.
This comes at the cost of making it harder for any individual to keep up with all the latest innovations (as critics of the JS tooling ecosystem are often quick to point out), but projects like create-react-app have been fairly successful at addressing this through sourcing collective wisdom from the community to create a collection of best-in-class tools configured to work effectively together out of the box.
I can also totally emphasize that there are many low-hanging fruits in terms of efficiencies to be gained through unifying tooling to avoid wasted work and maintenance overhead, but I'm of the opinion that the gains in efficiency isn't going to be worth the cost in potential for stifled innovation, and that those efficiencies are better achieved through shared specs and shared low-level libraries that individual tools can choose to adopt if they become compelling enough.
I'm personally still going to be rooting for single purpose tools + curated collections over any monolithic toolchain.