Just downloaded! I love it. The only thing I was going to say was I wish it had the ability to resize the window and save the size for each time it opened...then I realized you were one step ahead of me and had done exactly that! Very impressive, and a fantastic example of React and Electron. I'm definitely bookmarking this to come back and learn from the codebase later.
there is some irony here... by saying this and then "We are working on Windows and Linux versions. " is not exactly fair. The entire purpose of electron is to "Build cross platform desktop apps with web technologies" so by stating that and failing to release other platforms is quite silly
Looks great - in all honesty I probably won't use it day to day as I waste enough time checking HN, although perhaps it would be a less distracting way to check it. Source code looks nice and clean, look forward to digging into it!
I really like it, runs well under openSUSE (you have to download the repo and follow the instructions under "Development" in the readme). Hope to see it's functionality expand further.
Edit:
One thing I would change is maybe make the overall border a more noticeable darker color, I keep getting confused as to where the borders are for when resizing it, and maybe a way of dragging and dropping the window (that is more obvious if it is there, I haven't figured out how to move the window without using what I assume to be KDE specific features).
Thanks giancarlostoro. That is great feedback. Let's gather more responses from others, and we will make the change. We want this to be super easy to you to use.
btw, I am glad it works well for you under openSUSE. You have made a excellent example for others to start using it, w/o waiting for a build for a specific platform. We will get there. We are working a build for Windows version.
Maybe, just maybe, we should just bundle Node and Electron into a package, install that as a shared library (similar to the way .NET and Java are installed) and then just ship, in the installer, a tool that downloads those if not already installed?
Electron is moving pretty quickly (and breaking APIs) at this point so you'd end up with just as many versions of the shared library as you would copies in applications.
The very fact that we 'do not break APIs' is one of the reasons that this newsreader is 100+ MB. If Google Chrome wasn't 4,490,488 lines of code designed across years of development to, well, _support old web APIs_ -- then it would likely be much smaller. :)
Well, and, as the parent said, even with this you still can’t use the same version of the library even for a few months. That’s the worst out of both worlds.
I would bet that my newsreader uses booth less RAM and less disk space. This is what feeds were invented for. Why should I install that much bloat just for reading HN?
That's a pretty bad metaphor. I am refusing OP's free beer, because I don't drink beer. I also question the need of giving away free alcohol. Instead, I take the free glass of water from the next guy.
Come on guys, this isn't Reddit so lets keep the commentary constructive. I feel rtz12 has some valid points - although his/her language style contains emotion you can't presume to know why that is without being that person.
Is it really a good, constructive point, though? Boo hoo, too big? Having to make concessions drools?
The cutting edge of building xplat desktop apps with browser tech involves independently bundling Node and Chromium, so it's gonna weigh 100+mb like a single Chrome browser tab. That's life.
Yes, we all have different appetites for different sets of trade-offs.
Well, afaik you'd have to proxy HN somehow in order to get an RSS feed to feed to your rss reader?
I personally think that proxying by installing a 100 mb runtime just to be able to change some styles and change around some of the UX with custom javascript is a bit silly, but others here seem to like it, so who am I to judge?
I don't care how massive the app is compared to just web browsing...it's always great when people show off not just the product, but the open source code. Thanks!
Not particularly directed at OP, I haven't tried or even downloaded the app. But am I the only one that when I see 'Node' and 'Desktop' in a headline immediately think 'this may be really nice but it is just gonna be to big for what it does'? And, as a followup, what is the appeal of using Node for desktop dev?
The advantages would include shared tooling, a cross-platform GUI, and the ability for end-users to modify the code.
Regarding size, it appears to be around 100 MB, so you could have 20971 separate installations of it before filling up a 2 TB drive.
Memory usage could be an issue, but whether that matters will depend on your audience the app. In this case, the aim is toward HN, so it doesn't seem like an issue.
While I hope flash drives will come down in price, who has a 2TB flash drive right now? My entire desktop OS, with at least three web browsers, multiple sdks/compilers etc take up a grand total of 15GB. Granted, that'd still leave room for 150 "apps" in the same space (note that I actually only have 3GB free, though). Still, 100 MB for what is essentially high-level code? It's absurd.
[ed: Not directed at op, as such, just how silly the general node ecosystem is currently]
You are not the only one. But not because of Node (which is not that big) but because of Electron.
That said, the big issue is that we don't (yet) get to share Electron installs. If all desktop applications had to bundle all their dependencies, including what the OS already provides to them, they would be just as big.
Electron apps themselves aren't that big. Even Atom.
Electron really should be treated like `node` and be a dependency. Of course you could still package your apps with Electron, and you can do that with node too (if you wanted to), still nobody distributes node applications like that.
Smaller apps would probably benefit from an electron-like system that just uses the inbuilt system browser. I'm not aware of any such projects, though.
From: https://hackermenu.io/
"Do you have the habit of jumping to comments before reading an article? We got you covered. Comment is just one click away. So is vote."
I did a quick browse and search of the source on github for "comment", "vote" and "login". How do you handle logging in/submitting comments/votes? Just present the regular hn login inside the app, and use the hn site?
I thought there was some TOS/gentlman's agreement that APIs only had read access to stories, and one needed/should use the hn page for comments/votes? Perhaps I'm mistaken?
I suppose there's no rule against making a custom browser though -- while a bit heavy handed, I suppose there's really no difference between wrapping node+electron and enhancing the UI/UX with greasmonkey -- I suppose the main issue is to behave closely enough to a regular web visitor, so as not to put undue strain on the service, not demand that every visitor actually uses a general purpose browser...?
That's a pretty cool idea... but do people really want more HN? My impression is that most people want to read it once or twice a day, but are driven to it more often than that as attempts at procrastination. So this seems like it'd be a net loss for most users.
76 comments
[ 4.7 ms ] story [ 106 ms ] threadCool !!
Oh.. Mac only right now.
1- http://i.imgur.com/5WjIJ5M.png
2- http://i.imgur.com/A1VHspL.png
This is about it. When you click on any link, it takes you to the website itself.
Edit:
One thing I would change is maybe make the overall border a more noticeable darker color, I keep getting confused as to where the borders are for when resizing it, and maybe a way of dragging and dropping the window (that is more obvious if it is there, I haven't figured out how to move the window without using what I assume to be KDE specific features).
Would save a lot of memory and time for everyone.
But if a single newsreader contains more code than a full PlayStation game, you know something’s wrong.
This is just Wirth’s Law in action.
https://vivaldi.net/en-US/blogs/teamblog/item/50-snapshot-1-...
You can have a sidebar in your browser with it's own webpage displayed, so you can have Hacker News open no matter what tab you're viewing.
If OP gave you free beer would you spit it out over him and say it's too bitter?
The cutting edge of building xplat desktop apps with browser tech involves independently bundling Node and Chromium, so it's gonna weigh 100+mb like a single Chrome browser tab. That's life.
Yes, we all have different appetites for different sets of trade-offs.
I personally think that proxying by installing a 100 mb runtime just to be able to change some styles and change around some of the UX with custom javascript is a bit silly, but others here seem to like it, so who am I to judge?
Anyway, keep up the good work ;)
Regarding size, it appears to be around 100 MB, so you could have 20971 separate installations of it before filling up a 2 TB drive.
Memory usage could be an issue, but whether that matters will depend on your audience the app. In this case, the aim is toward HN, so it doesn't seem like an issue.
[ed: Not directed at op, as such, just how silly the general node ecosystem is currently]
For example, the only time I've maintained a proficiency in both a webdev stack and a native kit was when I was paid to work on both full-time.
Node's main appeal to me is a similar consolidation: using one language. At least until I find out I'm immortal.
That said, the big issue is that we don't (yet) get to share Electron installs. If all desktop applications had to bundle all their dependencies, including what the OS already provides to them, they would be just as big.
Electron apps themselves aren't that big. Even Atom.
Actually, I tried fixing that problem with `asv`: https://news.ycombinator.com/item?id=10244073
The app seems pretty nice. I wonder why people are saying harsh things?
I did a quick browse and search of the source on github for "comment", "vote" and "login". How do you handle logging in/submitting comments/votes? Just present the regular hn login inside the app, and use the hn site?
I thought there was some TOS/gentlman's agreement that APIs only had read access to stories, and one needed/should use the hn page for comments/votes? Perhaps I'm mistaken?
I suppose there's no rule against making a custom browser though -- while a bit heavy handed, I suppose there's really no difference between wrapping node+electron and enhancing the UI/UX with greasmonkey -- I suppose the main issue is to behave closely enough to a regular web visitor, so as not to put undue strain on the service, not demand that every visitor actually uses a general purpose browser...?
Currently the website has skewed image of the thing and then cropped round images of the thing.