ss3000

If they dived deeper into the usage patterns and broke down app usage by specific apps, I'd suspect a vast majority of that time is spent in a tiny handful of popular apps, since there are also countless studies pointing to the fact that consumers don't install more than a handful of native apps.

If you remove time spent in those popular apps and their respective websites from the stats, the data would likely paint a vastly different story (that might not be in the best interest for a site that relies on pushing "Launching mobile apps for your WordPress site" to highlight ofc).

As far as I'm concerned, the problem is the people who choose to disable JavaScript and demand to be catered to without considering how much extra development resources I'd have to allocate to maintain a version of my app that works with JavaScript disabled, despite barely even constituting a rounding error in my usage statistics, and the JavaScript version offering a vastly superior experience for the rest of my users.

I think you're taking that specific opening question a bit too literally (though to be fair, I'm also at fault for not being as direct as I could have been with my point). It's fairly clear from the rest of my post and from the linked posts that I'm fully aware that Github/MSFT-funded Atom development has mostly grounded to a halt.

These are the actual questions I'm trying to get at:

What made Github/MSFT stop funding Atom development when their CEO went on record to say they won't?

And why haven't they announced that was the case officially?

If the very same CEO then goes on an AMA on Hacker News, surely it's fair game hold him accountable to previous public statements and ask him to clear the air. If this was just some random scrub posting their thoughts on the acquisition I definitely wouldn't have wasted my time to bring this up.

Um... I think you might have me confused with someone else?

I looked through my own post history and it looks like I did reply in a thread about this topic a while ago: https://news.ycombinator.com/item?id=22606843

(same thread that I linked above)

I can only speak for myself as to why I posted here. And I really just want an answer for the question I posted (I'm not naive enough to believe a post like this has any chance of changing project priorities at a megacorp). I wrote about this in a bit more detail here: https://news.ycombinator.com/item?id=22875388

And judging from the upvotes, a decent number of people want the same question answered. If you don't care about the answer, my recommendation would be to simply collapse the thread, downvote if you must, and move on.

I'm honestly puzzled as to why so many people seem to be actually offended by the very fact that I'm asking the question, and even seem to be taking it somewhat personally, even though it's not directed at anyone other than the OP.

All I really want is to hear an explanation from Nat Friedman, CEO of GitHub, the human being, who said he wouldn't pull resources away from Atom development and then evidently did so soon after, to end all this needless speculation once and for all (and what you've suggested in your comment is still speculation, however plausible it might seem to you).

It offers very little solace to the few Atom users still hanging on, but I think the least he could do is end the speculation, and provide some certainty on Atom's future as a GitHub/Microsoft funded project so we could decide to either move on or stick around for longer.

Please realize that there still hasn't been an official statement that Atom's development at GitHub/Microsoft has been halted/dramatically reduced, or that they hope to transition it into a community led project, or anything to that effect.

I hope an official nail in the proverbial coffin is not too much to ask for.

EDIT: This comment was a lot snarkier in an earlier iteration. In hindsight, I realize that was in bad taste, so I've reworded it and adjusted the tone. I don't think being needlessly confrontational adds any substance to the discussion here (or anywhere else for that matter), so I would like to apologize for that and hopefully de-escalate so we can resume civil discourse.

Can you explain what happened to Atom development?

I've seen numerous posts noting the sharp decline in contribution soon after the acquisition was announced.

https://news.ycombinator.com/item?id=22601451

https://news.ycombinator.com/item?id=21142934

Without an official explanation, given the timing, it'd be reasonable to assume you pulled development resources away from it, the exact thing you actually went on Reddit to claim you wouldn't do:

https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...

P.S. I've observed that these kinds of posts tend to turn into a place where people shit on Atom in favor of _insert preferred other editor here_. Feel free to do that here too, but just note that I'm not going to be obliged to engage since it's completely orthogonal to the topic at hand. I think any remaining Atom users at this point are likely already painfully aware that Atom has long since lost the war in developer mindshare, but don't let that stop you from pouring salt on the wound.

For travel, is there any benefit to using TransferWise's debit card over a traditional debit/credit card that advertises 0 foreign transaction fees?

I remember somewhere about how the conversion rates are dictated by Visa/Mastercard on most credit/debit cards. Wondering how those rates compare to TransferWise's, and if their extra fee on top is justified.

Some examples: https://www.schwab.com/checking https://creditcards.chase.com/rewards-credit-cards/sapphire/...

