11 ms·

Announcing Rome Tools, Inc.

201 points by sebastianmck 5y ago

cpojer 5y ago
The JavaScript tooling ecosystem is fragmented, bloated and slow. Rome is the best - and currently only - bet to fix this. I’m excited!
- yewenjie 5y ago
  Why do you think this is the only bet? What about things like Snowpack, Vite, and Esbuild?
  - cpojer 5y ago
    Those are all great bundlers/dev servers but they aren’t as ambitious as Rome. Rome aims to be the one tool that handles everything: compiling, bundling, testing, linting and everything else.
    - inglor 5y ago
      You can also do that with Deno: - Built in testing library - Lint with `deno lint` - Bundle with `deno bundle` - Format with `deno fmt`
    - thiht 5y ago
      And it will be the one tool that handles everything poorly. Linting (eslint) and testing (jest) are solved problems, there's no way I'll migrate to Rome for these. They should focus on bundling which is the current pain point (although my bet is more on esbuild).
  - swyx 5y ago
    bad examples - the better one is Deno.
- vijaybritto 5y ago
  How will Rome be faster than the other tools when its also written in Typescript? I see that unification will be an advantage but I dont think it will be faster than others. Especially when native code/wasm based tools are already available. (esbuild/swc/rslint) The positives I see are: - No fighting with different versions of different tools when upgrading - Simpler configurations But I dont see any other reasons to convince people to use Rome.
blocked_again 5y ago
> Together, we’re announcing that we’ve raised $4.5 million in seed funding, led by A.Capital Ventures and OSS Capital. VCs fund startups which has the potential to 100x their returns right? How is that going to work here? How will they monetize a javascript library? Will we have an IPO for a javascript library? Or are they betting on a big tech company to acquire a Javascript library for 100s of millions of dollars? I am confused.
- ruffrey 5y ago
  Healthy skepticism is good. Dev tools are hard. There are hundreds of open source companies - many making gobs of money. Not all - many fail. This team has name recognition and a few successful projects already - Babel and yarn. I can see it working out. JavaScript is one of the most popular programming languages. Millions of developers. With solid execution, there are monstrous markets here.
  - throwaway91_82 5y ago
    this team also has had at least one example of unilateral non-open source decisionmaking https://www.vice.com/en/article/pawnwv/open-source-devs-reverse-decision-to-block-ice-contractors-from-using-software https://www.vice.com/en/article/pawnwv/open-source-devs-reve...
    - vosper 5y ago
      Is it a given that because the software is open-source, the decision-making will be, too? Almost seems there should be a separate set of claims for what the decision-making process will be (like how there are various software licenses).
      - ipsum2 5y ago
        From the article: > Eric Raymond, the founder of the Open Source Initiative and one of the authors of the standard-bearing Open Source Definition, said Kyle’s decision violated the fifth clause of the definition, which prohibits discrimination against people or groups.
ruffrey 5y ago
It’s a difficult, painful problem - meaning there’s an opportunity. Sebastian has the grit to deliver. What’s the business model?
- sebastianmck 5y ago
  Supplemental services that integrate with the tool. Think code quality monitoring, error reporting, and core enhancements like a remote cache. There's a lot we're going to be experimenting with.
  - inglor 5y ago
    I'd pay for fast remote builds that integrate into my source control (GitHub and Azure DevOps) and creates production builds fast.
coward76 5y ago
Can someone tell me how this is different than something like webpack?
- abc11283 5y ago
  This question is answered literally on the front page of their website.
throwaway91_82 5y ago
possibly sensitive question - i recall Sebastian and Kyle had their differences during the ICE issue of 2018 https://www.vice.com/en/article/pawnwv/open-source-devs-reverse-decision-to-block-ice-contractors-from-using-software https://www.vice.com/en/article/pawnwv/open-source-devs-reve... what are Rome's intended policies on OSS licensing and usage by ICE?
- abc11283 5y ago
  I think there’s a difference between “objectionable organizations” using what is available as OSS, and them being allowed on the platform that the company intends to develop.
