Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I started as a Jest core contributor before joining Meta. It's arguably the reason I work there now, and I'm really excited for the move.

Meta created Jest and a lot of the features that it's known for, but it's true that it hasn't been invested in for a few years and most of the recent features were created by the community.

With this move, Meta is showing their commitment to Open Source and Jest will be able to grow with ownership through the OpenJS Foundation led by the Jest core team and the Jest community.



Thanks for putting in the time to make this work from Meta's side! Us folks on the outside appreciate it a bunch


Reads kind of like an obituary.


It reminds me of projects being moved to the Apache foundation, that too often felt like an obituary of sorts. I'm sure there's good stewardship of those projects at Apache, but nothing exciting to come out of it.

And it's a shame. I wish there were more of these big companies that would just, idk, pay an organization like Apache or in this case OpenJS so that they can operate as a software development and open source stewardship company, pay people to work and manage these projects.


It's not about money. Foundation stewards without any attachment to the project are like political appointments; no skin in the game. Money doesn't push a projects requirements and demand it continues to evolve, diverse users do.

Sending it off to the Apache foundation in this state to me sends a signal that it's good enough, innovation is no longer required, and therefore is not worth the investment to continue to maintain.


It's going to take a while to impact the current ecosystem but NodeJS is implementing testing natively and that will inevitably erode the popularity of jest/mocha/etc -

https://nodejs.org/api/test.html


It will have some impact, but that erosion will be limited by how readily portable it is (I’d assume very, but haven’t looked at the source) and how attractive a target it’ll be for abstractions.

The former is table stakes if it has any chance of displacing test frameworks which are already widely used for both server and client code. I would be shocked if it’s an issue though, there’s very little to gain from coupling a test framework to Node specifics (its own non-test APIs, V8 bindings, NAPI, etc) unless you’re heavily invested in that focus. (I say this as someone who’s worked on such a project off and on for a while, and even then the primary motivation is to make testing itself more portable without sacrificing performance or tooling.)

The latter—attractiveness as a low level API to build on—remains to be seen. This is something Node generally does well with its novel APIs. But it’s a very crowded space already. And from what I’ve seen looking at the APIs, they don’t offer a whole lot more than basic correctness that can be skipped to quickly prototype and iterate abstraction ideas.

Otherwise it’ll be a reasonable default for very Node-specific greenfield projects. Which is welcome! But it’s also a somewhat niche audience. Portability is going to matter to almost all Node users already, and abstraction will matter to a largely overlapping segment of users who are accustomed to a much richer set of built in and extensible testing semantics.

I don’t want to dismiss the effort or its prospects outright! I just think it’s become increasingly clear that Node’s influence relative to the JS ecosystem is shrinking as the diversity of runtimes increases and as compatibility between them becomes more important.


Is Meta moving away from Jest or is it still used internally?


Yeah, Meta will continue to use Jest internally. It still works really well for us, it's just "feature complete" for our use cases so we haven't needed to invest in it.


>Yeah, Meta will continue to use Jest internally. It still works really well for us, it's just "feature complete" for our use cases so we haven't needed to invest in it.

What's the status of Rome? Is that being looked at as a long term replacement?


Rome is a completely separate project that Meta no longer owns. You can check https://rome.tools/ for the project status.


I'm a mixed of confused and optimistic about this project.

On one hand, I would absolutely hate for someone to force me to use one tools, opinions for everything I do in a project.

On the other hand, if I just start a new job and I need to get producing, I'd rather have one big tool that just makes JavaScript work. Versus 4 different tools with a bunch of different limitations.


I have full confidence that the people working on it can deliver an incredible product. I have severe doubts that this will be sustainable as a business though, which really sucks


Wouldn't it make more sense to create the business model first ?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: