JetBrains Noria | Hacker News Reader

JetBrains Noria

blog.jetbrains.com

163 pointsAbuAssar59 comments

> Fleet relies on the Java AWT/Swing framework to get a window from an operating system, but it doesn’t use the Java platform for managing its GUI components besides one JFrame and JPanel on top of it.

This is a terrible decision that is going to bite them in the long run. Doing things this way makes it far, far more difficult to implement accessibility, and regulations on this are only going to get stricter.

Implementing accessibility for a framework like that would involve three separate implementations for three separate platforms and the need to interface with D-Bus, COM and Objective C, from Java. I imagine that the latter two would be particularly difficult, considering how bad Java's FFI support is. It's not just calling methods either, you'd actually need to implement your own classes that conform to the relevant COM interfaces / Objective C protocols. There are libraries that can help with this[1], but I don't think they would work particularly well for something as complex as a code editor.

[1] https://github.com/AccessKit/accesskit

It's worth noting that Compose Multiplatform, which makes the same core decision, actually has a pretty solid accessibility story (https://github.com/JetBrains/compose-multiplatform/blob/mast...). It'd be nice if I didn't need the Java Access Bridge, but that doesn't seem like a major break for me.

Swing is notorious for not relying on underlying graphical system controls and drawing everything from scratch, and they are actually reinventing Swing on top of Swing.

IDEA actually ships its own Swing implementation for decades because the default one from Sun/Oracle is intolerably ugly-looking.

> This is a terrible decision

At first I thought you were objecting to the other part of the quoted sentence and saying that relying on AWT/Swing at all, even for creating windows, is a terrible decision.

These libraries are not good at handling windows. Sometimes windows can be seen being created in the wrong place and then moved afterwards, after being displayed. Sometimes focus is somehow moved to the wrong window when switching quickly between windows. And as far as I can tell there is no way to set a maximum size for a window, even though the underlying platform supports it.

Since Fleet has to bundle native libraries anyway, maybe it would be better to reimplement that part as well. That would also (in addition to being less broken) allow removing the whole java.desktop module from the bundled JRE, saving lots of space.

Fleet has been a multi-year effort, gotta applaud JetBrains for willingly take the bet and continuously investing in developing its products. It's way easier to rest on their laurels and only provide maintenance updates to IntelliJ.

I wish they provide only maintenance updates. I hate all their updates for I think 5 years or something like that. The only reason that I update is because I need new Java support. Their updates bring nothing but issues to me. This year I just migrated to vscode for everything but Java projects. Unfortunately vscode Java support is atrocious, so Idea is not replaceable at the moment.

I find myself agreeing with this sentiment lately, as a WebStorm user of many years. Little bugs and annoyances stay in the product, while every new feature has been unimportant for me — anecdotal, I know.

I particularly disliked Fleet. It resembles VsCode in looks, and that’s a very bad thing for me. No sense of hierarchy, of what matters, of what tools I actually want to see and where they should be.

But then I’d say the same for Apple and its software.

I don't mind fleet, even though I don't get on with vscode.

Yeah, they keep breaking stuff and causing UI bugs. I know I can stay on an old version, but I don't want that either, because I do want things fixed eventually...

Agreed. I'm using Idea for Scala development, but Scala support seems to get worse every year. The new features that each update brings I don't need, all that happens is that Idea gets more and more bloated.

If they rest vscode will take their lunch (if not already so to some extent). I applaud their Fleet effort but it’s definitely a reaction to vscode, rather than going the hard way willingly

I wonder if they're going to give a free version of fleet in order to counter vscode. Although right now is free due to being public preview

I use both, though I still prefer JetBrains IDE for coding.

May I ask, coding as opposed to what?

The other stuff I do is to write YAML, HCL, and other type of configuration files.

I've been giving Fleet a try every now and then and am looking forward to it becoming a full-featured stable product.

At the moment there is no extension/module system so it's not really a replacement for the million little jobs I have vscode open for, but I'm a Jetbrains Full Product license holder and use their main IDEs so I will definitely be happy to replace vscode with Fleet when the time comes.

What are you using VSCode for that the stable JetBrains IDEs don't do well?

I use JetBrains products as my main IDEs, but then fire up VSCode for smaller editing tasks on things like Ansible Playbooks and Terraform scripts, as there are official plugins for VSCode that are so much better than anything I've found on the Jetbrains marketplace.

It's good to enter a directory, type 'code .' and do some quick editing without the Jetbrains process of creating a project around the directory.

And I've grown to like the VSCode terminal, with side markers to help scrolling back to the start of a run and any errors.

Having said that, there are all sorts of things I miss from Idea or Webstorm when using VSCode, like great integrated Git and local history support. You can kinda sorta get close with a collection of VSCode extensions, but it doesn't feel as cohesive or polished to me. And that diff viewer is very Visual Studio, whereas the Idea one seem much more polished to me, like Perforce.