abc11283 5y ago
Disclaimer: I know the foundation of Rome was largely written by Sebastian. This question still applies to Rome though, but more so to “open source companies” in general. https://rome.tools/credits/ https://rome.tools/credits/ How many of these people are going to receive an employment opportunity from this company? How many will receive equity? I suppose the same questions can be asked if any big project, like React, though that had FB’s backing from the get-go. I understand that OSS needs funding from somewhere, and I am incredibly optimistic about Rome, but I’d think it a bit disheartening to be surprised by this announcement as a contributor.
- swyx 5y ago
  thats not how OSS contributions work. you contribute of your own free will, they don't owe you any equity or employment. of course you'd have a leg up on hiring but they don't owe you a thing.
  - abc11283 5y ago
    I know how OSS works. I just think the transition from being a community-oriented project, to one that will create a lot of value for a small group of people, will be interesting to watch. They certainly deserve any and all success, I just wonder how those decisions will be made.
- deleted 5y ago
  [deleted]
- sebastianmck 5y ago
  I've been keeping the core contributor team updated on the funding process since December. We've also been publicly speaking about it in the Rome Discord server too. I posted about securing funding in early April in #general. Emanuele and Yasser both approached us during this period to offer their interest in joining and have stayed actively involved in development. It's a good question around how to compensate the shoulders of the giants you're standing on, and I don't think anyone has a good answer for that. I think it's important to note that the credits page is meant to be as exhaustive as possible. I am not aware of many other projects that have something similar, and theirs are likely to be even longer. In the end the community is getting value because we'll now be able to do more to improve the project than we otherwise would have. Babel most notably has struggled for funding and is even currently undergoing a serious funding shortage. It has been used as one of the poster children for the JS community and it's clear that donation-based funding isn't effective, at least on the order of magnitude required to support a team.
lacker 5y ago
This is pretty exciting! I'm glad to see more investment going into the JavaScript developer tooling ecosystem. Some of the open source companies have had an easier time monetizing than others. Databases, for example, have a somewhat obvious path nowadays of offering a hosted version. NPM and Docker, on the other hand, developed incredibly popular tools but struggled to monetize. So I'm curious to see what Rome will do. The other interesting question to me is what Rome will focus on. There's a really wide array of things in the JS toolchain and it's tempting to boil the ocean. How much of it can you really boil? Running a nice JS browser stack of course. Supporting TypeScript I presume. How about Node on the backend? An Electron app? All of those in the same codebase? Some tough decisions here but I'm glad the team working on them is set to grow and attack this problem. Good luck Romans ;-)
tsdlts 5y ago
After using esbuild and experiencing fast builds, I'll never go back to tools written in javascript/typescript again.
- deleted 5y ago
  [deleted]
- orta 5y ago
  FWIW, sucrase (written in TypeScript) has done a great job of being in the same ordinal of perf as esbuild: https://github.com/alangpierce/sucrase#sucrase https://github.com/alangpierce/sucrase#sucrase
  - Touche 5y ago
    That's single threaded perf, so takes away a huge advantage of Go. Also doesn't include startup time (node is slow to start)
    - serverholic 5y ago
      And memory usage.
  - lhorie 5y ago
    Sucrase "cheats" though[0]: > Sucrase bypasses most of these steps, and works like this: Tokenize the input source code into a token stream using a trimmed-down fork of the Babel parser. This fork does not produce a full AST, but still produces meaningful token metadata specifically designed for the later transforms. While this is fine for simple transformations like transpiling JSX, it's not very suitable for full-on AST analysis like some eslint plugins do. Most notoriously, Sucrase is specifically designed to be garbage-in-garbage-out, whereas Babel will throw proper errors on things like early errors. Tools written in lower level languages like esbuild can take advantage of facilities that aren't well supported in Node, such as cheap concurrent coroutines and greater control over memory layout (Babel ASTs are notoriously megamorphic and can silently fall off perf cliffs depending on how you manipulate them). These caveats are not reflected in Sucrase's benchmark. [0] https://github.com/alangpierce/sucrase#motivation https://github.com/alangpierce/sucrase#motivation
