
Everest: A lightweight REST API client written in JavaFX - EpicBlackCrayon
https://github.com/RohitAwate/Everest
======
FlyingSnake
Nice work!

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.

~~~
rohitawate
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.

~~~
FlyingSnake
> 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](https://httpbin.org)

~~~
rohitawate
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?

~~~
FlyingSnake
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/deflate`),
`[https://httpbin.org/status/418`](https://httpbin.org/status/418`), and
`[https://httpbin.org/brotli`](https://httpbin.org/brotli`), and they all
failed on me. It would be cool if you could use httpbin as a test suite.

------
coldtea
> _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...

~~~
vbezhenar
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.

~~~
mrighele
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.

~~~
chii
> 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!

~~~
mrighele
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)

------
saberworks
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.

~~~
Tsarbomb
Startup time was definitely faster than Insomnia on my Linux laptop. Also no
issues with scrolling either.

------
rohitawate
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.

~~~
grzm
> _”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.

------
gred
> 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.

~~~
krat0sprakhar
You can still use Kotlin + TornadoFx
([https://github.com/edvin/tornadofx](https://github.com/edvin/tornadofx))

~~~
pkhagah
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.

~~~
dropofwill
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.

------
camgunz
Nice work; it does look nice and I'm glad JavaFX is getting a little love.

------
tomc1985
Thank you for not choosing Electron!

~~~
rohitawate
You're welcome! That was the whole point of the project.

User convenience >>> Developer convenience

------
krat0sprakhar
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](https://github.com/edvin/tornadofx)

~~~
erikdared
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.

~~~
tomc1985
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

------
bunderbunder
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.

------
dionian
I wish all free utilities put this amount of effort into UI design, looks
really clean and different

~~~
rohitawate
Thank you so much! A little bit of CSS can go a long way. :)

------
Zelphyr
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.

~~~
wuliwong
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."

~~~
crispinb
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.

------
Sophistifunk
I've been trying to find some non-trivial JFX code to study, thanks for making
this!

~~~
rohitawate
You're welcome! I'm glad this helps.

------
FredrikMeyer
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://](http://)). Didn't work.

------
robinhowlett
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.

