BackBlast

And yet I bet you often use "native apps" that are really just repackaged web views put into the app store. Without even knowing it.

> So how can you both want web apps to have more native capabilities and want to avoid apps because they have too many native capabilities?

You seem to totally miss my point.

A native application can do things like sniff local bluetooth devices, track your GPS location, snoop your clipboard. Something a web app can't, because the web APIs have been much more carefully vetted for privacy.

It's this fine grained user tracking that is behind the push towards using the app store. Companies want to know everything your doing, where you are, etc etc. That's much more difficult through a web API as compared to native APIs. This is why they will intentionally cripple their mobile sites and push to use their apps. They want native API level user tracking.

For a real list of objections...

PWAs don't integrate well into the native menu system, like say MacOS. This is much more noticeable on desktop. On mobile, it's fine.

The access to the file system is more limited (can be a feature rather than a limitation). Again, this is more noticeable on desktop as mobile apps tend to be heavily sandboxed.

Specialty hardware access like bluetooth, USB doesn't work. Direct access to the network stack or information isn't available, etc etc.

It's much more popular to use a wrapper around an HTML5+JS+CSS stack to overcome these shortcomings. Electron, Capacitor, etc.

Reduced feature set -> this only demonstrates a lack of investment, because it is not fundamental to the technology.

Buggy -> same demonstration of a lack of investment, not fundamental to the technology.

Slower -> I only see this "objection" on hackernews. Every user I talk to just wants their stuff to work, speed doesn't even make their list of concerns.

It's not that they suck. Most users probably can't even tell the difference on modern hardware.

It's that you can't spy on your user nearly as effectively with a web app compared to what you get with native. You're limited to web APIs, instead of native APIs. Which is why, I believe, there is a full court press on so many sites to get mobile users away from websites and into their apps.

I'm not alone in preferring to just use a website and not clutter my phone with apps for every online site I may interact with. Yet many sites actively press me to switch to the app including crippling the mobile version of the site. Removing features that work fine on desktop as soon as they detect a mobile client.

My experience matches this.

If there is a native dependency, then moving major node versions or moving to arm can cause difficulties or straddling the python version the gyp build system is based on.

It's worlds easier than trying to insure your C/C++ build environment is prepped properly to build a binary.

Updating libraries is usually not too bad, even across major versions. But that can be a bit of a wormhole trying to get everything squared away and all versions updated. This seems to be particularly true since all major frameworks I've used have gone from snake case deps (framework-module) to @framework/module.

> But is there any real evidence that adult content is harmful to underaged people? Unless scientists have put together a rigorous study, which even then there are confounding factors. Like all existing studies are small and don't control for desire to access such material.

Plenty of people who have gotten completely out of pornography can tell you directly about the difference in their lives. That doesn't require a study. It's as simple as, I touched the hot stove, I got burned. Perspective provides better answers than numbers. We don't need a controlled study of 1500 randomly sampled people to establish that touching a hot stove is bad. The difficulty is that this "touch" can play out over years or a lifetime and is done principally within your mind and affects your relationships and emotions. You can find various studies [0] to support these general conclusions also.

When you're a regular consumer of porn, you cannot really see its effect on you unless you have a clear perspective of what it is like to not be a regular consumer of porn and indulging in objectifying sex objects in your mind. Teenagers, or worse, children, who have become addicted, haven't had the time or experience to have any other perspective. All they know is the haze of porn sexuality.

It clogs up your love receptors and transmitters like a drug. It's like seeing love through a thick fog, being unable to really comprehend it. Without perspective the individual just assumes they can see everything clearly. That a sexual relationship can be cheaply bought at a glance and satisfied in a moment and then tossed in the trash when inconvenient without even needing to talk to someone. It creates the appetite for low effort relationships, which are often short-lived instead of durable. We should strive for the kind that can go 60 years of happiness for both parties and be more in love than when they started. That's what we're capable of. But with lust addled minds mired in selfish indulgence — we don't get there.

0: https://marripedia.org/effects_of_pornography_on_marriage

This is a graphic novel, in other words graphic depictions of sexuality/sex.

This isn't "bending over backwards". It is simply wrong to have that material there. This kind of material is damaging to children and should not be freely available in the public school library system.

Currency is the only one of those that actually works within the corrupt legal system because it doesn't require any action on the part of the corrupt system. You can use it directly with other parties.

(smart) Contracts? Without institutional enforcement, doesn't matter. Maybe being all on-chain, but that hasn't really functioned.