deleted 5y ago
[deleted]
capableweb 5y ago
Where is the company incorporated? In most countries, companies act for profits first. Especially if you raise funding from a few selected ones instead of the wider community. This statement reads weird too > We don’t believe in placing artificial constraints on the tool or having functionality behind a paywall. In order to support the open source project, we’ll be building supplemental products and services. This aligns our incentives with the community and our open source users, with a focus on interoperability, performance, and usability. Supplemental products and services on top of open source projects often require (down the line) the open source project to adapt because it might hurt the bottom line of these supplemental products and services. Since there is no guarantee this won't happen, if the stake is between the company surviving or a feature being open-source vs "supplemental", the people working at the company might have to chose the option against the wishes of their open source users. I don't see how creating a for-profit company is at all in alignment with open source users. Better would have been a Co-op, a non-profit, OpenCollective, or leverage an existing entity like the Linux foundation, that can actually guarantee it for you in contracts and laws.
- leodriesch 5y ago
  Sebastian actually tried fundraising, but I think the campaign got stuck at about 36k of the 100k goal. https://rome.tools/funding/ https://rome.tools/funding/ VC money is just on another level, although as you said it comes with its own difficulties.
anaclet0 5y ago
I thought Rome was a Facebook internal project. Am I missing something here?
- jillesvangurp 5y ago
  It's also a java framework for parsing RSS and Atom. I bet that there are more ways that lead to Rome :-)
  - SahAssar 5y ago
    This is that facebook project though (not just the same name), see here: https://github.com/rome/tools/blob/main/website/src/blog/posts/2020-08-08_introducing_rome.md https://github.com/rome/tools/blob/main/website/src/blog/pos... Seems like the author could take it with him when leaving facebook, which is nice.
  - yuchi 5y ago
    Parent comment was talking about this specific Rome project. And he is indeed right, it was a Facebook project at the earliest stage, but moved out of it when Seb left FB.
pier25 5y ago
Any news on plugin support (eg: Svelte)?
- FractalHQ 5y ago
  This was my first thought as well. More and more devs are beginning to discover Svelte as a milestone in the evolution of Javascript. I would be surprised if it wasn’t already on the roadmap.
  - swyx 5y ago
    second vote for Svelte support here - i'd hate for a next-gen tool like Rome to only support React when there are other great frameworks that it could handle
jillesvangurp 5y ago
I had a quick look at how they are set up and I like what they are doing from the point of view of actually creating an OSS community. I don't actually know much about what they do as I'm not one of their users. Judging this purely from a "does this make sense as an OSS company" point of view. - License: MIT. Great pragmatic choice. Generally a good fit for not obstructing your users to actually use, copying, modifying, etc. your code. Too many OSS startups play games with this and end up going for something too restrictive. IMHO not having copyright transfers is the key to longevity for any OSS community. It basically progressively removes re-licensing as an option as more contributors would have to agree to such a thing. Most long lived oss projects have long lists of contributors and no history of license changes past an early stage of their development. Also, MIT is very compatible with just about anything in the ecosystem. Given their stated goal of being good OSS citizens, that's a hard requirement. - Contributing.md: no mention of copyright transfers. Also they have close to twenty contributors. I assume this means the license will stay as it is and there are no plans to change that. Great! This is key to building a successful open source community with people actually contributing as well as using the code. It also ensures the code can survive acquisitions, bankruptcies, mismanagement of the company, etc. Committing to this upfront is important and a big step. - Community: There are seventeen contributors, most of which are not employees (I assume). And they probably integrate a lot of other libraries/tools. - Explicit stated goal that affirms the above: "The company exists to support the open source project, not the other way around.". That does raise a few question marks around valuation and ways to profit from this. I'm curious about their plans for adding value in the form of services on top of this. I assume this means some cloud based services and/or support contracts with consultancy. But then, it's good to remove the nuclear option (relicensing) from the table early on to create clarity for developers and investors that this is just not that sort of company. It's smart from a business point of view as well because most of what they do will come from outside the company anyway. The nature of the javascript community is people rapidly iterating on tools, libraries, etc. and forking left right and center as needed. So, a lot of value is going to be added through people doing exactly that. You can work with them or against them. With them is the smarter option.
- greshario 5y ago
  > License: MIT. Virtually all open source projects in the web dev community are MIT licensed, especially when it comes tooling. Choosing any other license would cause a lot of friction and prevent adoption.