I too swear by my Shures. I've tried quite a few NC headphones/earphones over the years but they've all had issues with distortion, wind noises, etc to some degree, whereas my Shures can passively cut out just as much noise as the best of them while never introducing weird artifacts that break immersion and take me out of the music.

I just wish they'd release a fully wireless version with the same comfort and fit (not the replacement cable+dongle thing they currently have).

Not entirely sure if the article is aimed at a web audience, but if it is, this would be an awkward justification because the unit "pixel" in CSS is normalized w.r.t DPI.

Ah I see, that makes sense. Shadow DOM definitely offers much stronger style encapsulation than a React component where you can only "enforce" that components shouldn't reach into it to style internals by convention.

> Web components do this with the `:host` selector that styles the component from within its shadow root. The styles applied with the `:host` selector can be overridden by the outside styles, without the component needing to weaken encapsulation by allowing styling from the outside via JS properties.

I don't see how the React approach of accepting styles as JS props is any weaker in terms of encapsulation compared to your example above. If anything, it offers the opportunity for stronger encapsulation because it supports limiting/transforming the styling props we accept through those JS props, and even allows us to define a styling API for our component that's completely independent of CSS semantics, enabling components APIs that can span multiple platforms with independent implementations.

Would you also take gradually losing access to other modern web standards apps rely on as time goes on until the only realistic option we have for building, deploying, and consuming apps are the walled gardens controlled by 2 corporations who have arbitrary rules on who can and can't participate, freely stifling innovation/competition as their interests dictate, and taking a more and more outrageous cut of all economic activity on the platform?

That's where this is going.

> "first they came for localStorage and I did nothing"

This reminds me of read receipts in chat apps. Hate them with a passion. I usually just leave the chat itself unopened and read the notifications until I'm ready to actually reply.

IMHO, Deno's approach to package management, that is to say, no package management ("packages" are just source files that you'd import directly using urls or file paths), is a breath of fresh air compared to the status quo in node where to import some javascript that's already hosted at some url (say on github), you first have to "package" it by describing it with some manifest, uploading it to some registry at a different url than the original, and then "install" it using a package manager from that other url, and at the end of the day not even have any guarantee that the content of that thing you installed actually matches what you saw at the original url.

Deno's approach on the other hand is doesn't force any of that indirection onto the user, and is analogous to (and compatible with) the model of modules on the web. Package management systems can be easily layered on top of that if the use case actually warrants that extra indirection, rather than having it baked into the core of the runtime.

I personally really enjoy the automatic line breaking behavior of prettier as it frees me from having to make this entire class of purely stylistic decisions but still have code formatted in a reasonably legible manner.

But I also have wished on multiple occasions that prettier was just an opinionated preset on top of a much more configurable core, which would make it less of a taboo to add options for what are obviously massively divisive formatting preferences.

Case in point, all the most popular issues in the repo are some form of people asking for options or changes to the current behavior: https://github.com/prettier/prettier/issues?q=is%3Aissue+is%...

And let's face it, that whole idea of a 1-size-fits all JS code formatting tool to end all formatting debates? That ship has sailed a long time ago. The debate just moved to what prettier options to use: https://prettier.io/docs/en/options.html

I think the real value of prettier these days is that we can debate as a team once, decide on an option, and then have that decision be enforced automatically moving forward. A configurable core + opinionated defaults can serve that use case just as well.

I don't think anybody's expecting them to fund both indefinitely, but given that their soon-to-be new CEO went on the record to say that they would actually keep funding Atom development, I feel it's fairly reasonable to expect that they wouldn't pull funding from Atom almost completely as soon as the acquisition went through. That's a really shitty move no matter how you look at it.

Personally, I'm just not a fan of having to keep charging those smart watches every other night.

Especially when taking them off to charge at night means losing access to sleep tracking, which for me is the only killer feature smart watches have going for them over the smartphones that I already have.

That's altering the _code_ as opposed to altering the _state_ of the system.

I think the "_running_ app instance" is the key distinction here.

Breakpoints require halting your system, so while you can inspect the system's state, you can't meaningfully alter it as you could with the kinds of Clojure REPL workflows talked about here.

Another limitation is that you can't really inspect parts of your system outside the context of the currently running function where the breakpoint was triggered.

I think debugging with state-preserving hot reloading in UI development is probably the closest analogue I've encountered to debugging workflows with a Clojure REPL, though it's still nowhere near as flexible.