Ownership (NFT)? Doesn't work at all without some level of institutional enforcement.

Blockchain does only one thing well.

The web is, frankly, the most open and level information and business playing field in the history of the earth. The ability for Joe Random to start a business on that platform, run compatible tools, and get in front of worldwide customers has simply never been greater or easier.

Yes, there are a lot of proprietary players today. Particularly all mobile platforms, and some gatekeepers like search and attention claiming groups in social media. But the web still dominates as the primary platform, and it remains quite available to everyone.

We don't have to "swing back", it's already here in front of us. We could utilize it better, and reject some of the platforms holding us back. But that's up to each individual.

That's a good bit of info. Excellent, I'll tuck that one away for the future.

Only way I could figure out was using the core SDK. There was no service-only option that I could find. I just spent 5 minutes looking, just now, to see if another option exists. I got nothing.

So... if it is out there, it's complicated enough I couldn't find my miss-steps then or now.

Have you ever tried to import the AWS SDK into a front end client? It's huge. Last time I tried it, it added multi MB of JS to my SPA, so I could do a relatively "simple" call using it. Yuck.

It did not tree shake cleanly with my build system and I eventually ended up just yanking AWS from the stack entirely.

N5105 Jasper Lake systems do this pretty well. Has a good iGPU, particularly for a low end budget intel chip. Efficient. Has Quick Sync for video.

The laptops use the N6000 chip, N5105 is for the small desktop lines. There is also a more expensive N6005 for desktop.

N6000 is more aggressive in power savings. So higher single thread, lower multi. It also has more silicon dedicated to the GPU, which is about a 25% boost (30 execution units vs 24).

The biggest practical difference I've seen is that 95% of the laptops have fixed memory that tops out at 8GB. HP has one that accepts an SO-DIMM. If this is a reasonable level for the minecraft they do then you should be fine. I know with my kid's systems I had to go up to 12GB because of the mods they like.

The iGPU on Jasper Lake CPUs is actually pretty good, particularly for the price. Much more potent than previous iterations of this class of CPU.

I wore out the USB-C connector on my android phone in about a year and a half of daily charging, so probably lasted less than 500 cycles. I had to resort to wireless charging to keep the phone functioning. This is my first long-lifed usb-c connector and so far it doesn't impress for durability.

My wife has used apple for years, while she does need new cables from time to time the phone side has never had an issue.

It seems disingenuous to me to call MacOS a walled garden.

It may be a cultivated garden, but there are no walls. You can go download, build, restore, or otherwise use the software you like.

I used a very expensive 2019 Intel Macbook Pro, and then an M1, not even the pro line. There was a big difference, the M1 build times were half and that turned directly into better productivity.

How to multi-cloud.

* Start with your architecture, KISS is king. Monolith using as few pieces as you reasonably can. Do you really need two DBs? Do you really need a message queue? etc. Trim, cut, remove. Scaling is mostly accomplished by using larger/faster systems.

* Only use the basic services universally available (VM, S3). You need your own provisioning and backup scripts and routines.

* Use your own VPN, nebula has been good for me. Makes your multi cloud infrastructure look like a flat network internally.

* Be very aware of egress costs and how your provider calculates them. Keep intra-cloud comms down. Don't do obviously bad things like host the DB at a different provider than the app server.

You can also mix on-prem/colo with cloud fairly seamlessly if you've built up this way. Cloud makes sense for really small, and for quick changes. Own your hardware when it makes sense. Make the switch when the finances line up with no need to change any software.

If something goes wrong at AWS, and it does. You have no power over recovery. The more of the stack you own, the more such ability you do have.

If you run a competent organization, this can be a boon. If you have serious deficiencies, it may well be the opposite.

Kids are where you find real and lasting fulfillment and happiness.

Go visit an old folks home and ask to hear about their lives. They don't talk about work accomplishments, they talk about their family and particularly their kids. When everything is put into perspective, that's what vast majority views as most important. It's hard-wired.

> I don't know what they do. I'm single and feel like I have time for nothing :P But it's clearly possible.

It is likely that, for these people, their hobbies and extra time are plowed into these productive pursuits. Which likely means they use none or very limited modern time syncs like TV, video games, sports, youtube/tiktok, facebook/internet forums, etc. It's actually pretty amazing how much time we waste on these things.