devit 5y ago
Being written in TypeScript and not Rust seems quite a big liability that might see Rome never be popular or lose out quickly due to inferior performance. There is already RSLint and SWC as JavaScript tools written in Rust and I would expect such tools to take over, with a good choice of it happening before Rome is ready.
- valyagolev 5y ago
  no, much worse. they might actually win by overspending on marketing and feature-bloat, and we’ll be stuck working with slow tools
  - intergalplan 5y ago
    Yeah, I'm over here going, "oof, I hope they don't do too well by burning VC cash, or they might stifle esbuild and deno and similar efforts, and we'll remain stuck at this embarrassingly-low local maximum even longer"
    - valyagolev 5y ago
      what else would VC money be for other than a sweet vendor lock-in?
- jeroenhd 5y ago
  I don't see the relevancy of rust here, but you're right that at this point any language that compiles directly to machine code will blow any javascript tool out of the water any time. Of course, perf is only one reason to use a tool, I expect javascript based tooling to stick around for much longer because developers are used to them now. And, of course, if all you know is frontend, everything starts to look like a javascript job.
  - serverholic 5y ago
    I'd prefer my tools to use languages that are compiled + memory safe. Basically that just leaves rust or go. But rust also has other features that can help prevent bugs regarding concurrency and more. So rust is a feature in my book and not just an implementation detail.
SamBam 5y ago
This feels like a new version of Brunch. Did anyone use Brunch to build and bundle JS projects and manage dependencies? It seemed like the best thing since slice-bread at the time. I recently had to go back and update a 6-year-old project that had been written using Brunch. It took several days of painful work to extract it all out of the framework and built it using Babel. All I'd want to know with Rome is, if and when I abandon it or it gets abandoned (whichever happens first), how annoyed am I going to be that I had chosen this framework? How seamless will it be to extract my project?
gremlinsinc 5y ago
Rome sounds awesome but the branding confused me for a second... I was trying to find out how this relates to https://roamresearch.com/ https://roamresearch.com/ I guess phonetically my mind was flipping things around.
redisman 5y ago
https://xkcd.com/927/ https://xkcd.com/927/
betterfaster 5y ago
I think the future of JavaScript tooling is esbuild and SWC, written in fast compiled languages like Go and Rust. I don't see the value proposition in a brand new toolchain written in slow and memory hungry TypeScript/JavaScript.
- pictur 5y ago
  you are right but the most common tools are still made with these. I think people don't worry about performance that much. or worry, but they don't make an effort to change that.
  - vijaybritto 5y ago
    You're correct on this to some extent. Teams in our company are so fed up with webpack for local development that they are willing to skip some features it provides to use vitejs.dev for local dev. We fully couldnt avoid webpack 5 because Module federation is very very valuable.
proxyon 5y ago
I'm a senior eng in Typescript at a tech company. I will always advocate against adopting this project. Jamie is a perfect example of the toxic attitudes and activism destroying OSS and tech. Lerna or Babel are fine, but then again, they are purely OSS projects, not companies expressly designed to enrich him and reward his toxic activism.
- PleaseIgnacio 5y ago
  What kind of activism are you referring to?
  - proxyon 5y ago
    He's well known for almost torpedoing Lerna by committing an insane proprietary license where he called ICE and Palantir fascists who aren't allowed to use Lerna, and included into that any companies who ever do work for ICE or Palantir, which included Microsoft. Microsoft in response had to get to work dropping Lerna from all of its repositories, but instead managed to convince a different maintainer to boot Jamie off the Lerna team. While he was doing all of this he had the gall to call Babel and Lerna HIS personal projects. He wrote stuff like (paraphrasing) "I will not allow Palantir to use my projects." Multiple other maintainers of these projects had to point out to him that these were, literally, not his projects. At the time that he did this he wasn't even the maintainer or core contributor to Lerna. Long story short I will never support anything this guy does. It is incredibly irresponsible to put him anywhere near the levers of power of any significant project or to give him power over employees in a company.