I think the major difference between the Clojure REPL experience and most other language's REPLs that I've worked with is the fact that Clojure REPLs can connect to a running stateful system (or a situated program as Rich Hickey coined it), and allows you to explore and manipulate the system's state and behavior dynamically at runtime, which makes it an incredibly powerful tool for building and debugging such a system.

Most REPLs I've used in other languages are strictly for evaluating individual commands in an isolated, stateless manner.

Part of it also comes from the tendency of large orgs to ship their org structure.

It can oftentimes be worthwhile to have individual teams each fully "own" a piece of the product, and that also comes with the autonomy to choose to duplicate stuff that other teams might have already built rather than working with them and tweaking it to match their own specific new requirement.

This significantly reduces communication & coordination overhead for delivering new features, at the expense of consistency and code reuse, which can often be a worthwhile tradeoff at scale.

Interesting, I thought this was going to have something to do with their acquisition of Spectrum, but it appears to be an entirely separate in-house feature. I wonder what's going to happen to Spectrum longer term then.

https://spectrum.chat/spectrum/general/spectrum-is-joining-g...

Sure, that can kill a few of them, but entirely inadequate for actually getting rid of any real infestation. They breed much more quickly than the diatomaceous earth can kill, and can survive on the order of months without any feeding so you can never be sure to have killed them all with a passive approach that just waits for them to come out and kill themselves.

I can confirm all of the above, having lived through an infestation myself. Had to ditch my dirt cheap apartment and basically throw away all of my belongings at the time out of fear of bringing any of them with me to the next place ("luckily" I didn't have much at the time as I was a poor student). And then ended up spending $2000+ anyways on a full room heat treatment for my new place because I could swear I was still getting new bite marks and it was driving me insane (though in hindsight they might have been what's referred to as "phantom bites" but I wasn't going to take the chance to find out after going through that whole ordeal).

Up to that point I've lived in shady places with ants, roaches and rats and other shitty stuff but none of that bothered me too much, so I thought I could handle any shitty living arrangement as long as the price was right, but the bed bugs thing was by far the most nerve wracking experience of my entire life, and even made me contemplate suicide at one point. I learned to not cheap out on a place to live ever since... And definitely never pick up used furniture lying on the sidewalk, which I used to do a lot...

So yeah... I can see why people might have reservations against used mattresses...

Switched from chocolatey to scoop a while ago and never looked back. Most package installs don't need admin rights, and for those that do, there's the `sudo` package that it recommends, which is a life saver when working with the terminal on Windows in general.

> Also some services straight up refuse to send SMS to cloud phone providers meaning you can't sign up for certain services that needed a verified phone number (unless they had an option to receive a call with the verification code which worked like 25% of the time).

I've ran into the same issue with this on Google Voice. Though sometimes I wonder if I could have gotten the best of both worlds by just porting a number from a traditional carrier to Google Voice/Twilio.

Are these kinds of checks only against the number itself? Or is there some kind of dynamic registry?

Chargebee looks really promising but the pricing of minimum $250 per month feels way too steep for bootstrapped businesses that are just getting started, and a billing system feels like something I'd want to decide on at the beginning and have it scale with my business rather than starting with something basic and then have to refactor to something else later once the business starts gaining steam.

Anyone have recommendations for similar services that have a lower price of entry?

Anyone aware of a VPN provider that offers WireGuard and supports more than 5 simultaneous connections? I've been using Mullvad but the 5 connections limit is starting to feel really restrictive.

I have both a Surface Go and an iPad Pro, and while using the pen on the iPad Pro on its own offers a satisfactory experience, I find that it's not nearly as good as the Surface Go when it comes to accurately recognizing the correct input method when quickly switching between pen and touch inputs.

My iPad Pro very often would treat my finger as a stylus and start drawing when I meant to use my fingers to scroll around, while on my Surface Go I honestly can't even recall that happening even once, and it's a night and day difference in terms of ergonomics for me. I think Microsoft's much longer experience in handling hybrid pen & touch input in OneNote for Windows still gives it an edge at the moment.

I would argue that _most_ full time jobs probably require too much of us than we should be willing to accept, regardless of if we have energy left over to do anything else outside of those hours.

40 hours per week is more than half of most people's waking hours. That's a terrifying amount of my life to have to spend on something I don't _absolutely love_ doing, and I sincerely hope I can find a way out of it sooner rather than later.