I don't like it, here's why. The current version is very compact, each line of text is a different article. All the complex CSS makes scrolling on android Firefox hang.
Really it just feels wrong for hackernews, the site that works in elinks and only uses 7 or so optional lines of JavaScript.
This doesn't look like a "Hey look how much I improved HN's CSS!" kind of project. It calls itself a "HN clone built with Vue 2.0 + vue-router + vuex, with server-side rendering", so one presumes that it was made to showcase those things (as opposed to, because the author felt HN desperately needed a front-end framework and thumbnails).
I mean, if you think it's using Vue wrong then flame away, sure. But critiquing that you prefer HN's current design strikes me as a bit like going to a "TodoMVC in framework X" project and commenting that you prefer to use paper and pencil.
Yeah I don't like the large image square, it might be cool if list mode could be toggled into and remembered via local storage or ever side storage
2 counters points:
- The low-js version is already pretty good and usable without js, why make a clone to specialize in using even less JavaScript?
- vuejs 2.x is targeting isomorphic server side rendering, so you should target your complaints to anything that should work with js disabled, but only works with js enabled.
I agree, all the HN clones that come up are usually just a ton of JavaScript that slow everything down. I've been using my own minimal clone[0]. It uses the firebase websocket API and focuses on speed and readability. The source is here[1] if anyone wants to fork it and create their own experience.
The purpose of this is not to demonstrate a new design for the site, the purpose is to demo a well written server side rendered + client side hydrated Vue app, and especially how fast it loads:
https://twitter.com/youyuxi/status/860856697799098368
This encouraged me to spend the morning reading up on Vue. They have a section on their site comparing it to React. AFAICT Vue is faster but react has a larger ecosystem (partially on account of a large head start)? What's the best argument for using Vue instead of React at this point?
I guess what I'm really asking: does anyone think Vue will still be good and fast in a couple of years or will it be more like Angular, breaking under its own weight and growth? (no offense to the angular folks, but I haven't heard an engineering team say "glad we chose angular" for a while)
I would add the following points from my experience with Vue:
Vue is incredibly easy to learn. The usual claim with React is "productive in under a week", while I find that with Vue, most JS engineers can be productive in a few hours. Especially for engineers coming from a background in Angular, Mustache, Handlebars, etc. the templating in Vue is very easy to understand.
The documentation for Vue is excellent, some of the best documentation I have ever worked with:
https://vuejs.org/v2/guide/
It has the advantage that it's not beholden to the whims of a large company like React is with Facebook or like Angular is with Google, given that its development is funded by a Patreon campaign:
https://www.patreon.com/evanyou
I don't anticipate Vue crumbling under its own weight. Vue is developed by Evan You, who has already shown his ability to learn from Vue 1 and iterate on that with a lean and organized Vue 2. My main criticism of Vue would be that its ecosystem is not as strong as React's at this point, as you have pointed out.
It means the initial server-rendered page comes with a JSON representation of the store used to render it. Usually in the HTML.
The client "rehydrates" this data into its own store so that its state is consistent with the data rendered. Essentially we're in the same position as if we'd rendered it client-side.
1) Consider installing an adblock plugin into the headless browser you're using for screenshots. Sometimes the ad banner takes half of the thumbnail image, e.g. NYT.
2) The thumbnail images oftentimes just repeat the title, consider reducing the size of thumbnails to fit more text.
3) In the spirit of HN, consider removing all images from thumbnails to give readers a feel for the text.
Why do screenshots at all? Just parse the open graph metadata and get the meta image the site wants to display rather than screenshotting it.
Most sites these days have a meta tag for images they want to display which is likely optimized for exactly this usage. Can always fallback to screenshots if those don't exist, but I'm pretty certain it'd be more pleasing.
You could implement this in less 10 minutes with micro-open-graph[0] (disclaimer: I made that). Runs on now.sh, so it's free to host too. (depending on how much traffic you send to it)
> Consider installing an adblock plugin into the headless browser you're using for screenshots. Sometimes the ad banner takes half of the thumbnail image, e.g. NYT.
Lots of news sites don't allow ad blockers these days. This means that all you'll see in the screenshot is some popup.
It will only actually be "bad" if the costs (losing some people with ad-blockers which are like dead weight to them anyway) outweighs the benefits (being able to force their ads to regular visitors and discourage them from adopting ad-blockers).
Otherwise, it's mostly "don't let the door hit you on your way out" case.
I suspect there are network effects of pushing out users who use ad blockers. These people, who will feel frustrated with their experience on your site, might not share your articles to other users, who in turn might not have those ad blockers installed.
I kinda like the lack of adblocker actually. It lets me avoid promoting sites with excessive advertising without having to really expose myself to any advertising (since you can't really read the text in the images, especially not accidentally).
I feel like there are trade offs. With the image approach, I can tell what I'm engaging with at a glance instead of a few clicks and page loads. I know whether a link is a blog post, repo, promotion, article, tweet without having to decipher the domain, and I can even tell whether a site will accost me for my email address.
On the other hand, one could argue a lot of what the images tell can be inferred from looking at the title and metadata alone, but this has definitely reduced my "false positive" clicks. Vanilla HN wins hands down for information density.
I totally agree with you. I have positive experience to see preview of the website, because now I could recognize what is behind the link. Personally, I really like "native" HN which is just simple, fast and straightforward to use, and I definitely wouldn't be satisfied to use the Vue-version on daily basis.
I think website preview (history-less, pre-rendered and cached) might be a possible field for interest for startups (pocket, raindrop etc.) and their browser extensions to manage bookmarks in browser, because they currently generate (and cache) image previews on their own so they can offer website preview as feature. This feature also reminds me Force Touch [1].
Because I get additional feedback for what I'm going to read (which often includes images within a post too, the formatting of the post, etc) than just the domain name and title?
Twitter was designed to be text-based and was beloved during this phase of its existence.
Around ~2013/2014 Twitter Cards were introduced. Cards are text (the tweet) + a large image (2-4 tweets in size). This was marketed to users as a preview of the URL/article content, but it was really about making the ads less obtrusive. It failed and, IMO, had massively negative impacts on the UX.
Nice full example of a working vue.js app. For me it loads very fast, almost comparable to the text-only version.
Where is the code that generates the screenshots?
I looked around here https://github.com/vuejs/vue-hackernews-2.0 but couldn't find anything. Is this the right repo/branch ?
Very nice. I would love the links to the original news.ycombinator.com pages comment pages somewhere, particularly on the comments. Also, the title element doesn't change on the individual comment pages.
Looks very pretty, though I'm not sure whether I'd prefer this. At least on mobile I definitely prefer the text version, where there is less bandwidth and a smaller screen.
I've been using the original Vue HN (https://vue-hn.now.sh/top) for months, never even turn on the original HN (unless I need to post a comment, like now).
The mobile viewport for me is slightly smaller than the width of the page, so I can always scroll left or right just a few pixels, and never zoom out. Not a real issue, but it bugs me a little bit.
I love the preview but I am a fan of hckrnews.com. is there any plan of time based sorting and a option in setting (like hckrnews) that if i click on comment it will bring me to HN discussion.
Nice! I did a far simpler 'Top HN News' project [0] as my first foray into Vue.js programming as well. Some background for anyone who is interested in how I built it - [1]
FYI: if you click the "Built with Vue.js" it takes you to the github page, which links to a live demo at: https://vue-hn.now.sh/top. This vue-hn site has a more traditional layout and is pretty clean and fast.
To the maker: it would be nice if you linked to the HN page so as to enable people to comment on posts they find via your client.
In HN the right side of the screen is underutilized. Maybe you can have the list on topics on the left, and previews on the right, etc. Or have the right area to be customizable...
But I like having a list of topics since it allows you to discard the ones that are uninteresting faster.
Maybe if you could also have tags like in slashdot and filter tags that would be good too, but HN doesn't have tags.
I like it, I guess. Neat idea. Not something I feel like I would have a use for, but I'm probably not the target audience. Heck, it's cool just seeing Vue in use.
Neater would be a thumbnail-in-the-thumbnail showing a picture of the submitter and author, perhaps on the upper left and right corners. Might require a bit of data mining, though.
I'm not a huge fan of the UI (images are nice, but only for about half of the usual HN content), but I am very impressed by the performance of the app.
The speed at which images and content are loaded (esp. during paging) makes it feel very snappy to use. I don't know why, but it "feels" even faster than the standard client.
I'll be a contrarian, I actually really like this. I can take cues visually - like seeing it's github, a blog, a service, or an atlas obscura-like piece - and a lot more quickly determine if it's something I feel like looking into given my mood or time constraints. So thank you :)
Not to hijack this post, but there was another HN skin that was created a while ago. It was posted on HN about a year ago or something and it came in at 300+ points. What the skin/website did was sort the day's HN post by number of points. Does anybody know where I can find that?
One thing that caught my eye on this is the (perceived?) speed of how fast it was able to grab a screenshot of the website and display it on the image placeholder. Likely I'd be spending some time looking at the implementation and how the developers were able to do that.
I'm not crazy about the thumbnails and here's why. The way I use HN is I look at the article title, dip into the comments first and read the top 2 or 3 to get an idea of whether or not the article would suit me. Having thumbnails is a distraction from that flow.
I like the thumbnails - but I'd like them more if they were a toggle on/off or avail perhaps on hover - so we can also have the succinct list view that makes consuming and grokking more efficient.
Why do the thumbnails have a slight orange or green overlay until I hover over them? I hate that the overlay color is not consistent and I haven't found any connection between the site and the color.
Hilariously, one of the top three links is currently your own site, which fails to render properly. (https://h-u.gs/Ky20B for reference.)
That aside, this is a well-executed concept: It loads quickly, is fairly well laid out, and the comment section is more modern feeling than the original HN -- if a little too modern for my taste.
I'll never use it, the thumbnails are completely useless to me, and I'm in Australia. Dynamically loaded content is garbage, over here. Too much time spent staring at an empty screen waiting for content. The actual linked-site content takes as long as it takes, of course, and you have no control over that, but it's definitely well done!
Really it just feels wrong for hackernews, the site that works in elinks and only uses 7 or so optional lines of JavaScript.