201 points by sebastianmck 5y ago

The JavaScript tooling ecosystem is fragmented, bloated and slow. Rome is the best - and currently only - bet to fix this. I’m excited!

yewenjie 5y ago
Why do you think this is the only bet? What about things like Snowpack, Vite, and Esbuild?
- cpojer 5y ago
  Those are all great bundlers/dev servers but they aren’t as ambitious as Rome. Rome aims to be the one tool that handles everything: compiling, bundling, testing, linting and everything else.
  - inglor 5y ago
    You can also do that with Deno: - Built in testing library - Lint with `deno lint` - Bundle with `deno bundle` - Format with `deno fmt`
  - thiht 5y ago
    And it will be the one tool that handles everything poorly. Linting (eslint) and testing (jest) are solved problems, there's no way I'll migrate to Rome for these. They should focus on bundling which is the current pain point (although my bet is more on esbuild).
- swyx 5y ago
  bad examples - the better one is Deno.
vijaybritto 5y ago
How will Rome be faster than the other tools when its also written in Typescript? I see that unification will be an advantage but I dont think it will be faster than others. Especially when native code/wasm based tools are already available. (esbuild/swc/rslint) The positives I see are: - No fighting with different versions of different tools when upgrading - Simpler configurations But I dont see any other reasons to convince people to use Rome.

blocked_again 5y ago

> Together, we’re announcing that we’ve raised $4.5 million in seed funding, led by A.Capital Ventures and OSS Capital. VCs fund startups which has the potential to 100x their returns right? How is that going to work here? How will they monetize a javascript library? Will we have an IPO for a javascript library? Or are they betting on a big tech company to acquire a Javascript library for 100s of millions of dollars? I am confused.

ruffrey 5y ago
Healthy skepticism is good. Dev tools are hard. There are hundreds of open source companies - many making gobs of money. Not all - many fail. This team has name recognition and a few successful projects already - Babel and yarn. I can see it working out. JavaScript is one of the most popular programming languages. Millions of developers. With solid execution, there are monstrous markets here.
- throwaway91_82 5y ago
  this team also has had at least one example of unilateral non-open source decisionmaking https://www.vice.com/en/article/pawnwv/open-source-devs-reverse-decision-to-block-ice-contractors-from-using-software https://www.vice.com/en/article/pawnwv/open-source-devs-reve...
  - vosper 5y ago
    Is it a given that because the software is open-source, the decision-making will be, too? Almost seems there should be a separate set of claims for what the decision-making process will be (like how there are various software licenses).
    - ipsum2 5y ago
      From the article: > Eric Raymond, the founder of the Open Source Initiative and one of the authors of the standard-bearing Open Source Definition, said Kyle’s decision violated the fifth clause of the definition, which prohibits discrimination against people or groups.

ruffrey 5y ago

It’s a difficult, painful problem - meaning there’s an opportunity. Sebastian has the grit to deliver. What’s the business model?

sebastianmck 5y ago
Supplemental services that integrate with the tool. Think code quality monitoring, error reporting, and core enhancements like a remote cache. There's a lot we're going to be experimenting with.
- inglor 5y ago
  I'd pay for fast remote builds that integrate into my source control (GitHub and Azure DevOps) and creates production builds fast.

coward76 5y ago

Can someone tell me how this is different than something like webpack?

abc11283 5y ago
This question is answered literally on the front page of their website.

throwaway91_82 5y ago

possibly sensitive question - i recall Sebastian and Kyle had their differences during the ICE issue of 2018 https://www.vice.com/en/article/pawnwv/open-source-devs-reverse-decision-to-block-ice-contractors-from-using-software https://www.vice.com/en/article/pawnwv/open-source-devs-reve... what are Rome's intended policies on OSS licensing and usage by ICE?

abc11283 5y ago
I think there’s a difference between “objectionable organizations” using what is available as OSS, and them being allowed on the platform that the company intends to develop.

abc11283 5y ago

