Everest: A lightweight REST API client written in JavaFX(github.com)
github.com
Everest: A lightweight REST API client written in JavaFX
https://github.com/RohitAwate/Everest
58 comments
Yes it is lighter than the Electron-based options. Definitely a lot more than Postman which always consumes north of half a gig. Everest hovers around 250-300MB which I know is still a lot and I'm currently in the process of optimizing the internals.
And another yes, Java is not the lightest thing around. But man its much better than Electron.
And another yes, Java is not the lightest thing around. But man its much better than Electron.
> Everest hovers around 250-300MB
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
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 understand that 250-300MB is still a bit heavy, I'm not too happy with it either, but I've come to realize that even a Hello World JavaFX application with just a button on screen eats 70MB. I'm trying my level best to keep this at 200MB but I can't make any promises.
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 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?
Don't get me wrong, 250-300 MB is perfectly fine. As long as it doesn't grow exponentially and take over the system like Electron apps do, people would love to use this. I think you've got a solid product at hand and you should try to grow this commercially.
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.
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.
Unscientific, but for me Everest started a few seconds faster than Postman and used about half as much RAM. I tried to clear out preexisting state from Postman but probably didn't get 100% of it. If you already have a JVM installed, the executable is also 90% smaller
> it's funny so see Java being touted as a `lightweight` alternative to desktop apps.
Exactly my thought when I read this. Google really outbloated Java with Electron.
Exactly my thought when I read this. Google really outbloated Java with Electron.
>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.
A technology finally came up to make a Java desktop app look better in comparison...
A technology finally came up to make a Java desktop app look better in comparison...
I always laughing when I'm thinking about it. A lot of tech people complained about Java being resource-hungry. Just to get another more resource-hungry technology. It just means that those complaints are not very serious. If people like software, they'll use it.
>It just means that those complaints are not very serious. If people like software, they'll use it.
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.
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.
> Or rather, if people have no other options, they'll use whatever they are given.
I have a simple example: Discord. It's a popular voice conference application used by many gamers. I played WoW for many years and I saw voice software gamers used. It was Ventrillo, it was Raid Call, it was Team Speak. They are native programs. Discord is very recent player but it completely disrupted this ecosystem. In few years every WoW community switched to Discord. Nobody cares that it's JavaScript with React (AFAIK). But everybody likes slick interface and features.
I have a simple example: Discord. It's a popular voice conference application used by many gamers. I played WoW for many years and I saw voice software gamers used. It was Ventrillo, it was Raid Call, it was Team Speak. They are native programs. Discord is very recent player but it completely disrupted this ecosystem. In few years every WoW community switched to Discord. Nobody cares that it's JavaScript with React (AFAIK). But everybody likes slick interface and features.
It helps that Discord is amazingly fast and responsive and doesn’t “feel” heavy.
Those people people were complaining about it 10 years ago. In those times I remember that you could recognize a Java desktop application because you could count the seconds that it would take for a menu to open after a click. While the current batch of Electron apps use lot of memory/cpu/battery, they usually fare _much_ better in interactivity, which is what often drives away a user.
The people that cared about their users already had the option to AOT compile those Java applications, or actually write them properly.
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.
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.
> count the seconds that it would take for a menu to open after a click
if that's really the case, then it was the application writer's fault, as java can be made just as responsive, if not more so, than electron. The GC can be tuned far better tha javascript!
if that's really the case, then it was the application writer's fault, as java can be made just as responsive, if not more so, than electron. The GC can be tuned far better tha javascript!
I agree that a Java desktop application can be responsive, in fact I use a couple of them from time to time that behave quite well.
Back in the day though my experience was that most of the Java software had terrible performance. In that case, I think it's correct to blame the platform for making hard to have a smooth experience "by default".
(In the same way, for example, that we can blame C for not making it easy to write safe program, even if a programmer should be able to write them properly)
> The GC can be tuned far better tha javascript!
On this I agree completely! (altough my experience with that is mostly on the server side)
> The GC can be tuned far better tha javascript!
On this I agree completely! (altough my experience with that is mostly on the server side)
Java isn't so much of a hog anymore. My stupid little Kotlin JavaFX apps with a dozen Maven deps sip memory like too-hot coffee
JavaFX was released nine years ago.
V edit: yep my reading comprehension is not on point today
V edit: yep my reading comprehension is not on point today
I can't believe JavaFX is still alive, it's been years since Silverlight and Flash died.
They're talking about electron.
It's nice. I tried it out on a mac. The experience leaves something to be desired. The startup time is excessive. It doesn't feel lightweight. When scrolling through a response body the scrolling feels completely different than on every other app on my mac. This must have something to do with java? It seems every "click" of the scroll wheel scrolls by a little more than half a line. Every other app scrolls ~3 lines per click. Keyboard shortcuts seem windows-specific (ctrl-t to open new tab). There are other little things here and there (and some documented on the github page) but overall it's nice. Can't say that it's an improvement over electron.
Startup time was definitely faster than Insomnia on my Linux laptop. Also no issues with scrolling either.
Hi! The dev here. Thanks for trying out Everest.
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.
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.
Start up time was like a second for me.
Hi! I'm Rohit, the dev behind Everest.
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.
Thanks, again!
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.
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.
Thanks, again!
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.
> ”HN keeps throttling my account since I'm a newbie around here”
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.
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.
> Why Everest?
> 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.
> 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.
Compared to a standard Electron app, I'm sure the Java version will seem pretty svelte.
Sign of the times, I guess.
You can still use Kotlin + TornadoFx (https://github.com/edvin/tornadofx)
Is TornadoFx supported native without JVM? AFAIK TornadoFx is just a layer around JavaFX. So, Kotlin/TornadoFx should use the same resources as Java+JavaFX.
Yeah, I think the usual approach is to ship the JVM with the app.
And last I looked it (like ScalaFX) runs against Java 8, so no Jigsaw to shrink app sizes.
And last I looked it (like ScalaFX) runs against Java 8, so no Jigsaw to shrink app sizes.
Which it does. JavaFX doesn't do native but its given widget takes a very conservative and elegant approach to styling.
Nice work; it does look nice and I'm glad JavaFX is getting a little love.
Thank you for not choosing Electron!
You're welcome! That was the whole point of the project.
User convenience >>> Developer convenience
User convenience >>> Developer convenience
Nice work! Although the UI looks too similar to Postman IMO, it's a great way to showcase what's possible.
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.
https://github.com/edvin/tornadofx
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.
https://github.com/edvin/tornadofx
ScalaFX[1] is another excellent option for writing JavaFX apps. The resulting application will probably be slightly more bloated though since the Scala stdlib alone is around 5 MB.
Also, ScalaFX doesn't seem to be under active development, which is quite a shame tbh.
[1]: http://www.scalafx.org/
Also, ScalaFX doesn't seem to be under active development, which is quite a shame tbh.
[1]: http://www.scalafx.org/
I was a little bummed to see this was not using Kotlin and TornadoFX, I've used them together a little and they're much more pleasant than using plain Java + JavaFX.
I find myself dipping into Java code a lot, and mentally translating examples from Java even more, with TornadoFX, particularly with regards to XML Scene Builder and databinding. K+T are very pleasant, but the docs have a ways to go
This looks nice and clean compared to some of the other tools in this vein that I've used.
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.
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.
I wish all free utilities put this amount of effort into UI design, looks really clean and different
Thank you so much! A little bit of CSS can go a long way. :)
I don't mean to knock this project because it looks interesting and I wish the developer all the best. But, why does every damn project announced have to be "lightweight"? Even the ones that are definitely not light anything.
In general I agree with you, I seems to come up a lot with javascript frameworks. But in this case, it's a pretty specific claim, right? The dev is saying that it's lighter on resources than Postman because it's built with Java and not Electron. I think it's fair even given the current overuse of "lightweight."
It might be fair if true. But is it true? In general java desktop apps that I've used have been heavy users of memory & cpu resources (I don't think any of these were JavaFX-based though).
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.
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.
In my country there's an aphorism that roughly translates as "Tell me what you boast about and I'll tell you what you lack".
It's a marketing term. It is often not provable either way and sounds good.
It's lightweight compared to the other options because all the other options are Electron based.
It's like saying something is "fast" - its a platitude that can draw developers to at least look at it, which is hard to do with all the new projects coming out constantly.
I feel like to announce it as leightweight you should at least include memory/latency benchmarks.
I feel like to announce it as leightweight you should at least include memory/latency benchmarks.
I've been trying to find some non-trivial JFX code to study, thanks for making this!
You're welcome! I'm glad this helps.
Very short feedback: it looks very nice (startup time was fast on my Mac). However, some of the usual Mac hotkeys in text fields didn't work. In (for example) the Chrome URL field I can press ctrl+a to go to the beginning of the URL (in this case I forgot to write http://). Didn't work.
Nice looking client. I've been tipping away at a JavaFX application of late. I'm shipping with a JVM and bundling into .app/.exe distributions. Looking forward to seeing what you did to learn from it.
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.