Maybe it's just what you're used to, and I've spent a lot of time in Idea and Webstorm. So for a large codebase, I'd definitely be inclined towards Jetbrains. As others have mentioned, the code discovery, navigation, and refactoring facilities are second to none. Not surprising as it's been continually developed as an IDE (rather than an editor) since 2001.

> as there are official plugins for VSCode that are so much better than anything I've found on the Jetbrains marketplace

It's a damn travesty what JetBrains has done to the CloudFormation plugin and by close-sourcing the terraform plugin then basically abandoning it. I'm aware there is a commercial ansible plugin but my experience with it is that it's not worth the money to me when, as you pointed out, the vscode language server for ansible does a fine job for the yaml, but sadly does nothing for the jinja2 snippets therein

IntelliJ IDEA does have LightEdit mode to handle this use case: https://www.jetbrains.com/help/idea/lightedit-mode.html

Thanks for the link... I checked out LightEdit, but it sounds like it leaves quite a lot behind :

"..and it doesn't support the usual IDE editor features such as code completion, or code navigation."

I remembered it's possible to use the Jetbrains Toolbox tool in order to generate shellscripts for command line startup. So 'ws .' when generated will do the same thing for WebStorm as 'code .'

They don't do containerized development well. VS Code + docker for development "just works", as of 2023 there is still no similar workflow in PyCharm. You have to start the container and treat it like an SSH target.

Alternatively, why would I want to use Jetbrains over VSCode?

Depends on the language you use really.

CLion is the best cross platform C++ and Rust IDE there is imho. Everything from target management, to debugging integration and integration with CMake (no having to go back and forth with generated projects) is so head and shoulders above alternatives.

Rider is similarly so well tuned to game development needs. There’s tons of quality of life features in the IDE for Unity and Unreal developers.

PyCharm Pro has great multi language support within a single file which is great for web frameworks, and an integrated database inspector too.

But I’d go back to the : “why would I want to use X over Y?”

I use both. VS Code for small projects and quick edits. Jetbrains for larger projects where I need the better tooling like inspection and refactoring. They’re complementary.

That said, I don’t think I’d be anywhere near as efficient a dev if I didn’t have my Jetbrains stuff on hand. I could replace VS Code with any number of smart text editors like sublime or fleet instead.

I used CLion for the longest time but it's just so sticky and slow. VSCode with the clangd plugin is blazing fast.

I don't think the Rust story is that simple. They've got the best Rust debugger, but I'm skeptical about their decision to build their own intellisense. Everyone else is using rust-analyzer, and r-a is getting better and better. Intellij Rust started off quite solid, but it's fallen behind in innovation.

Things like proper analysis of code in branches of the select macro matter a lot to me.

A serious alternative is neovim together with lsp plugins. You can set up a preconfigured neovim such as lunarvim and after learning a few shortcuts you are 90% the way what Clion offers. It isn't totally easy to get into it but at least for coding it is very productive. Debugging is another story I haven't really touched until now.

> I use both.

I mostly don't get the all chips in a single IDE people. None of them are perfect for everything. Be glad there are options and use what works best for you for the task at hand!

Like with everything, you can either learn a bunch of tools on the surface or only a few of them deeply. And there's quite a lot of depth to the JetBrains tools.

I use mostly CLion, PyCharm and Android Studio from JetBrains. I get what you mean, but about depth and getting really good with a single tool, most of time I have more success in this with command line tools, as their interface almost never changes, the knowledge can pile up in little steps.

With graphical UIs (hi Xcode) I mostly don't see big benefits of getting that much of depth as productivity gains can be swiped off by software updates - or alternatively, by switching projects with different technologies.

Well, there's basically no alternative (CLI or otherwise) for the Java tooling with the quality Intellij provides ...

If you are happy with VSCode you probably aren't doing the things Jetbrains IDEs excel at.

That said: Language support - specifically Java and Kotlin are absolutely top tier. CLion is easily the best Rust IDE also. Automated refactorings. Really really fast code search - caveat, indexing takes a while but it's worth it.

My own anecdotal experience.

- VSCode plugins don't seem to work as well or feel as cohesive for the languages I typically use, Go, Python, Typescript.

- Jetbrains debugging is much better

- I like the look of Jetbrains IDEs much better

- One IDE custom fit to each language

- Great git integration

I pop in to VSCode from time to time and I always seem to return.

I've been developing a large Angular application and I got fed up with the flakiness of the Angular plugin in VSC. Sometimes jump to definition works, sometimes it doesn't. Sometimes error indicators are correct, sometimes they aren't.

With webstorm I don't have these problems. People will mock the indexing shenanigans of jetbrains IDEs but they get results. WebStorm can reliably refactor where I get anxious in VSC because it often misses some template references and webstorm's symbol search is reliable and fast.

It's a MUCH better debugger: https://www.youtube.com/watch?v=OBgLeRwjlAc