Disclaimer: I know the foundation of Rome was largely written by Sebastian. This question still applies to Rome though, but more so to “open source companies” in general. https://rome.tools/credits/ https://rome.tools/credits/ How many of these people are going to receive an employment opportunity from this company? How many will receive equity? I suppose the same questions can be asked if any big project, like React, though that had FB’s backing from the get-go. I understand that OSS needs funding from somewhere, and I am incredibly optimistic about Rome, but I’d think it a bit disheartening to be surprised by this announcement as a contributor.

swyx 5y ago
thats not how OSS contributions work. you contribute of your own free will, they don't owe you any equity or employment. of course you'd have a leg up on hiring but they don't owe you a thing.
- abc11283 5y ago
  I know how OSS works. I just think the transition from being a community-oriented project, to one that will create a lot of value for a small group of people, will be interesting to watch. They certainly deserve any and all success, I just wonder how those decisions will be made.
deleted 5y ago
[deleted]
sebastianmck 5y ago
I've been keeping the core contributor team updated on the funding process since December. We've also been publicly speaking about it in the Rome Discord server too. I posted about securing funding in early April in #general. Emanuele and Yasser both approached us during this period to offer their interest in joining and have stayed actively involved in development. It's a good question around how to compensate the shoulders of the giants you're standing on, and I don't think anyone has a good answer for that. I think it's important to note that the credits page is meant to be as exhaustive as possible. I am not aware of many other projects that have something similar, and theirs are likely to be even longer. In the end the community is getting value because we'll now be able to do more to improve the project than we otherwise would have. Babel most notably has struggled for funding and is even currently undergoing a serious funding shortage. It has been used as one of the poster children for the JS community and it's clear that donation-based funding isn't effective, at least on the order of magnitude required to support a team.

lacker 5y ago

This is pretty exciting! I'm glad to see more investment going into the JavaScript developer tooling ecosystem. Some of the open source companies have had an easier time monetizing than others. Databases, for example, have a somewhat obvious path nowadays of offering a hosted version. NPM and Docker, on the other hand, developed incredibly popular tools but struggled to monetize. So I'm curious to see what Rome will do. The other interesting question to me is what Rome will focus on. There's a really wide array of things in the JS toolchain and it's tempting to boil the ocean. How much of it can you really boil? Running a nice JS browser stack of course. Supporting TypeScript I presume. How about Node on the backend? An Electron app? All of those in the same codebase? Some tough decisions here but I'm glad the team working on them is set to grow and attack this problem. Good luck Romans ;-)

tsdlts 5y ago

After using esbuild and experiencing fast builds, I'll never go back to tools written in javascript/typescript again.

deleted 5y ago
[deleted]
orta 5y ago
FWIW, sucrase (written in TypeScript) has done a great job of being in the same ordinal of perf as esbuild: https://github.com/alangpierce/sucrase#sucrase https://github.com/alangpierce/sucrase#sucrase
- Touche 5y ago
  That's single threaded perf, so takes away a huge advantage of Go. Also doesn't include startup time (node is slow to start)
  - serverholic 5y ago
    And memory usage.
- lhorie 5y ago
  Sucrase "cheats" though[0]: > Sucrase bypasses most of these steps, and works like this: Tokenize the input source code into a token stream using a trimmed-down fork of the Babel parser. This fork does not produce a full AST, but still produces meaningful token metadata specifically designed for the later transforms. While this is fine for simple transformations like transpiling JSX, it's not very suitable for full-on AST analysis like some eslint plugins do. Most notoriously, Sucrase is specifically designed to be garbage-in-garbage-out, whereas Babel will throw proper errors on things like early errors. Tools written in lower level languages like esbuild can take advantage of facilities that aren't well supported in Node, such as cheap concurrent coroutines and greater control over memory layout (Babel ASTs are notoriously megamorphic and can silently fall off perf cliffs depending on how you manipulate them). These caveats are not reflected in Sucrase's benchmark. [0] https://github.com/alangpierce/sucrase#motivation https://github.com/alangpierce/sucrase#motivation

deleted 5y ago

[deleted]

capableweb 5y ago

