I was kinda expecting someone to showcase JavaFx/TornadoFx, after the daily parade of electron/JS based apps.
> it is significantly lighter on resources and more responsive than the Electron-based options
I tend to agree that this is lightweight than Electron etc, but are there any benchmarks to verify the actual numbers?
One the side note, it's funny so see Java being touted as a `lightweight` alternative to desktop apps. Desktop technology has come a full circle.
And another yes, Java is not the lightest thing around. But man its much better than Electron.
Maybe I'm a spoilt C++ programmer, but 250-300 MB is still bit higher for my tastes. For me the golden standard of cross-platform desktop app is Sublime Text which usually hovers around 100-150 MB for me.
However I'm sure the memory usage, and performance can be drastically improved given the fact that JVM is one of the most heavily optimised pieces of software in recent times.
Edit: I just tried it, and it doesn't work for some of the methods for httpbin. Would be great if you could test the app against https://httpbin.org
I sometimes wish I'd done this with C++, but it would be very tedious. I was quite proficient in JavaFX so I reckoned it will be the best tool for the job.
About httpbin: Could you please elaborate on that? Which method failed?
I tried `https://httpbin.org/deflate`, `https://httpbin.org/status/418`, and `https://httpbin.org/brotli`, and they all failed on me. It would be cool if you could use httpbin as a test suite.
Exactly my thought when I read this. Google really outbloated Java with Electron.
A technology finally came up to make a Java desktop app look better in comparison...
Many Java applications got bad reputation because no one bothered to learn how to use Swing properly and were doing everything on the UI thread.
On this I agree completely! (altough my experience with that is mostly on the server side)
Or rather, if people have no other options, they'll use whatever they are given.
Besides, it's not very serious if user adoption is the criterion -- as opposed to the possibility of a better computing environment.
yep my reading comprehension is not on point today
The JVM does have a slightly higher warm-up time than something like Node.js.
The slow scrolling is a JavaFX thing and bothers me too. I'll definitely polish that up, if possible.
I don't have a Mac at hand so I didn't do any Mac-specific stuff in Everest. I'll add the usual Mac ones in the coming weeks.
First of all, I want to thank all of you for trying out Everest and providing such great feedback. The project really blew in popularity since yesterday. I was not expecting a response anything close to this (Everest is #2 on GitHub's Trending Java repositories).
I'm really happy that most of the responses have been positive with some constructive complaints. I'll make sure they're addressed in the coming alpha builds.
Regarding performance: Yes, JavaFX is not the lightest thing on the block but its much much lighter than Electron-based options. I know the memory usage for Alpha v1 is not too great (not bad either) and it will improve as we go ahead. I haven't made any JVM/GC tweaks yet. I'm currently working to optimize the internals and that has improved performance quite a bit.
I have my finals coming up in a week so the development is gonna be stalled for a while. But its gonna be fun. We'll build a kickass application together.
PS: HN keeps throttling my account since I'm a newbie around here so if you want to reach out to me, I recommend you do so via Twitter or email, both of which are available in Everest's README.
You can reach out to the mods via the Contact link in the footer. They can remove the new-account throttling on a case-by-case basis.
> Unlike other REST clients like Postman and Insomnia, Everest is written in Java. Thus, it is significantly lighter on resources and more responsive than the Electron-based options.
I love Java, but I had to laugh a little.
And last I looked it (like ScalaFX) runs against Java 8, so no Jigsaw to shrink app sizes.
User convenience >>> Developer convenience
I'm not a fan of Java so I'm really excited that with Kotlin (& TornadoFx), this can actually be a very pleasant environment to program in.
Also, ScalaFX doesn't seem to be under active development, which is quite a shame tbh.
That said, I've fairly recently decided that Jupyter notebooks are a better mousetrap than GUI-based tools for this kind of thing. Python's a pretty ergonomic language for this kind of thing, and having a full programming language to work with makes some testing scenarios more convenient.
Plus, you can get some nice spinoffs out of the deal. Once you get everything how you like it, you might be only an nbconvert away from having a decent suite of automated acceptance tests. Or sprinkle some markdown cells in between your tests, and now you've got executable, hackable documentation for your API. Check that into GitHub, and you've also got reasonably pretty documentation with detailed code samples that's easy to view in the repository browser.
On my system, Everest is using a lot more memory than Insomnia. Perhaps an unfair comparison as Everest is an alpha, whereas Insomnia is very polished. But I see nothing to support the claim.
I feel like to announce it as leightweight you should at least include memory/latency benchmarks.