I really want to use Fleet but its vim emulator development is so behind it’s barely usable. (No go-to definition mapping for example)

Come on Jetbrains, you’re targeting the developer market, get this right!

"Interestingly, Noria is not a UI framework at its core. Instead, it’s a platform for incremental computations. Imagine a large multi-part mathematical formula with interdependent components that sometimes have to be recalculated or trigger the recalculation of dependent components – not unlike a spreadsheet."

I wonder if they took cues from Jane Street's Incremental (https://opensource.janestreet.com/incremental/) which they built specifically to address this very issue in UIs that needed to be very performant.

Fleet is a good idea, but it’s DOA for me unless they can fix the performance. It somehow managed to run worse than VS Code on the multiple occasions I tried it. The word “performance” isn’t mentioned once in the entire arricle.

I’m eager to find a good Sublime Text competitor, so I’ll be rooting for them, but so far this project has been disappointing.

Generally speaking, when writing code you should:

1. Make it work,

2. Make it right, and

3. Make it fast

In that order. I have to assume JetBrains is quite a ways away from any significant performance optimizations on this project.

Is it surprising that a Jetbrains product is slower than VS Code? For relatively small projects, my VS Code with over a dozen extensions seems to run leaps and bounds faster than Pycharm/Clion.

This was the case for rider as well. By the time it released it was plenty performant.

I’m not concerned about that yet.

Nice article! Good to have an alternative in the editing world.

I tried to use Fleet. I applied when it was still on private beta. Only those invited could test it. I found it snappy and really liked it. But the dealbreaker was that it couldn't replace Sublime Text for me 'cos it does not allow for plugins then (don't know about now). I do not need a bazilion plugins on my text editor but I must have vim keybinding if it's gonna be a daily driver.

It did not have it... so ¯\_(ツ)_/¯

I check in every release to see if their vim plugin has progressed enough that I can actually use it, but unfortunately they still don't seem to have visual mode implemented yet

Tell me about it, it’s almost as if there’s no development on it. Or it feels like maybe there’s one person working on it part-time

It feels more than a little bit coincidental to call it Noria when https://github.com/mit-pdos/noria exists (and has been posted about here on HN)... especially with the whole bit about incrementally computing changes.

At this point, it doesn't matter anymore. Any sane name is already used multiple times for any kind of project or product. Unless you have the exact same domain of functionality, go, use whatever name you want.

That's... entirely a different project, not sure what bow you're drawing, but it's a long one.

You do realise that this project has had broken build since 2021?

It’s really interesting to see so many UI frameworks shift from the old small talk style paradigms to reactive forms

Noria reminds me greatly of SwiftUI in paradigms and I think it’s a really great direction for UIs to take this hybrid approach

Reading the article, it seems like they made React for Desktop (mobile coming soon). I wonder how the approach differs from React Native?

I skimmed it but didn’t see, do they say why they didn’t use Compose for Desktop? Seems strange not to use the UI library being developed at the same company.

From the article: "When we started working on Fleet, however, Jetpack Compose didn’t exist, and thus Noria was born."

On the one hand, it seems like a significant waste of resources to duplicate efforts between the two projects. On the other, I wonder if Noria has any desktop-centric advantages over the mobile-oriented legacy of Compose.

It doesn't at a base; both render via Skia and have completely bespoke widget systems, not tied to AWT/Swing or the native platform. They could implement the Fleet widget system on top of Compose if they wanted to invest in the effort.

Personally, having worked with multiplatform Compose, I very much appreciate it over the plain "widget objects with callbacks" approach.

They're reasoning is Compose wasn't available, surely then the next logical step was to either work on Compose or eventually port to Compose? Not, "ah well let's just have two competing frameworks".

As a customer, I'm really excited for Jetbrains to take on experimental research projects. I love their IDEs, but they definitely have that old crusty feel, like old enterprise Windows apps and not in a good way (slow and ugly).

Yeah in the short term it's not great to have two similar homegrown frameworks. In the long term though maybe it gives their apps more options to choose from, or at least different pros and cons they can try to merge together later. Either way, it's a great step forward than having to rely on Java or Oracle directly.

Of course the web dev in me wishes they built a similar stack from Typescript instead (to compete with Electron and React Native) but I don't blame them for not doing that.

because Compose for Desktop wasn't available yet when they started fleet development

> Why invent a new UI framework when we have so many brilliant UI frameworks out there begging to be applied for creating highly responsive GUI applications with a modern look and feel for all major desktop platforms at once?

There is probably some xkcd cartoon that says no, you can't have such a GUI. Human compute is not meant to be a pleasure.

It's funny that the author introduces React as a framework that's notable because it brought a few paradigms mainstream, then immediately re-introduces the equivalent of virtual dom diffing without a tip of the hat.

Excited to see what they come up with here though, love Jetbrains products and Kotlin is a solid JVM language

This was a fantastic article. Thank you!

Reply on news.ycombinator.com