Where is the company incorporated? In most countries, companies act for profits first. Especially if you raise funding from a few selected ones instead of the wider community. This statement reads weird too > We don’t believe in placing artificial constraints on the tool or having functionality behind a paywall. In order to support the open source project, we’ll be building supplemental products and services. This aligns our incentives with the community and our open source users, with a focus on interoperability, performance, and usability. Supplemental products and services on top of open source projects often require (down the line) the open source project to adapt because it might hurt the bottom line of these supplemental products and services. Since there is no guarantee this won't happen, if the stake is between the company surviving or a feature being open-source vs "supplemental", the people working at the company might have to chose the option against the wishes of their open source users. I don't see how creating a for-profit company is at all in alignment with open source users. Better would have been a Co-op, a non-profit, OpenCollective, or leverage an existing entity like the Linux foundation, that can actually guarantee it for you in contracts and laws.

leodriesch 5y ago
Sebastian actually tried fundraising, but I think the campaign got stuck at about 36k of the 100k goal. https://rome.tools/funding/ https://rome.tools/funding/ VC money is just on another level, although as you said it comes with its own difficulties.

anaclet0 5y ago

I thought Rome was a Facebook internal project. Am I missing something here?

jillesvangurp 5y ago
It's also a java framework for parsing RSS and Atom. I bet that there are more ways that lead to Rome :-)
- SahAssar 5y ago
  This is that facebook project though (not just the same name), see here: https://github.com/rome/tools/blob/main/website/src/blog/posts/2020-08-08_introducing_rome.md https://github.com/rome/tools/blob/main/website/src/blog/pos... Seems like the author could take it with him when leaving facebook, which is nice.
- yuchi 5y ago
  Parent comment was talking about this specific Rome project. And he is indeed right, it was a Facebook project at the earliest stage, but moved out of it when Seb left FB.

pier25 5y ago

Any news on plugin support (eg: Svelte)?

FractalHQ 5y ago
This was my first thought as well. More and more devs are beginning to discover Svelte as a milestone in the evolution of Javascript. I would be surprised if it wasn’t already on the roadmap.
- swyx 5y ago
  second vote for Svelte support here - i'd hate for a next-gen tool like Rome to only support React when there are other great frameworks that it could handle

jillesvangurp 5y ago

I had a quick look at how they are set up and I like what they are doing from the point of view of actually creating an OSS community. I don't actually know much about what they do as I'm not one of their users. Judging this purely from a "does this make sense as an OSS company" point of view. - License: MIT. Great pragmatic choice. Generally a good fit for not obstructing your users to actually use, copying, modifying, etc. your code. Too many OSS startups play games with this and end up going for something too restrictive. IMHO not having copyright transfers is the key to longevity for any OSS community. It basically progressively removes re-licensing as an option as more contributors would have to agree to such a thing. Most long lived oss projects have long lists of contributors and no history of license changes past an early stage of their development. Also, MIT is very compatible with just about anything in the ecosystem. Given their stated goal of being good OSS citizens, that's a hard requirement. - Contributing.md: no mention of copyright transfers. Also they have close to twenty contributors. I assume this means the license will stay as it is and there are no plans to change that. Great! This is key to building a successful open source community with people actually contributing as well as using the code. It also ensures the code can survive acquisitions, bankruptcies, mismanagement of the company, etc. Committing to this upfront is important and a big step. - Community: There are seventeen contributors, most of which are not employees (I assume). And they probably integrate a lot of other libraries/tools. - Explicit stated goal that affirms the above: "The company exists to support the open source project, not the other way around.". That does raise a few question marks around valuation and ways to profit from this. I'm curious about their plans for adding value in the form of services on top of this. I assume this means some cloud based services and/or support contracts with consultancy. But then, it's good to remove the nuclear option (relicensing) from the table early on to create clarity for developers and investors that this is just not that sort of company. It's smart from a business point of view as well because most of what they do will come from outside the company anyway. The nature of the javascript community is people rapidly iterating on tools, libraries, etc. and forking left right and center as needed. So, a lot of value is going to be added through people doing exactly that. You can work with them or against them. With them is the smarter option.

