pcr910303

It's an interesting idea. I did thinking it looked pretty scammy (felt like a crypto miner), but...

It does feels different in that it doesn't use any user's bandwidth if the site doesn't monetize it and it mandates a UI with an opt-off button if the site does monetize it and uses the user's bandwidth.

But I'm not sure if this is ever gonna work... will a nearby user device really give the content that I need than a datacenter...? There's no mention on the FAQ page how it prevents from a fake user sending malicious scripts across the network as well.

It’s not usual for news on my country to be on top of HN. Very unexpected.

I’m guessing though that the South Korean market is be significant enough for Apple and Google to not just pull out it’s business from South Korea and call it a day. I guess this is, in some kind, a victory against the huge companies.

But… personally I do find sad that this would be detrimental to South Korean app UX. Stripe isn’t a thing here, and most of the home-grown web-based payment systems have… like super shitty UX that require (on the desktop) native plugins running a server on some bespoke port. It did come a long way since from when we were the country that required IE6 for web banking, but the UX is still not really there.

I’m hoping that Apple will provide APIs for showing payment screens and Apple will still control the ability to show all subscriptions, cancel them in one single place, etc… but I don’t think Apple will ever do that. Unfortunate…

SQLite is an exceptional piece of software as well…

It’s lightweight, reliable, knows what it’s tasked for, does exactly wat it does, and easy to extend. I personally reach SQLite first in so many cases, including web backends. That the DB is a file that’s literally a cp away to backup is super-useful in development and debugging.

