TIL: You can access a user’s camera with just HTML
austingil.com
austingil.com
I hacked it together in half an hour to give people a way to look at the uninverted version of my inverted analogue photos with their phones at exhibitions. most people were more excited to play with it on their phone than by the photos I took days making. :'(
[edit oops this javascript ]
Edit, the second: Disregard. It's definitely a corporate middlebox on my end.
Edit: it doesn't help that the domain is `radioac.dev`. So *NEGA.R*adioc.dev
- your boss
https://developer.mozilla.org/en-US/docs/Web/CSS/filter-func...
Kudos to whoever made this free site and also the modern browser tech for making this possible.
It's cool because if you have an app that requires users uploading pictures, you just need an HTML <form>, an <input> with `capture`, and a few lines of code in the backend. I thought I would need to do some JavaScript gymnastics, and it ended up taking just an afternoon to design, develop, and deploy.
"It appears @capture is not supported and @accept is supported." for Safari, Firefox and Chrome on MacOS.
I see two buttons, Choose File and Upload. Upload is just a placeholder that shows a 405 error so I'll ignore that. Choose File just lets me choose a file, but there's no option to take a picture.
What am I missing here?
EDIT: nvm I see that it only works on mobile:
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
Didn't expect to have that easy access to TTS/Speech Synthesis.
https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_...
"twin=75 kill=75 twin=115 kill=115 lit=130 till=130 star=110 how=100 i=100 won=90 dur=90 what=85 you=80=2 are=70".split(" ").map(s=>{u=new SpeechSynthesisUtterance((t=s.split('='))[0]);u.pitch=parseInt(t[1]||100)/100;u.rate=parseFloat(t[2]??1.5);speechSynthesis.speak(u)})AFAIK, this feature is mobile only.
The state of the modern web is pretty incredible now. There really isn't any kind of application that I would feel uncomfortable building this way in 2022.
For me, native has evolved into pure overhead (unless you need to light up some shiny device-specific feature that will inevitably become deprecated within 2-3 years). I also understand those who believe their product's main selling point is that it exists as an offering in the various app stores. For us, we actually have a value proposition beyond "it has a native app icon".
If I had to attribute my confidence in the web to any one specific aspect, it would have to be CSS grid by a very wide margin. Realizing that I could achieve the exact layout I want on any range of viewport without having to pull down a 3rd party dependency was a huge step for me.
The mindset of developers is what it is because the requirements demand so.
And let's not pretent that users are ever given a choice in the quality vs. cost tradeoff except for looking for a different program entirely. And even that is often not an option because the software needs to interact with systems that are actively hostile towards third-party clients.
We shouldn't excuse mediocre software just because the market puts up with mediocrity.
The market has stopped putting up with mediocre software and chose higher-quality alternatives. The one thing that is not obvious to developers is that the market considers faster software with less features, hard crashes and limited portability as much worse than the web-based alternatives.
With html + js, we're able to deliver a great user experience in a fraction of the time.
Also, the desktop bundlers are getting better over time.
1) Users don't want to deal with installation.
2) New developers are attracted towards the least steep difficulty incline -- learn HTML first, then some CSS, then some JS. At each stage you can do something visible and useful, and the next step is within your grasp.
3) Most investment goes towards companies adding value to the web, and companies that do that will tend to use web technologies first.
I think crashes have very little do with it. In my experience web apps have just as many stability problems and broken features. Also important that #2 means that developers that can work on systems where web solutions can't work (things that really need C++ because of realtime requirements) are paid a substantial premium. So the market has also decided the people who can do native well are more valuable.
That is definitely one of the top selling points for web-based solutions, agreed.
> 2) ... At each stage you can do something visible and useful
BTW is this still true in 2022? My totally out-of-nothing guess would be that SAAS offerings and website builders have made people with HTML + minimal JS knowledge next to useless.
> 3) Most investment goes towards companies adding value to the web, and companies that do that will tend to use web technologies first.
OTOH, I have been involved in a project where the web was found to be superior to the alternatives. It does have to do a lot with (no) installation, though. A related project, OTOH, is moving their UI from Swing to the Browser. While this is just the UI, the remaining code was written in Java, not native.
I think I do agree with the claims as long as Java/C#/similar get added to the "native" side of the argument, because I really see them eating C/C++'s lunch, and this is only going to accelerate with Java becoming more and more independent of a separate JVM installation.
> Also important that #2 means that developers that can work on systems where web solutions can't work (things that really need C++ because of realtime requirements) are paid a substantial premium
I haven't found this to be true, but my experience is limited, and it probably depends on country / region.
Any laptop sold in the last 10+ years?
I would never make a connection from a public Domain to my local machine just to test something. It's just too risky.
I want to know if he had any reason to do so.
Why do that when you can duct tape an old phone to the window lol
Why waste an old phone?
...why is a markup language for hypertext able to control my device's camera? Why have all the relevant standards bodies associated with this language and protocol gotten on board with turning a markup display language into a full-blown OS?
The alternative to standards is every browser vendor doing their own thing, and "this website only works on IE". Remember the bad old days of the web where every bank required Windows because their UI was implemented with ActiveX? Standards killed that and now you can view your bank account on Linux.
WebRTC has its security downsides, but probably better than running a binary from the Chinese government as root so you can video call someone.
Not really, webdev is a pain just as much as making a native Windows app or Go binary. Programming is bullshit all the way down. The moment you try to do anything correct in absolutely any modern software stack or framework, you will have to do a bunch of hacks to indirectly force stuff into doing what's needed for your program to be correct. Of course in practice everyone just skips this part, contributing to the said problem.
> Standards killed that and now you can view your bank account on Linux.
But I literally can't view certain bank websites with Firefox.
I didn't mean to imply it was easier for the programmer. It's harder! But it's easier for the end user. Click link, app loads. Next best thing to being bundled with the OS.
Regarding the web becoming its own OS.. there is no easier way to make cross platform applications these days. If every OS vendor could agree on some standard desktop API, there would be a lot more native apps.
Why wouldn't we want to be able to do useful things on the web with our devices?
Contrast this with where we were in the bad old days: sites used things like plugins or Flash/Silverlight which had massive attack surfaces and, for years, inadequate privacy controls or sandboxing. Part of why this is in the browser now is that the browser developers realized that things were never going to get better if they left it to the disinterested developers at companies like Adobe, and now that's just a “can you believe we used to think this was normal?” historical trivia point.
> Contrast this with where we were in the bad old days
In the "bad old days", you could decide not to install plugins, choose which ones to install, etc. You could customize the attack surface you're willing to present. That ability is seriously constrained now.
Understand that my complaint is about web browsers allowing websites to do these things. In effect, it's allowing any random website to have the power of a natively installed application. This is a bad thing in my view because with native applications, I could decide which ones were and were not acceptable to me. That's extremely difficult now that the browser gives that power to every website.
No, it can't. It's an HTML attribute which enables some mobile browser UI around the standard <input type=file> behaviour. The only thing it allows for tracking is whether your browser supports that attribute, which narrows it down to about 60% of the browsers in the world:
https://caniuse.com/html-media-capture
The only way you're breaking that is if you have the kind of exploit which could break just about anything and in that case the argument would be more along the lines of “we should remove JavaScript entirely” since that's been a source of orders of magnitude more security problems.
> In the "bad old days", you could decide not to install plugins, choose which ones to install, etc. You could customize the attack surface you're willing to present. That ability is seriously constrained now.
Your choice was to enable a massive operating system-scale level of functionality in Flash/Silverlight or not be able to use many popular sites. Since those plugins were managed separately from the browser they did not follow the same secure development practices or sandboxing which the browsers were using, and many users either did not update them or did so on a schedule far slower than the update schedule Chrome or Firefox kept.
> In effect, it's allowing any random website to have the power of a natively installed application.
… with complete user control. That's exactly what you say you want in the next sentence and it's far better from a security perspective because trusting a browser's sandbox is a lot easier to evaluate than having to individually review every native application you install. Installing native applications should be seen as a relatively rare activity because they expose you to more risk and are harder to evaluate.
I wasn't talking about this particular ability. I was talking about the risk of browsers being effectively operating systems in their own right. That puts me in an untenable position -- I have to determine the safety of every web site, which is a thing that is effectively impossible to do.
> with complete user control.
Not even close. I have to install and use several addons in order to muster a somewhat reasonable amount of control. And even then, the control I have is far from "complete".
> it's far better from a security perspective because trusting a browser's sandbox is a lot easier to evaluate than having to individually review every native application you install.
It's certainly easier to "trust the sandbox", except that the sandbox allows far too much nefarious activity in order to be able to trust it.
Modern web browsers are inherently problematic because of the combination of presenting powerful abilities to websites, and that it's impossible to know if a website is using those abilities responsibly (and most -- especially large commercial websites -- aren't, as near as I can tell).
> Not even close. I have to install and use several addons in order to muster a somewhat reasonable amount of control. And even then, the control I have is far from "complete".
You have per-site authorization for each different feature, and those can be one-time, ongoing, one prompt per day, etc. Now, yes, I'm sure you can come up with some policy like “I want to only allow camera access when I'm holding down the left meta key” but it's important to remember that the alternative is people downloading and running native code. Do you really think that's going to be _better_ than a modern browser?
> Modern web browsers are inherently problematic because of the combination of presenting powerful abilities to websites, and that it's impossible to know if a website is using those abilities responsibly (and most -- especially large commercial websites -- aren't, as near as I can tell).
The browsers fully disclose when something is being used. You can't tell what they do with the data but that would be the case in any alternative model and I trust the browser UI a lot more than a prompt which that company implemented in their own app.
It's nice that we have a portable app platform now, but I really wish that would be a separate thing from the document centric Web, which slowly but surely is getting killed and replaced by a bunch of always-online apps.
I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML.
Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML.
That's not HTML though. That's not even really browsers and JavaScript. It's just Google and Chrome, and even then it's mainly there so it's available in ChromeOS more than the Chrome-the-browser. They just happen to share the same 'engine'. A random webpage is not hax0ring your bluetooth devices. They're very tightly coupled, so sometimes it's hard to see where one stops and the other begins, but Web Bluetooth has nothing to do with HTML. You only need look at the compatibility chart to see that - https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...
If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward. You can't bookmark a scroll position either and neither can you link it. If you split the document into multiple HTML files, you complete break the ability to search across the whole document. Performance also breaks down with long form documents.
There is of course .epub, which fixes some of those short comings, but epub is not part of the Web, not supported by any browser and requires a separate app. So it really doesn't fix the fundamental problems either.
There is also 'link rel=next/prev' that in theory would allow working around some of those issues as well, but that hasn't been supported in any browser as far as I know.
If HTML would be any good at handling documents we wouldn't still be using PDF all the time.
This isn't true on any popular browser or platform. Single-page scrolling using the keyboard, mouse, or touchscreen is built-in for all common browsers and scrolling even extremely large documents has been fine for at least a decade – unless you load it up with tons of JavaScript even in the ranges of thousands of pages will be at least as snappy as a PDF.
> You can't bookmark a scroll position either and neither can you link it.
You can't, and also wouldn't want to since that's inherently unstable (e.g. I resize the window slightly and all of the links break). What you can do is what people have been doing since around 1993 and put anchors on logical sections, paragraphs, etc. so you have a linkable stable anchor which doesn't depend on the window or font size.
Except there is no way to expose such anchors to the user without cluttering up the display. Giving users the option to create a bookmark to the nearest id-ed element + offset (perhaps with extensions to let the website specify which elements to consider) is an example of document support that is missing from browsers.
Chrome does have an extension to bookmark text fragments: https://support.google.com/chrome/answer/10256233?hl=en&co=G... Something like this should be standardized and also include a nearby ID to help find the location when the text changes.
Most pages also don't change that significantly/often and if they do they can just disappear entirely so anchor links aren't that stable either. Most browsers already do remember your scroll position when you refresh the page because even if it sometimes gets you to a different part becaus the preceding content changed it is still useful most of the time.
> Except there is no way to expose such anchors to the user without cluttering up the display.
1. Using unobtrusive anchors isn't that bad as far as clutter goes — if you have a discrete octothorpe or paragraph symbol consistently at the start or end of a paragraph it's not the end of the world, especially if they're styled to be in the margin outside of normal text flow.
2. Since approximately late 1995, people have used JavaScript to only display those symbols on hover/focus. This works well and is pretty common around the web.
I'm not saying that there isn't room for improvement such as Chrome's extension but when there's 3 decades of common usage for something you say can't be done it suggests that the probably isn't that it's impossible but that there isn't enough social pressure to make publishers _want_ to publish books as HTML. Examples of massive documents are easy enough to find (e.g. W3C specs) so I'd prefer to spend time thinking about why other people aren't (e.g. DRM) and what you can do about the real problems.
There's nothing stopping browser vendors solving the problems you're talking about but then you'll probably worry that browsers are becoming operating systems or something.
Bookmarks are entirely part of the browser UI. They're an entry in a database of URLs that the browser presents to the user, and when the user clicks on one it tells the browser to navigate to that address. There is absolutely no HTML involved.
Because the web is for hypertext, which means static content. Images, text, video and audio clips, tables, code snippets, etc. Of course even that subset it does unimaginably bad, okay? Interactive web apps fucking suck, so that takes care of that 50%. For the other 50%, which is document viewing, why in the hell would I want pages to be able to move stuff around and create their own custom UIs and color schemes for every document I view? That use case is for magazines, a content-free medium. It's actually hilarious how people think hosting their library documentation on some stupid website like readthedocs.io, or publishing scientific journals behind IP blocklists (aka misconfigured bullshit from some charlatan sysadmin) is "progress".
Thats what hypertext meant originally but it's evolved and moved on. The spec is literally called "HTML The Living Standard". You don't get to claim it's fixed and can't change. It just isn't.
HTML has been a victim of ridiculous amounts of creep, to the detriment of growth. Creating static web content isn't really easier or cleaner now than it was in the 90s, but the protocol DOES now permit the remote end to interrogate your computer for almost as much info as the freakin' SysInternals suite.
What makes you think web apps can't enable exploits that compromise your system? Anything that can run code on your machine enables attacks. Even Javascript that gets run in browsers have enabled attacks on the local system.
If anything web apps decrease your security since a binary can be vetted and verified as unchanged, but when you open a web app you're at the mercy of whatever it is and does in that moment.
web apps also have access to the file system, although there are extra steps
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
Here's a shell! https://rreverser.com/webassembly-shell-with-a-real-filesyst...
Webassembly is overwhelmingly used for malware (https://www.crowdstrike.com/blog/ecriminals-increasingly-use...) but at least it's usually just mining cryptocurrency. I'd guess it's only a matter of time before it's commonly used for much worse.
Slightly tangent, but it seems like more services are no longer offering fallbacks. Twitter recently got rid of its tweet text fallback, and the caniusewidgets doesn't offer a png fallback (at first glance). https://github.com/badges/shields uses svg so you can do this without complaining about bandwidth too.
Would be funny to include this in an article about yet another privacy-breaking feature of web.
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
If you care about desktop users at all, you can't use this, except in a mobile-only version of your site or application.
Secure Context seems (coupled with the permission check) like it's an appropriate requirement here but I didn't see whether it's actually enforced, and obviously as an HTML attribute rather than say a Javascript API it might have been forgotten.
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
If it's acceptable to send the picture as a file upload over http then i see no reason why it wouldn't be acceptable to send a webcam captured picture.
Why do you think it should or would?
It does make me more than a bit sad how the web is bifurcating between mobile & desktop. We keep justifying it to ourselves, saying, yeah, that's not as important on desktop, and nit implementing. This pile of discrepancies built by non-implementations keeps growing though & it's not cool. Web Share & Web Share Target not being on desktop is another mobile only example, of more tech that's just good for PWA's in general/everywhere.
>> Check back later once traffic has gone down.
For personal fun and learning, I'm making a complete 2D video game in ideally less than 1MB. It has 60fps graphics, full spatial audio, and gamepad support, all because the browser has a lot of these APIs that didn't exist when I was starting out my career. The only issue I'm having so far with the user experience is the desire to assume complete control of your keyboard the way a traditional PC game would, because browsers really don't want you to own _every_ key.
Wouldn't be really a sandbox anymore if they could
Some interesting ones:
- Screen recording/capture
- Battery status
- Barcode Detection
- Bluetooth
- Sensors (e.g. Accelerometer)
- Wake/screen lock
- Color picker
- Vibration
- MIDI
- USB
- Contacts picker
- Presentation (AirPlay, Chromecast)
- Virtual reality
I'm amazed at how quickly I can throw together a front end feature in JavaScript on my otherwise html site.
Really all of web impressed me over the desktop/app counterparts. I wrote and read to/from a php database with less than 2 hours of time. Laravel has me doing user authentication + useful coding in less than 40 hours after the tutorial.
No permissions required.
I had issues as recent as last year's new products.
But otherwise I love the concept of hardware access with HTML. The embedded guy in me thinks the future is going to be crazy. I can't quite wrap my head around the possibilities.
I also keep Bluetooth disabled on my mobile devices. It's used extensively to ID and track people and their devices. For things that don't move and are only ever paired to a single thing (like a speaker) it works fine. Most of the complaints I hear about bluetooth are from people who pair multiple devices to a single source and want to easily switch between them.
I wish there was something similar for but for modern browsers, taking advantage of HTML5 and all the browser API's available now which previously required a plugin like adobe flash.
As you mentioned the API's and capabilities are there, built right into the browsers now. I just wish the tooling was better.
Any time I've tried to use WebGL... pain.
Same.
My latest project is a waveform generator for wavetable synthesizers [1]; there are visualizations, as well as handling audio (not real time but still). I was surprised that I could build that as a web app and achieve good UX and performance.
And your domain is really cool too. I presume it’s like a self deprecating math joke.
The .xyz pun was not intended, but it does make a lot of sense for a math related app. Thanks for spotting that too!
- Very hard for me to find the play button.. took like 10s of looking. I looked at the segment buttons
- Accidentally, I got some really cool sounds by mashing the play button to overlay it. Not sure why it gets distorted if it should be playing the same waves. But it sounds cool
DDG search does not help much [1], [2]
Any pointers ?
1: https://duckduckgo.com/?q=waveform+generator+for+wavetable+s...
And also doing this declaratively makes it so much easier to secure & build well-thought-out privacy & consent UX around.
An imperative API has so many variations on implementation approach for the end-developer / API consumer that the combinatorics become much more challenging for browser implementers.
(obviously imperative APIs for doing this already exist, but the existence of this declarative API at least makes limiting imperative API access less draconian/severe as a measure).
Other than that... I'm not sure even I'd want to allow a webpage to do that.
I have made a web editor that uses this. There is an example pwa app Https://webide se/
The fact that the browser is also heavily sandboxed is another big benefit. I personally feel safer using a web app than a native app on any device, any day. You just don't know what a native app might be doing in the background, but with a web app, I feel things are much more transparent.
I can potentially see a future where you could deploy docker-like containers directly from the browser, while keeping the same fine grained controls that a browser allows. Then it really would make the web a truly flexible, infrastructure agnostic application delivery platform.
First, it was cross-platform UI toolkits and OS abstractions like Qt (require users to use a big, "lowest common denominator compromise" library )
Then, it was web apps (require users to provide a browser)
Then, it was Electron and friends (ship the whole browser with the application)
Then, Docker and containers (ship the whole OS with the application)
Where do we go from here? Ship an entire physical PC to the user pre-loaded with the application? We keep trading away the end user's resources and convenience to gain developer's time and resources. All to keep (badly) solving the "Well, it works on my computer" class of problems.
Ironically, that’s essentially what IBM did with mainframes.
Another example of what’s old is new again.
Nowadays they are mainly meant as machines with extreme reliability guarantees, from things like running multiple processors in lockstep to detect spontaneous processor errors, but they're still just computers.
While their cost makes them hugely impractical for .øst usecases, mainframes do have some really cool tech, including their new CPU designs with quite interesting cache layouts.
The software came pre-loaded with the hardware, and IBM shipped it to you and set it up for you. You couldn't buy an app without paying for the hardware. Technically, you rented everything from IBM, and paid one lease price.
I'm going to guess that there will be a few intermediate steps, with the additional goal of removing rights to your own computer.
After Docker and containers, an image for a virtual machine, to provide a kernel and not just the libraries.
After virtual machines, a connection to a remote machine, to avoid downloading the entire image and reduce your first-use bandwidth.
After connections to remote machines, a "co-located server", with an abstraction layer between using the remote machine to reduce first-use bandwidth and using the machine in your house to reduce latency.
Which is all to say that I wouldn't be surprised if it happened that way over the next 10-20 years, resulting in you renting the computer that sits in your own house.
A phone (hi iOS), a video game console, a smart appliance, etc. are examples of this.
Building cross platform, native applications is expensive (comparatively) to building web applications.
I made an FM synthesizer in the browser using WASM and the webaudio api just for personal use. I wouldn't have made it if I had to write it as a native app, because native apps are a time sink and annoyance to me (I mean, I'm on linux anyways. I probably have to use either GTK or QT anyways!!!)
Demand for software is MASSIVE right now, and making shipping easier, even if the end product isn't as fast, does have value.
Though yeah, I wish Slack was faster too.
Related to this: iirc, games for the Xbox One (and presumable the latest generation 'Series' consoles) always run in a VM, with their own kernel and graphics drivers.
Maybe not that, but it’s becoming popular to run high-intensity programs on a remote server and stream video to the user’s machine, both for pretty sensible reasons (e.g. Stadia for games) and totally nonsensical ones (e.g. Mighty for Google Chrome). It’s mainframes all over again!
Instead, the industry as a whole hands out more "productive" tools, i.e., the abstraction layers you mentioned, in order to build ever more trivial applications (that don't work properly in most of the cases anyways).
I think that we're in a downwards spiral at this point: Business doesn't make enough money per line of code to hire or train really good engineers. Tries to push out more software, resulting in more crap. Software quality sinks. Business makes even less money per line of code. Engineers throw the towel and are replaced by less experienced people. Rinse and repeat.
The 1% where I don't agree: most developers aren't engineers. These days companies hire engineers for stuff that is hard and important. But most do not need that.
And my impression is that that is a good thing. There's been a real democratization of development which means there's a lot of software being written. Most applications I see are fundamentally CRUD apps, and while I'm a bit fearful of the security of the banking apps, the massive frameworks are at least designed (implicitly at least) to reduce complexity and steer people towards some "best practices". Any kid today can build something that only a couple of decades ago (or less) really did need serious engineering.
We've followed the same path before. Rich people used to hire chauffeurs who didn't just drive but performed maintenance on the cars. Then people knew how to change tyres, gap their spark plugs etc. Now people know how to turn the key and steer around the road, hopefully not killing too many people in the process. Next, they'll only need to know how to step into the vehicle.
We should be glad software is going that way. It's not like that will reduce employment for engineers.
> I think that we're in a downwards spiral at this point
I'm mainly writing a reply just to say: I have huge hope we're on an great upward ascent & have made things increasingly better.
> IMO, the reason is, to a large degree, ineptness of software engineers.
I sometimes encounter less than optimal code or solutions, but the amount of times that it matters is unbelievably little. Focusing on really good engineers making really excellent decisions is, not, to me, a critical issue in most places. I think there's a lot of value in just finding the budget to support open source engineers, in trying to support good community efforts, like Web Incubation specs, like Bytecode Alliance. Time & care, about doing good things for community, over time, is the incomparable advantage, is the prime requirement of turning acceptable/passable/maybe-a-little-defect-y code into something that really works well & serves & is/has-become enduring.
> Instead, the industry as a whole hands out more "productive" tools, i.e., the abstraction layers you mentioned,
I see so little harm to using the good, well embraced, ultra productive, mid-industrial toolset we've grown into. And I see so little benefit to trying to go any other way. We should respect resource consumption, and some apps (webapp and native both) do bad jobs, but the layers mentioned seem like a vanish point of concern, far far far down where I think computing needs to be dwelling & caring & trying to do better. There's so few examples that there are real gains to be made from abandoning the layers we have; efforts like react-native show we can do basically the same high-production technioques at a native layer, but the rewards for doing it native have almost never materialized; just using the web stack continues to be good.
I think there are far more productive things to be debating & discussing, as we decide where to orient ourselves & the next steps of computing to. Worrying about these stacks has infected too much of the online discourse time spent, has become a mind-virus.
Hmm, software engineers? IMO the culprits are "greedy" managers who didn't like (and still don't like) common libraries, file systems etc. Motto: "It must be my standard, or else ..." Where's the common (license free and secure, encryptable) standardised file system, to exchange data between all platforms, including digital cameras and other gadgets? Where's the graphics API? Java tried to answer some of these questions, but failed miserably IMHO.
My experience: as soon as I learned to use some API or framework, at least two new APIs or frameworks showed up posing as the best thing since sliced bread. Sorry for the sarcasm, but I lost my optimism regarding software development some years ago.
Believe it or not, I've done this, and I have to maintain a small fleet of them now. The software in question functions as a server/database for a mobile app that's only used by employees on a given job site. It was deployed before Docker was a thing.
I don't want to have to code the project in multiple native languages, and likely wouldn't be able to without massive amounts of time learning each language.
Similarly I want access to native APIs, some of which browsers don't have. And I don't want to run a website to host my app.
I'm currently learning dart/flutter due to this. IMO it is the answer. You may disagree.
𝚃̶𝚘̶ ̶𝚋̶𝚎̶ ̶𝚏̶𝚊̶𝚒̶𝚛̶,̶ ̶𝚝̶𝚑̶𝚊̶𝚝̶'̶𝚜̶ ̶𝚜̶𝚑̶𝚒̶𝚙̶𝚙̶𝚒̶𝚗̶𝚐̶ ̶𝚝̶𝚑̶𝚎̶ ̶̶𝚔̶𝚎̶𝚛̶𝚗̶𝚎̶𝚕̶̶ ̶𝚊̶𝚗̶𝚍̶ ̶𝚗̶𝚎̶𝚎̶𝚍̶𝚎̶𝚍̶ ̶𝚙̶𝚊̶𝚌̶𝚔̶𝚊̶𝚐̶𝚎̶𝚜̶ ̶𝚠̶𝚒̶𝚝̶𝚑̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚊̶𝚙̶𝚙̶𝚕̶𝚒̶𝚌̶𝚊̶𝚝̶𝚒̶𝚘̶𝚗̶.̶ ̶ ̶𝚃̶𝚑̶𝚊̶𝚝̶'̶𝚜̶ ̶𝚙̶𝚎̶𝚍̶𝚊̶𝚗̶𝚝̶𝚒̶𝚌̶,̶ ̶𝙸̶ ̶𝚔̶𝚗̶𝚘̶𝚠̶,̶ ̶𝚊̶𝚗̶𝚍̶ ̶𝚠̶𝚑̶𝚒̶𝚕̶𝚎̶ ̶𝚠̶𝚑̶𝚊̶𝚝̶ ̶𝚢̶𝚘̶𝚞̶ ̶𝚜̶𝚊̶𝚒̶𝚍̶ ̶𝚒̶𝚜̶ ̶̶𝚝̶𝚎̶𝚌̶𝚑̶𝚗̶𝚒̶𝚌̶𝚊̶𝚕̶𝚕̶𝚢̶̶ ̶𝚝̶𝚛̶𝚞̶𝚎̶,̶ ̶𝚛̶𝚎̶𝚖̶𝚘̶𝚟̶𝚒̶𝚗̶𝚐̶ ̶𝚘̶𝚗̶𝚎̶ ̶𝚕̶𝚎̶𝚟̶𝚎̶𝚕̶ ̶𝚘̶𝚏̶ ̶𝚊̶𝚋̶𝚜̶𝚝̶𝚛̶𝚊̶𝚌̶𝚝̶𝚒̶𝚘̶𝚗̶ ̶𝚏̶𝚛̶𝚘̶𝚖̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚍̶𝚎̶𝚜̶𝚌̶𝚛̶𝚒̶𝚙̶𝚝̶𝚒̶𝚘̶𝚗̶ ̶𝚛̶𝚎̶𝚊̶𝚕̶𝚕̶𝚢̶ ̶𝚌̶𝚑̶𝚊̶𝚗̶𝚐̶𝚎̶𝚜̶ ̶𝚝̶𝚑̶𝚎̶ ̶𝚖̶𝚎̶𝚊̶𝚗̶𝚒̶𝚗̶𝚐̶ ̶𝚜̶𝚒̶𝚐̶𝚗̶𝚒̶𝚏̶𝚒̶𝚌̶𝚊̶𝚗̶𝚝̶𝚕̶𝚢̶.̶ ̶ ̶𝚃̶𝚑̶𝚎̶ ̶𝙻̶𝚒̶𝚗̶𝚞̶𝚡̶ ̶𝚔̶𝚎̶𝚛̶𝚗̶𝚎̶𝚕̶ ̶𝚘̶𝚗̶ ̶𝚒̶𝚝̶𝚜̶ ̶𝚘̶𝚠̶𝚗̶ ̶𝚒̶𝚜̶ ̶𝚜̶𝚘̶𝚖̶𝚎̶𝚝̶𝚑̶𝚒̶𝚗̶𝚐̶ ̶𝚕̶𝚒̶𝚔̶𝚎̶ ̶𝟷̶𝟶̶ ̶𝚖̶𝚎̶𝚐̶𝚊̶𝚋̶𝚢̶𝚝̶𝚎̶𝚜̶.̶
EDIT: What I've said is not exactly correct. If you're not running Docker on a Linux host, then you'll have a Linux kernel running in emulation but it's not shipping with containers. Not sure what I was thinking. I believe this is closer to the truth.
Reciprocally, on the server, there's definitely traction strong traction with webassembly being the de-facto platform for glue/extensions/user-code, owing to it's super sandboxing & capability systems like WASI. Being able to take any langauge, compile to wasm, and distribute & safely run that module has been a huge upgrade, and a very nice bit of platform that historically wasn't really available/commonplace on "native".
Your issue with "Electron and friends" is wrong. As you say, Electron does at present bundle a whole browser in each app. But many "friends" have new approaches. Tauri recently went 1.0, and generally builds off the already available WebView that all major OSes include[2]. I'd be interested to see what kind of fear/concern you'd present if Electron also had a more respectful shared-library usage-pattern.
[1] "Writing an App is Like Coding for Laserdisc" https://shkspr.mobi/blog/2022/09/writing-an-app-is-like-codi... https://news.ycombinator.com/item?id=32723192 (153 points, 1d ago, 184 comments)
[2] "Tauri [1.0] - Electron alternative written in rust" https://news.ycombinator.com/item?id=29807022 (558 points, 8mo ago, 419comments)
And sadly it will get more complicated over time.
I just figured that at some point we should start over with a very simple sandbox that allows to run all the webgl renderers, javascript interpreters, css parsers, and whatnot, inside it. This simple sandbox would also be more secure, because of its simplicity.
This is an optimistic take on the near- and mid-term evolution of software. What makes you think that working inside the browser will stop wheel reinvention? Have you not tracked the endless reinvention of "the right way" to do interactive app development inside the browser?
The modern web drives obsolescence second only to gaming, but while gaming is user driven and entertainment focused (i.e. not essential), the web is megacorp driven and also includes necessary modern infrastructure.
That is all around a bad thing.
The web is the closest thing there is to a ubiquitous operating system. And with the development around WASM, performance and efficiency is getting closer and closer to native. That's along with built-in security and sandboxing.
This is all around a good thing.
One of the best things about NIH-ing my own engine is that I don't need to make it generic, meaning one less layer of abstraction to complicate implementation and debugging.
My worry is basically that the absent functionality is the best thing about the web as a user. Take the notification API: One of the nice things about web pages and apps is that they stop bothering me once I close them; not so if I accidentally permit notifications! Fortunately I can turn that whole feature off, but at first I found myself wondering who ever thought that would be a good idea.
Yes I picked an extreme example, and I don't actually mind some of these things. I wish there were a permission pop-up before playing sound at all. Also, WebGL does concern me, since heavy GPU usage can draw a lot of power. Things like gamepad support and spatial audio (if they are behind permission pop-ups) don't really bother me, though.
> I wish there were a permission pop-up before playing sound at all
The browser can't actually play sound unless 1) it's triggered as the result of a user action (such as a mouse click) or 2) if you've often listened to sound on that page in the past.
Re: sound, "Triggered as the result of a user action" is not a high enough bar.
And the chat app, and the email app, and the social media app (other opinions about social media notwithstanding). I think each of these things have their own legitimate use for notifications.
I guess it's the point of "weakening a primary advantage". I don't see how it's weakened (or rather, I don't see how it's a problem) when the notifications are on a per site permission. Especially so when the notifications can be turned off completely per browser.
> Re: sound, "Triggered as the result of a user action" is not a high enough bar.
I'm with you on this. Although it took until this thread for me to realize that sound at all should be a permission.
The point is that a click should not give the website permission to play audio - that should be handled much explicitly and not just the user selecting text or some other interaction. Besides, last time I checked Firefox still let AudioContext play sound without any user interaction even though the <audio> element has more restrictions. Which is another problem: the HTML + JS spec is too bloated to properly secure things.
if you don't like it turn it off. arguing that things shouldn't exist just because you choose not to use them is pretty selfish.
[0]- With only anecdotes supporting my suspicion; I haven't done a rigorous study.
The thing I like about it is what you just said.
For me the big thing holding it back is IndexedDB.
Actually in the process of designing a software solution that needs to work on desktop and mobile, and be able to write mission critical data while offline.
As much as I'd love to just make one responsive web app - I just can't trust the safari or even chrome browsers to not /dev/null users data if it feels like it.
And that's much better than Apps, where you are forced into an unfavorable ecosystem.
The underlying technology is terrible. HTML and CSS are for displaying documents. Things which should be trivial to add to an application UI (add a ListView, anchor element X to be left of element Y, etc) are nigh impossible without using some bloated toolkit anyway. JS is a slow and brittle language to work with.
The fact that the web became an application delivery platform is an unfortunate historical accident that I am not sure we can recover from.
If we devoted 10% of the engineering that went into "web technology" into an actual dedicated cross platform application platform, it would be way better than the web is today. Faster, less bloat, better technology so that we don't need frameworks on frameworks to do a hello world, etc.
Unfortunately what's convenient for you as a developer is more often than not hostile and awful UX for me as a user.
Too often, developer convenience trumps good UX.
TIL you shouldn't run a blog on Cloudflare Workers due to rate limiting.
Given this is a blog, a better solution would've been Cloudflare Pages[1], which is their own static site hosting service and provides unlimited requests/bandwidth for free.
0: https://developers.cloudflare.com/workers/platform/pricing/