thinkloop

To me the mistake is not having the back/forward buttons honor the different states. It would be a nice built-in undo/redo.

I don't think it's possible to "scramble" a site to be unscrapeable - it has to render at some point.

> a product that is similarly just barely good enough to use.

I thought facial recognition was advanced (mainly based on genpop articles), but isn't China using it massively with success?

Being a business owed many small amounts of money from many people seems expensive to collect - any thoughts on that?

> My question is what's preventing few people accumulating trust and credit lines and eventually becoming bankers for this system?

That would be great, it would be more credit for everyone and wouldn't take away anyone else's credit - and if they start misbehaving they can be quickly replaced.

"Democratic" may not have been the best term to use (edited the original comment), even though, as far as platforms go, the web probably is one of the more democratic ones. I was more aiming for "non-proprietary", "cross-platform" and "shared". Mobile apps are closed ecosystems.

> how all this would harm Google in any way

Owning half the mobile app ecosystem is more valuable than sharing a web.

How does the "Live Stream" of transactions work: https://convertcalculator.baremetrics.com/ (lower right panel)

> More access to HW is the last thing I want from the web at this moment

This is a big deal, and an irreconcilable philosophical divide. On the one hand web apps need to be able to compete with mobile. They should have access to gyros and cameras and location and offline and push - everything. Mobile apps are modern day Flash and we should strive to be rid of them in favor of a non-proprietary shared platform.

On the other hand the majority of useful information in the world is in document format. We need some sort of non-print-focused (pdf) format that we can use to share documents. Delivering basic documents through what are basically user-land operating systems (browsers) is overkill in every sense of the word: performance, security, accessibility, efficiency, etc.

What to do? The web is already on its march towards being an app platform. The next steps will be tough since Apple and Google also own the much more valuable mobile app ecosystems, and will try to protect them - but it's too late for the web now, the march is on. I think eventually there may need to be some sort of fork of the web to better satisfy both needs.

I'm doing something similar but less ephemeral. I have many web profiles, but they are dedicated, for example I have a Google profile where I open Gmail, drive, photos, etc. I have an FB one, a reddit one, an HN one, etc. About 15. Then Firefox for my regular browsing.

Interesting. Why disable gpu?

> Disables 3D APIs / WebGL, GPU acceleration by default while allowing them to be re-enabled through command-line switches.

These are the exact tools I am constantly looking for. Full browser sandbox for no stress "install", local-first, offline-first, so you own your own data - then option for locally encrypted cloud backups. I am almost 100% web now, I use very few installed programs and am constantly trying to get that to zero. One day someone is going to collect all these best-in-class web tools and make a proper chromebook where the user owns their own data.

> Storing a document in a URL is nifty, but not terribly practical. Hashify uses the [bit.ly API][4] to shorten URLs from as many as 30,000 characters to just 20 or so. In essence, bit.ly acts as a document store! [1]

bit.ly et al. seem to be able to get away with being agnostic processors. I'm surprised there haven't been more stories about their services being abused.

[1] https://hashify.me/IyBIYXNoaWZ5CgpIYXNoaWZ5IGRvZXMgbm90IHNvb...

All that's missing now is a ranking mechanism and commenting system.

What regulations advise screen reflectivity?

The problem is that easy queries are easy, who cares about orm, and hard ones are too hard for orm. I haven't been able to see the benefits in either easy or hard projects.

Dogs are 50% the joy at 5% the effort :p Not having kids is great too :D

Oddly Germany might be the single most productive country in the world?

> Then both teams meet to negotiate the "Contract"

What you describe is pretty much front-end first with the tweak that when the teams negotiate, the burden of proof lies on the back-end. The back-end should contort as much as possible to satisfy the needs of the front-end, allowing it to remain as clean and nimble as possible. Only when it matters should the back-end be able to materially affect the shape of the api. In most cases "mattering" means balancing the needs of this front-end with another that also consumes the back-end.

> Always define the API first

Impossible. What will the API serve? A list of horses? Wouldn't work if the user needs a mortgage calculator. There is no choice but to define the front-end first. The question is whether it's defined nebulously or with thought - it's rare for thoughtlessness to be the optimal strategy.

Do you remember any cool examples of an algorithm bazooka?

It looks a shade more detailed than google's recipe cards, they link back to the original source for the instructions, I would bet they didn't get permission, and that they count as a fair-use search engine. The law isn't (can't be) perfectly prescriptive here, there's some line that you have to sue about to know if it has been crossed.

Any recommendations for a js lib that does all the "easy" scraping (microdata, og tags, jsonld, etc)?

Scraping is LEGAL, all search engines scrape to some degree for example, there is a fair use component, so you can't "scrape" 100% of a site and stick it on your domain, but you can still scrape more than zero. In general it is leaning more acceptable than less.

For many sites this is an endorsement not to close tags.

> <meta name=viewport content="width=device-width, initial-scale=1">

> This snippet is copy and pasted a whole lot around the web. Most people don't explain how it actually functions though. "width" sets the initial width to the mobile's physical display width in 100% pixels.

I still don't get this - if the browser is the width of the device, why doesn't the site flow to 100% of the browser?

A hello world react app with everything you would typically need (redux, router, etc.) starts at 100K+. Svelte is a couple K.

A react app has massive abstraction to render on every frame, Svelte compiles out the framework to render instant straight vanilla js (wins all perf tests).

Pre-compiling allows for beautiful syntax and more flexible app structure, since you aren't limited to the runtime.

SSR and code-splitting are significantly easier and more straightforward.

React is designed for a billion-user site and it shows.

There really is zero cost to pre-compiling except mind-share, and only benefits. Of course an F100 company has many concerns above tech awesomeness, so no judgement on your selection criteria. But I assure you this movement is coming, react/vue/angular will adapt/change and/or people will move to Svelte-like solutions.

You can already see it happening in the article facebook released today [1]:

"By using rems, we can respect user-specified defaults and are able to provide controls for customizing font size without requiring changes to the stylesheet. Designs, however, are usually created using CSS pixel values. Manually converting to rems adds engineering overhead and the potential for bugs, so we have our build tool do this conversion for us."

[1] https://news.ycombinator.com/item?id=23116300

When the article mentions costs they mean in terms of performance for the user. Faster sites and better battery have been objectively shown to be material. Users don't know to vocalize it, but they bounce from fat slow sites.

It's about a 4 hr learning curve from react - but I'm not shilling svelte, just showing that there are already superior models. Pre-compiling is really objectively better in every way except popularity, and that will change because of its betterness.

Wait another year or two and your stakeholders will smarten up - users are noticing. Svelte JS, for example, has everything you listed minus the costs. React is very far from the end of the road.

I completely agree, especially when we redefine AI to mean roombas and lane assist.