Additionally, someone who is dedicated can often find 15 minutes here and there on a commute or while running errands to listen to a segment on a podcast about an industry or technology. And when you can't do that sometimes just thinking things through in those moments, changing a diaper or in the checkout line. I'm amazed how much about starting a company is about thinking through everything carefully, so you don't waste as much time running about.

Finally, constraints force people to get creative to accomplish what is important to them. It's not uncommon for very productive people to also have large time constraints.

You can get an Intel NUC 11 Essential kit [1]. It comes with a low power N5105 Jasper Lake with 4 cores. This is an atom core (Tremont), the rev before Gracemont (Intel E-core) built on Intel 7. It's about $165 with case, power supply. You need to supply RAM (DDR4 SODIMM) and SSD (M.2 2280 NVMe or SATA). It's probably one of, if not the best bang/buck small unit on the market from a major US based vendor.

[1] https://www.tech-america.com/item/intel-nuc-11-essential-nuc...

It really depends on what you are building.

Vue with Quasar is pretty good for getting you a good development velocity in the front end and has a lot of useful build targets. I like to build fat clients to minimize what the server is doing. If you can just convert an image to the proper sizing in the front end, why not just do it there? Lowers your cloud costs and makes what there is nice and responsive, just need validation.

The backend can be whatever you prefer.

You just have to love the different collapsible goal posts everyone sets up for each other.

I believe that you are close to the mark the market is starting to look for.

I hope to build a competitive system as I think I know how to bring it together with a workable business model. When I have the time...

The limiting factor of the CD/DVD drives was seek time, not read speed. Seeking a spot on the disk was on the order of 150ms. You basically got 5-7 read OPS. The best drive I remember stood out at 120ms seek, some would be over 200ms seek. Sometimes this was a hard number to track down. Even with a 48x drive, installation could easily still take 30+ minutes particularly if the installer wasn't optimized for sequential read off a flat file.

Sometimes you got a really bad installer, and it could take a pretty grueling 2+ hours. Some companies chose to optimize for space (thus cost..) rather than user experience.

As space got more plentiful it would sometimes be easier to copy the disk and remount it and then install.

> Most 'performance tuning' out there is eliminating quadratic functions and putting stuff into simple dictionary caches. This should be easily teachable to any competent developer.

That does happen, but some of the more severe performance issues I've seen are memory related. Every byte allocated has to be freed. If you lower the memory profile of your function then you reduce the overhead of running the code significantly.

I recall a web service that ground to a halt and would sit at 100% CPU, after I put it in a profiler 97% of the cycles were in the garbage collector. Dig a little deeper and I found that the caching library used was cloning the data before sending it back. Ahh, junior devs.

I rewrote a library with the same interface that did not clone the data, this was safe as the original data wasn't being changed, 15x speedup from 10 req/s to 150 req/s.

Then I dug deeper and changed which data was getting cached. Cache post-render and post-compression instead of the pre-render database calls. 150x speedup from the original or 10x from the previous point. The system went from being able to serve 10 requests/s to 1500 req/s. This change also was safer since nobody is going to ever try to alter compressed data, no such guarantees from the cached database calls.

Not necessarily. If you're running the browser anyway, and the app is a PWA and can share that same instance. The "browser" overhead is not really there.

A native app, lets say that wants to play video and is using a cross platform GUI. You've got to load and run that code, and have all the relevant code in the native app's address space. That would be a bunch of code that needs to load over the PWA which is leveraging something you have loaded in RAM anyway. In this case the native is actually worse than the PWA for resource utilization.

Launch CPU cycles can be similar, running a huge swath of GUI code for the native app vs a pre-loaded browser which only needs to run the JS and render the page.

Having your app's runtime already loaded on the system is a huge advantage.

Electron does not benefit from these advantages though. These are PWA exclusive advantages.

Somehow a security feature in browsers called CORS, that isn't present at all in native apps, is both a vulnerability and a downside? I don't understand this line of thinking.

I had a private family Slack instance, and we observed similar things. A question about buying a particular brand of soap would be spoken in the channel and ads for that exact soap would show up minutes later on Facebook. No searches or other activity, just a text query to a person through Slack.

I prefer to think that some of this is chance, or Facebook just guessing really, creepily well. But after the 3rd or 4th time we observed this same scenario play out, trust has eroded, even if I have no evidence as to how this is happening. It's time to change up the tools.

I now self-host an open source chat application, and we have not had another repeat of this kind of creepy ad invasion.

To get around CORS you have to run the stream via a proxy from a place that will allow requests from the domain you are hosting it from. Or the origin stream has to allow the domain directly.