greshario 5y ago
> License: MIT. Virtually all open source projects in the web dev community are MIT licensed, especially when it comes tooling. Choosing any other license would cause a lot of friction and prevent adoption.

devit 5y ago

Being written in TypeScript and not Rust seems quite a big liability that might see Rome never be popular or lose out quickly due to inferior performance. There is already RSLint and SWC as JavaScript tools written in Rust and I would expect such tools to take over, with a good choice of it happening before Rome is ready.

valyagolev 5y ago
no, much worse. they might actually win by overspending on marketing and feature-bloat, and we’ll be stuck working with slow tools
- intergalplan 5y ago
  Yeah, I'm over here going, "oof, I hope they don't do too well by burning VC cash, or they might stifle esbuild and deno and similar efforts, and we'll remain stuck at this embarrassingly-low local maximum even longer"
  - valyagolev 5y ago
    what else would VC money be for other than a sweet vendor lock-in?
jeroenhd 5y ago
I don't see the relevancy of rust here, but you're right that at this point any language that compiles directly to machine code will blow any javascript tool out of the water any time. Of course, perf is only one reason to use a tool, I expect javascript based tooling to stick around for much longer because developers are used to them now. And, of course, if all you know is frontend, everything starts to look like a javascript job.
- serverholic 5y ago
  I'd prefer my tools to use languages that are compiled + memory safe. Basically that just leaves rust or go. But rust also has other features that can help prevent bugs regarding concurrency and more. So rust is a feature in my book and not just an implementation detail.

SamBam 5y ago

This feels like a new version of Brunch. Did anyone use Brunch to build and bundle JS projects and manage dependencies? It seemed like the best thing since slice-bread at the time. I recently had to go back and update a 6-year-old project that had been written using Brunch. It took several days of painful work to extract it all out of the framework and built it using Babel. All I'd want to know with Rome is, if and when I abandon it or it gets abandoned (whichever happens first), how annoyed am I going to be that I had chosen this framework? How seamless will it be to extract my project?

gremlinsinc 5y ago

Rome sounds awesome but the branding confused me for a second... I was trying to find out how this relates to https://roamresearch.com/ https://roamresearch.com/ I guess phonetically my mind was flipping things around.

redisman 5y ago

https://xkcd.com/927/ https://xkcd.com/927/

betterfaster 5y ago

I think the future of JavaScript tooling is esbuild and SWC, written in fast compiled languages like Go and Rust. I don't see the value proposition in a brand new toolchain written in slow and memory hungry TypeScript/JavaScript.

pictur 5y ago
you are right but the most common tools are still made with these. I think people don't worry about performance that much. or worry, but they don't make an effort to change that.
- vijaybritto 5y ago
  You're correct on this to some extent. Teams in our company are so fed up with webpack for local development that they are willing to skip some features it provides to use vitejs.dev for local dev. We fully couldnt avoid webpack 5 because Module federation is very very valuable.

proxyon 5y ago

I'm a senior eng in Typescript at a tech company. I will always advocate against adopting this project. Jamie is a perfect example of the toxic attitudes and activism destroying OSS and tech. Lerna or Babel are fine, but then again, they are purely OSS projects, not companies expressly designed to enrich him and reward his toxic activism.

PleaseIgnacio 5y ago
What kind of activism are you referring to?
- proxyon 5y ago
  He's well known for almost torpedoing Lerna by committing an insane proprietary license where he called ICE and Palantir fascists who aren't allowed to use Lerna, and included into that any companies who ever do work for ICE or Palantir, which included Microsoft. Microsoft in response had to get to work dropping Lerna from all of its repositories, but instead managed to convince a different maintainer to boot Jamie off the Lerna team. While he was doing all of this he had the gall to call Babel and Lerna HIS personal projects. He wrote stuff like (paraphrasing) "I will not allow Palantir to use my projects." Multiple other maintainers of these projects had to point out to him that these were, literally, not his projects. At the time that he did this he wasn't even the maintainer or core contributor to Lerna. Long story short I will never support anything this guy does. It is incredibly irresponsible to put him anywhere near the levers of power of any significant project or to give him power over employees in a company.