Congrats, Emil and team! I'm most excited for this as an extensible platform for further desktop tools, built on FB's robust stack of front-end tech.
Although I must admit, I'm disappointed that they didn't use react-native-web to build this app in a cross-platform way. I agree Electron is a good choice for the current landscape, but I'm hopeful that we will be able to move past it. If Sonar was implemented with React Native's layout API, it would be easily portable to projects like react-native-macos, React Native on Windows, or projects like Proton Native, once it matures and stabilizes.
Of course Emil knows this, because he is one of the primary maintainers of Yoga, the cross-platform flexbox implementation in React Native. This is one of the primary technologies that will allow us to move away from Electron one day, if people would just stop using CSS!
Like I get that people don't like Electron because of it's resource heavy nature but it's been a boon to us Linux users who have finally been getting a lot of cross platform apps and I truly appreciate that.
getting a Mac is generally not an option - it's too expensive just for a few GUI apps (and overall pushes the bar of development quiet a bit higher) and in all honesty, it's not great for the developer ecosystem to stick to one platform either (new Macbook with the touch-bar is a good reminder of that).
I am currently fortunate enough to own and work on OS X, but I do remember when I was in university with a Lenovo T420 running Ubuntu 12.04 having issues with quite a lot of tools when I was just getting started.
Agreed that Electron has been a great boon to Linux users. There is no need to loose that.
If the app was built with RNs layout API, you could continue supporting Electron via React Native Web. But there are awesome upcoming projects like Proton Native that support Linux UI properly on top of libUI.
There was a react-native-ubuntu experiment that unfortunately died down because it forked RN, rather than the Windows approach of using real RN releases.
Glad to hear the tool works well for FB employee's. As always the contribution to the community is much appreciated. But as others have pointed out, the tool name could use a rebranding. The popular SonarCube is just one example where confusion can arise.
Thanks for bringing the naming up. I wasn't aware of these other tools. SonarQube looks interesting, though! Just to clarify, I don't contribute to Sonar development, I'm just a heavy user. I think the team is aware of your concerns now though (Emil is the OP and works on Sonar development).
Facebook has been using it internally for a long time. It would make no sense for them to rename the tool for open-source release just because a naming conflict exists, unless you'd prefer they just not release it at all?
We typically do rename before open sourcing and intend to avoid namespace collisions. E.g. Litho was not the original name of that framework either.
I am familiar with most of the other tools mentioned here (e.g. SonarJava) from my time doing Java development outside of Facebook and never had a collision in my head because this project is not actually a library or tool for Java. It's a standalone Electron app that works on iOS and Android for debugging purposes, the only Java part is incidental in the Android app (and could be Kotlin or C++ or whatever you want).
That's a bad example. Gerrit is not a new name for Reitveld, it's a totally new implementation (with similar inspiration). And both of those were publicly released under those names.
It can and has been done multiple times in the past - AsyncDisplayKit -> Texture is the one that immediately comes to mind as it happened after open-sourcing.
I'm not actually interesting in debugging mobile apps, so it would have been nice if that was mentioned at the start. Now I had to wait for the third section, not very helpfully titled "An open source architecture", to find any clues.
> With Sonar, engineers have a highly flexible, intuitive way to inspect and understand the structure and behavior of their iOS and Android application
...and the top of the post is tagged as "Mobile", "iOS", and "Android".
I think he meant appending "for mobile apps" in the title instead of burying key constraint in midst of wordy paragraphs. There is quite a distance between clarity and fine prints.
I agree unique naming is one of the fundamental pillars of modern coding , or else we would have chaos with stupid generic completely unrelated names like
To be fair, most of those pre-date an era where the name collision would be a known significant problem. I remember when Starcraft was released and being frustrated that the young web at the time only gave me info on camping trailers, but even that is much later than half your examples.
Also, many of those you name collide with words that have no particular collision within the industry, so while you and I might think "Swift" is a non-ideal choice, it's not the same as the problem people are speaking of here.
JavaScript gets a pass because it was intentional. Not wise, as recruiting emails point out to me painfully regularly, but nonetheless intentional.
Go is the major and blink-tag-in-neon exception. I have no idea how naming something that is not only one of the english words with the most definitions but ALSO a game that has a higher-than-average overlap with people in the industry AND one that has been a significant target of the industry survived. I can only assume that someone underestimated the concern or I'm overestimating the actual pain.
Nowadays, however, there's no reason to repeat the Firebird debacle and fail to do a simple web search within your industry. Particularly if you're with a large company. Doing so earlier in your process is better, but even a last-minute name change can avoid generating a lot of ill will and confusion.
Those are arguably some of the best examples of software naming and branding done right, with the notable exception of JavaScript, which isn't unique or accurate. Sonar would arguably make a bad name for anything that isn't underwater SOund Navigation And Ranging.
I will have to try it, I've been a user of Stetho for a long time and the new network inspection tools from Android studio doesn't completely click for me.
The attached video only supports mono audio in the left channel. Evidently no one involved in this release process listened to the video with headphones. Stuff like this is always humbling to me, that you can have a big release with dozens of people involved yet mess up something simple.
This tool looks promising, but it doesn't provides some functionalities that Stetho has, like SQLite and Shared Preferences inspection. Also it is only officially released for MacOS, which is a big con imho.
I rarely comment on name ambiguity because there is rarely overlap, but this does overlap a bit with the Sonar CI analysis tool IMO. Reading this post, I can create a Sonar plugin with Java? OK, let me Google "Sonar Java plugin"...
This is so confusing. My immediate reactions were a) but Sonar is already open-source! b) did Facebook somehow acquire Sonar? c) oh, they're actually polluting the name space.
Hey People from SonarSource: https://www.sonarsource.com/company/history/
please file a lawsuit against Facebook. It looks like it is necessary to prevent them to use these confusing names.
Didn't they rename to SonarQube though? All of SonarSource's products are named Sonar.*, which is unfortunate but in theory there should be no collisions on a Google search.
Although I must admit, I'm disappointed that they didn't use react-native-web to build this app in a cross-platform way. I agree Electron is a good choice for the current landscape, but I'm hopeful that we will be able to move past it. If Sonar was implemented with React Native's layout API, it would be easily portable to projects like react-native-macos, React Native on Windows, or projects like Proton Native, once it matures and stabilizes.
Of course Emil knows this, because he is one of the primary maintainers of Yoga, the cross-platform flexbox implementation in React Native. This is one of the primary technologies that will allow us to move away from Electron one day, if people would just stop using CSS!