Really the only complaint is that type enforcement is lacking… which I wish I could have said not a big deal, but it turns out it is. I wish I had a embedded DB that’s as reliable and trustful, lightful as SQLite, but with types enforced. :-(

A bit offtopic, but I don't see much people knowing/using the Algolia API[0]. It's much better to use than the HN official API[1], since it returns the whole tree data in one request.

Unfortunately (I guess this is a big reason why people don't use it), it doesn't sort the comments – if you need the orders, you'll have to parse HN HTML (or just use the official API).

Still just two requests (the HN site, the Algolia API) is much better than recursively requesting a hundred requests, so I use this approach in my client[2].

[0]: https://hn.algolia.com/api

[1]: https://github.com/HackerNews/API

[2]: https://github.com/goranmoomin/HackerNews

I guess file formats also somewhat(?) suffer from the ‘Worse Is Better’[0] – a bunch of universal formats suffer from being not well-designed because it was a result of a popular program that worked at the right time…

[0]: https://www.dreamsongs.com/RiseOfWorseIsBetter.html

It’s still amazing to me that we use spreadsheets to handle big systems like the contact tracing system. I know the reasons – it’s probably the most effective, low-price, available at any time, but it is just so amazing that the same exact program I use to do simple calculation can also handle nation-scale contact tracing.

Remove the protocol part, and with the JS Proxy[0], you can actually do something like:

  await www.example.org

as demonstrated in a tweet[1]. This is pretty interesting IMO :-)

[0]: http://developer.mozilla.org/en-US/docs/Web/JavaScript/Refer...

[1]: https://twitter.com/rreverser/status/1138788910975397888

Unfortunately I don’t like Electron, and I did try out some solutions (e.g. Fluid[0]) that don’t use Electron, but it felt best to create a native Mac app with Cocoa.

[0]: https://fluidapp.com

I also started studying Cocoa with Big Nerd Ranch’s book.

Unfortunately, I found that resources on Cocoa are very lacking, you have to search all day to get some trivial thing to do. The best resources you have would be WWDC videos and transcripts[0]. If the subject you’re looking for is older than a few years, the documentation archive[1] might have detailed, good documentation with concepts and sample code. Some more obscure features will require you search all day, find a few blog posts from ~10 years ago, and munge them enough to make something workable.

The best resource of all was the help of more experienced Cocoa devs – the AppKit Abusers Slack [2] was very helpful and pointed out problems when I had problems. Very grateful for them.

[0]: https://asciiwwdc.com

[1]: https://developer.apple.com/library/archive/navigation/

[2]: https://appkit-abusers.herokuapp.com

Yup, just added the MIT license. Thanks for reminding!

Unfortunately I’m not expecting to support anything lower than Big Sur. I tried supporting Catalina, and having to support an OS that I don’t use daily was hard… Sorry about that. :-(

I guess I’ll have to add a compact mode that hides some of the UI. Thanks for the idea!

Unfortunately the second API is also a bit of a mess — the comment order is mixed up, so you have no option but to parse the HN HTML and sync the orders. I really wanted faster load speed (than slowly querying the tree-like API), so I did wrote that code…

Thanks for the feature requests! Will definitely add a text zoom feature and a ‘My Posts’ category.

> Any reason you're connecting to firebase rather than storing preferences locally?

All of your preferences are stored locally — the firebase connection is due to the official HN API[0] implemented on Firebase. Your HN credentials never leave the app (except for news.ycombinator.com) — it’s tucked in your keychain.

[0]: https://github.com/HackerNews/API

> Does the Algolia hackernews api ( the specific API this client uses ) still require you to query in a tree like fashion, every comment item id if you want an entire page of comments?

I’m using two different APIs — the inefficient API that requires you querying in a tree fashion is the HN official API[0], but there’s also the Algolia API[1], which is much faster and gives a much sensible data shape. I also do actually fetch the HN website as well — it’s needed for account/voting features. With these sources, it’s much faster than a usual client that gets it’s data from the official API.

> The HN website I think is pretty ideal for the type of content its displaying, a native app doesn't give you much over having a HN tab open.

I guess it’s a bit of difference on how one uses HN? I didn’t like HN tabs being mixed with other work—related tabs. I felt that having an app would be a perfect solution to me, but YMMV I guess.

> The only benefit I see from a native app is the ability to save articles and comments for offline reading

I guess that’s one more feature that I should add to my backlog :)

[0]: https://github.com/HackerNews/API

[1]: https://hn.algolia.com/api

For me, right now, this is a hobby project — until now, the feature roadmap was basically the feature that I have in mind.

I’m more than happy to get feature requests though — read/unread indication and favorites are something that I would definitely try implementing. Notifications are a bit harder because it would require polling HN — I’ll be thinking on it.

I believe this new design is the best Safari design 'in the constraints of the new Big Sur design language'. I'm liking it mostly because the Big Sur's new toolbar is too thick.

With the menubar, toolbar, and the tabbar, 106px of my total 800px height display gets to display non-content information, much of which is clutter when I'm trying to focus on the webpage. It's a whopping 13.3%! Most of this comes from the thick toolbar that Big Sur has started.

But since Apple won't be changing that thick toolbar (as we all know), the 30px vertical height (which translates to 3.6%) that I get by hiding the toolbar is precious. So I appreciate the new Safari 15 design. Really, the only problem I'm finding is the refresh button, which I'm like 99% sure will come back with all of this fuzz, and the other functionality in that (...) button needed multiple mouse clicks in Safari 14 anyway. Like... disabling the ad blocker required a long-click on the refresh button, it's now more discoverable.

Shifting address bars... I can see how that might make people freak out; Personally I've had zero problems, so YMMV.

About tab management – I can't disagree more than the article. Creating group of tabs is very much useful, it's much more helpful than having a group of windows each with different topics and prevents idle windows eating memory and CPU when only one window gets used for a long time.

I have five tab groups, one about my school, two on my personal hobbies, one on generic development-related information (including HN) and one on my work, each with 10~20 tabs. I'm guessing the writer doesn't use tabs pervasively – that's fine. But I would like to point out that it is not rarely efficient nor overall unconvincing. Thanks Apple for that tab group feature, I'm seriously getting a ton of mileage over it.

I was hoping for Windows 11 to finally have a consistent look, not have two settings, and merge the Win32 world and the UWP world… Alas, from the screenshots[0] it looks like the split continues :-(

[0]: https://twitter.com/goranmoomin/status/1404856884767592451

> it's an optimized way to do inline styles for component based architectures, because it turns out inline-styles are actually a pretty good way to style re-usable components

Yeah, I also understand Tailwind as inline-styles without it's problems:

* it provides less choices (instead of 256*3 colors you have limited choices)

* classes are (a lot) faster than inline styles in most browsers

* has access to features that inline styles can't (e.g. media queries)

(Not directly related, but) The article reminds of a recent article named 'Why Go Getting Generics Will Not Change Idiomatic Go'[0].

Using functional programming in Go... just doesn't look right. Generics are useful, but won't change the whole Go ecosystem into FP. Maybe some uses of Map might make sense, but... idiomatic code will look the same.

[0]: http://www.jerf.org/iri/post/2955

Does Emacs native-comp work outside X (i.e. works with the Cocoa port)? I thought it only worked through XQuartz b.c. gcc can’t parse the Objective-C required for the Cocoa port…

If the Cocoa port runs well, well that changes everything to me

> This is why, on the web, text input and keypresses are separate events. Terminals conflate these two, causing problems.

Yeah, so please don’t create terminal TUIs please. Very disturbing to use TUIs that don’t work with CJK languages at all. Please, please create GUIs instead of TUIs. (I’m not blaming programs reading from stdin and printing data to stdout, but the ones based on ncurse and fill the terminal screen.)

Unfortunately the status quo on text editing didn’t improve since the last time this came up on HN. Unfortunately everything I said the last time[0] still applies…

[0]: https://news.ycombinator.com/item?id=21384596

AFAIK Obj-C was based on the ideas of SmallTalk (with objects receiving messages), but mixed with C syntax.

Obj-S (originally Objective-SmallTalk) is a Smalltalk on top of the Obj-C runtime.

HN strips out prefix ‘How’s by default. I guess that was applied here as well...

I’m not sure if it’s ‘true’ intrinsic complexity: one can argue that the complexity comes from the kernel having so many different modes. (E.g. a ‘simple’ single-threaded cooperative kernel might not have this complexity.)

But it definitely is ‘useful’ complexity...

> I store all my dates in sql as text in iso format so I can easily sort them

Strong SQLite vibes... (SQLite doesn't have a date format, it has builtin functions that accept ISO format text or unix timestamps)

So many HNers pointing out that it was possible since the dawn of the web... yet the point of this article is that you can just add highlighting JS and constexpr.js will automatically optimize it. JS-based highlighters have all sorts of plugins, so it makes sense to reuse the effort.

So basically the script renders the JS-needed website, execute the JS as a build step and spit out the highlighted site. Pretty cool!

> temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.

I’m not sure if it’s temporary or process-lifespan basis, but AFAIK macOS’s sandbox does have a model where the user must grant access by using the system-provided out-of-process file dialog for the application to be able to access the files.

Pretty interesting. For an example, try renaming a file in MS Words by clicking on the document icon — you’ll see MS office asking for permission for the access of the parent directory. (Apple does provide rename functionality by it’s APIs, but MS Word does it by it’s own, which requires the permission.)

> And yet, it seems majority of HN wants to rewind from the App Store which was created as to assist users and devs with that problem.

Well, to be fair the App Store isn’t really a viable solution to these problems to a fair bit of applications. The sandbox requirement makes a large portion of ‘useful’ apps unable in the App Store.

Looks like most non-App Store apps use Sparkle[0] these days though, so it’s much better than before.

[0]: https://sparkle-project.org

I used to really use fish pervasively in my computer, but after a while I realized that I forgot literally all of bash (like I forgot how for-loops look like, how word split works…) and I just switched back to macOS default zsh.

I’m still wanting a fish-alike interative shell that improves on the Bourne shell language (and bash extensions). I’m having hopes on Oil shell [0], but it’s still in an early stage so I guess I’ll have to wait for a far future…

[0]: https://oilshell.org