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. :'(
Note that this uses the JavaScript MediaDevices API to stream the camera, which is different from OP's link (which is a file picker input that launches the mobile camera instead of going to the photo gallery)
fortinet is a cyber security software company, that makes a product called fortigate that does SSL MITM to decrypt and monitor/filter your traffic. Probably want to poke your IT team or get very concerned about your ISP...
Maybe you're behind a firewall with some filtering, and it doesn't like the domain name or something? browsers treat '.dev' domains a bit more strictly than the norm, so the browser doesn't like the redirect?? that's just my guess sorry.
Nah. It's in the Fortiguard category "Newly Observed Domain". So, it hasn't been classified yet, and that person's corporate filter was setup to block those pages.
Another view of it: Someone in Management sent a message something like "Stop pointing me to the Scunthorpe Problem wikipedia page[1], just block all these sites" directive and this was the easiest way to resolve it permanently.
I'm always too lazy to make an online gallery, and I don't want HN knowing my instagram. But I just made a few snaps of what I had around and put them here. https://golden-taffy-476b64.netlify.app/photos_m/
Another cool website that I came across a few days ago is https://vdo.ninja/ (create reusable invite option) which also uses the HTML camera APIs to connect your mobile phone to OBS. Both the audio and video quality I get from my phone is at par or sometimes even superior to my laptop's webcam. This video tutorial(1) explains the setup really well.
Kudos to whoever made this free site and also the modern browser tech for making this possible.
VDO Ninja is great. I've used it to stream on Twitch with a friend, so that each of us could have a live video capture in the Twitch stream. (The main streamer uses OBS, added a browser source pointing to a VDO Ninja room, and then the other person joins the VDO Ninja room and streams their own video feed into it.)
HTML media capture is superb. I have successfully used it in production, and I was surprised by how simple it was and how well it worked. I learned about it from here[0].
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.
This and the Web Speech API were quite unexpected things to discover lately. Even quite robust browser support, besides speech recognition missing on Firefox.
Didn't expect to have that easy access to TTS/Speech Synthesis.
I suspect we're still waiting on Firefox's multi-language speech database in Common Voice to get processed into some useful offline learning models. We can't be that far away from a googleless speech input world.
We've been using this approach for a long time in a B2B setting. The fallback to a file picker is really elegant for our use cases wherein some users operate on an old-school desktop PC rather than a mobile device.
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.
This mindset is exactly why we all have to suffer with slugish electron apps and bloated websites instead of using fast, native apps written in something like Qt.
The actual reason is that nobody (probably not even you) wants to pay the substantially higher price of developing native apps, nor do they want the suffer the loads of crash bugs that inevitably come with using lower-level technology.
The mindset of developers is what it is because the requirements demand so.
Oh please, "loads of crash bugs" are not and were never inevitable. And for the user experience, an exception that prevents you from doing what you want is not even that much better than a hard crash.
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.
> 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.
I think this is the wrong take away. The market made a few specific decisions:
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.
I feel like the default file input behavior is more user-friendly. Giving the user a choice between taking a new photo or uploading an existing one just seems way more flexible, and this is already how the file input works without the `capture` attribute.
I can't get over the fact, that he is using "a public internet URL" to tunnel the traffic to his local server, just to watch it on his phone.
What he should have done:
- Make his local server listen on his local ip like <<local-lan-ip>>:3000 instead of just 127.0.0.1:3000
- Connect his cellphone to his local lan with wifi.
- Look at the site on <<local-lan-ip>>:3000 on his cellphone.
I would never make a connection from a public Domain to my local machine just to test something. It's just too risky.
Actually a pity it doesn't work on the non-mobile; many of my computers have webcams now and it is kinda convenient to have this (and of course, you ought to always be able to bypass the camera as a user. really perhaps it should be part of the file picker itself but lol those things are so overloaded already)
Did you by chance click the JavaScript demo that totetsu posted? That demo uses the JavaScript MediaDevices API to stream the camera, which is different than the original post that is a file picker that opens the camera on mobile.
Not the same but for a more pro approach and allowing to stream to a RTSP Server I use LARIX Broadcaster, which is both available on android and iOS and it's just superb to turn an old phone into a camera, ofc you'd need an other software to actually detect movement and such from the RTSP feed. Scrypted can do that (for example)
I have, but limited usage. Just for monitoring the dogs when I'd run to the store or something. I've had it bookmarked for years in the event one day I needed it for something.
...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?
This is exactly what you’re implicitly asking for: deferring functionality to the OS. It doesn’t give the browser access to your camera (despite the title), it allows the browser to facilitate uploading a file produced by the camera. To the browser it’s no different than any other file input, which was standardized in HTML 3.0. To the OS, it’s not meaningfully different from opening a file picker dialog. To the user, it requires direct interaction to invoke, and while it can be abused it has the same limitations as any other file input, i.e. nothing is uploaded without further affirmative action by the user. This is much better than the JS standards which give sites the power to request interactive access to the camera (after asking permission).
It's not really controlling the camera. You need the JavaScript MediaDevices API for that. It just launches the mobile camera and requests that you take a picture, and the picture of never returned to the site until you confirm it. (Similar to any app that shows the "Take a Picture" or "Choose from Gallery" dialog when uploading an image. That is actually the default if you don't specify that the photo should come from the filesystem or camera)
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.
I find it incredible that people still think HTML, a spec first published in 1990 when we were using 386s with CGA monitors, shouldn't have evolved to utilise some of the modern features available on today's computers and phones.
Why wouldn't we want to be able to do useful things on the web with our devices?
There is nothing wrong with HTML evolving, the problem is that it has evolved in the completely wrong direction. HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support). Instead it can talk to my Bluetooth devices and my camera. Something went very wrong in the evolution of HTML.
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.
HTML should be a document language, yet it has barely improved in that in the last 20 years and is still missing really basic features (e.g. long-form document support).
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...
> I'm not sure what features you mean. Most things I can think of for long form content are right there in HTML.
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.
> If you publish a book as plain HTML scrolling becomes impossible, as any tiny movement will catapult you numerous pages forward.
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.
> 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.
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.
> > 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.
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.
Those are all flaws in browsers, not HTML. In the case of bookmarks that's not even a part of HTML.
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.
A bookmark is just a link and links are part of HTML. If you only workaround those issues only at the client level you aren't fixing anything, as the Web will still be crippled just the same. You need better ways to link content on the Web itself.
A bookmark is just a link and links are part of HTML.
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.
I'm not arguing that the trend is a bad one, but it does come with downsides that are significant for some. For instance, I certainly don't want every random website I might visit to have access to these abilities. It just strikes me as an unnecessary security risk.
What exactly is the security risk? The browser intermediates all access and you already trust the browser to handle many other sensitive operations on your behalf. There's no way for a site to activate this without your approval or covertly without a full zero-day (probably two since most OSes also have recording indicators now).
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.
The security risk is that advanced functionality is available to all websites. Even if the browser itself is actually a perfect sandbox (and I don't think that's a claim anyone would make), it's still a security problem because a lot of mischief can be done within those parameters, such as tracking, fingerprinting, and other forms of spying.
> 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.
> The security risk is that advanced functionality is available to all websites. Even if the browser itself is actually a perfect sandbox (and I don't think that's a claim anyone would make), it's still a security problem because a lot of mischief can be done within those parameters, such as tracking, fingerprinting, and other forms of spying.
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:
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.
> No, it can't. It's an HTML attribute which enables some mobile browser UI around the standard <input type=file> behaviour.
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 a shim on top of a file picker dialog. Instead of taking a picture and picking the file from its saved location, it skips a step and lets you directly supply the file from the OS's camera app.
>Why wouldn't we want to be able to [run interactive apps] web with our devices?
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".
Because the web is for hypertext, which means static content.
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.
The distinction is between growth and creep. Growth is when your spec matures to serve the original purpose even better than it used to. Creep is when your spec decides to achieve other, new purposes.
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.
Path of least resistance. The same reason every single new network service has to be tunneled through a stateless client-server text protocol on a single tcp port. Doing anything less hacky would require more work/money/cooperation. Foundations are expensive, scaffolding is cheap.
Because it's the easiest way to distribute software.
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.
> Because it's the easiest way to distribute software.
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.
> webdev is a pain just as much as making a native Windows app or Go binary
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.
Because its the securest way we have to launch any app on any device. With binaries, any binary might be malicious and therefore I can only trust and run a very small amount of selected binaries. With web apps, I can launch whatever I want without compromising my system.
> With web apps, I can launch whatever I want without compromising my system.
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.
That may be plausible in some limited cases (iOS) but on most platforms opening an untrusted native app is much more risky than opening an untrusted website. For example, a native app has access to the file system, which is all that is necessary to enable ransomware attacks.
This doesn't work at all without JavaScript. I much prefer the picture to a blank region.
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.
Hmm. I couldn't find an indication of whether this requires Secure Context (ie only works with HTTPS or localhost) ?
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.
Secure context has never applied for form data and i see no reason why it would here.
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.
Great seeing coherent cool capabiliites mase so east, taking & growing thr input element like this.
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.
"You can access a user's camera with just HTML" is really misleading, imo. The outlined approach lets you access an image (or video) that is the output of the platform's camera, but you don't actually get to access the camera itself.
You cover your phone camera? This only works on mobile and pops up the native Android/iOS camera which requires you to actually take the picture (and at least on iOS, asks you to confirm you would like to use the photo before going back to the website)
I habitually cover the camera on my phone when I'm not using it. It's just common sense for any connected device running complicated software without hardware switches to turn the sensors off reliably. The latter would be better of course but there wasn't a practical option for it last time I was looking for a new phone.
It's definitely a niche market at the moment. It really shouldn't be given the implications of connected devices, sensors like cameras and microphones, and where those devices get taken by many of their owners. I believe we would have a much safer and more resilient society today if the norm had become for connected devices to follow the principle of least privilege and for there to be complete transparency about how any kinds of sensors and any kind of remote communication operated. But apparently the market has spoken (even though in most cases it was only given one "choice" of what to say).
That is pretty cool. Been wanting to create a site with a blurred backdrop effect around text, but a camera background to simulate an augmented reality style. Wish something like this could work on desktop as well though. It is a shame really that more features don't get encapsulated into elements recently and everything is some JS API that then companies use some bloated framework to utilize.
You can't do what you're describing with just HTML, but it's only a handful of lines of js to get a media stream from getUserMedia and pipe it into a video element. In fact, it's probably more HTML than js.
A lot of totally valid opinions out there about this, but I personally _love_ how the browser is becoming a very well-featured sandbox for shipping applications.
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.
Thanks for saying this, as I know a lot of people on HN have very negative feelings towards this trend. Personally, I feel the browser is a great way to stop reinventing the wheel, and the APIs abstract away a lot of the heavy lifting. They pretty much get you 80% of the way there, and the last 20% is where you can really add the stamp of "uniqueness" to your implementation.
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.
It just feels like every time software developers can't (or won't) build things cross-platform, users end up with bigger and bloatier solutions and poorer experiences.
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.
> Ship an entire physical PC to the user pre-loaded with the application?
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.
> A phone (hi iOS), a video game console, a smart appliance, etc. are examples of this.
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.
You're absolutely correct. IMO, the reason is, to a large degree, ineptness of software engineers. It simply doesn't pay to hire or train high-quality SEs, if you're not google or Amazon (and even they probably only hire and pay the best to prevent competition).
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.
> You're absolutely correct. IMO, the reason is, to a large degree, ineptness of software engineers.
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.
I agree with what you wrote 99% but draw a different conclusion.
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 see so much growth & positivity, so much can-do-ism. Everyone's doing great things, but in particular the web has brought about a much higher access to systems that seem much safer for users, much more sandboxed, with better tools/extensions/navigability/accessibility/hackability, that have much more open source activity going on than native (which has been to huge benefit in so many ways: to productivity, to learning, to exploring, to having fun, to creating social cultures & groups).
> 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.
> Ship an entire physical PC to the user pre-loaded with the application?
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.
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.
>> Ship an entire physical PC to the user pre-loaded with the application?
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.
Eh? Mainframes are and always were general purpose computers, and run stufd like Linux just fine.
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.
I never commented on the specificity, rather I pointed out this quote "Ship an entire physical PC to the user pre-loaded with the application." Replace "PC" with "Mainframe" and the sentence was true (at least back when mainframes were a thing.
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.
The problem with HTML is that it is not a layered technology. It's all or nothing.
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.
Operating systems like WebOS, KaiOS/Firefox OS, ChromeOS largely do away with many layers of the stack, by making the web technology front & center. I do think you're right that perhaps some layers could go, but I think native apps & much of the native OS itself are far closer to the LaserDisc technology[1] that we can get rid of.
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.
I've being wondering about this myself for a personal project.
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.
> Ship an entire physical PC to the user pre-loaded with the application?
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!
The browser is inefficient. Use a modern website on a ten year old laptop and it is close to unusable because of modern web dev practices. That laptop is still perfectly usable for a lot of things.
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.
"modern web practices" may be more to blame than the browser. It's possible to make lean fast things running on browsers (within reason), but the culture is nobody gets fired for bloat. It's ubiquitous, same for mobile apps, server side, etc.
The browser is responsible for providing web developers with ever-increasing resources to eat up. It also defers way an increasing amount of much functionality to javascript (or at least allows javascript to reimplement that functionality) - e.g. there is no native support for DASH video so you are always beholden to whatever js the website uses (unless you want to use website-specific hacks).
There's no desktop standard. Desktop operating systems are either proprietary or niche. Any application you write needs to be ported again to each operating system separately.
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.
> Personally, I feel the browser is a great way to stop reinventing the wheel
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?
If I understand you comment correctly, WebAssembly is on a path to give you that web based container that can be as powerful as your computer allows while still being sandboxed in the browser.
> I personally _love_ how the browser is becoming a very well-featured sandbox for shipping applications.
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.
This is very cool, although I was just playing around with it and my cat cast me a filthy look and raced away at high speed. Your warning about playing the sounds is well given! :)
- 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
I recognize that this kind of thing is useful to the developer, of course, and we've gotten a lot of neat things this way.
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 don't know, this seems like a good compromise to me. Some apps (calendar) would be absolutely crippled without them. For everything else, I've just never turned them on in the first place.
> 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.
My answer to this is that the calendar just does not need to be a web app. Weakening a primary advantage of everything else on the web just so that my calendar can be a web app seems like a poor trade-off.
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.
Calendars are far more useful as web apps than other incarnations; you can open them anywhere and don't have to carry a specific artifact with you to do it.
> 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.
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.
this seems like a pretty silly criticism - you have a feature that is both gated behind a per-site permission prompt and that has an option to globally turn it off, and you're still grumpy that it exists?
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.
I mean... it does exist now, and I don't advocate taking it out since people have probably come to rely on it for some reason. Defaults matter, though, and I suspect[0] that a minority want this default.
[0]- With only anecdotes supporting my suspicion; I haven't done a rigorous study.
It seems silly to ask for a release to be crippled just because a page does something obnoxious inside its own space. The solution to that is a URL allowlist or blocklist.
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.
It was useful an API to detect if a client was faking their user agent or was a bot. When I worked for a neo bank we abuse all the APIs to detect if client was a real person or not without having to use captchas.
I vaguely recall there being some early-days accelerometer-based webapps that absolutely destroyed batteries, because the high-resolution accelerometer checks required responsible throttling / debouncing. So gating it behind permissions makes some sense to me.
USB/Bluetooth is underrated because it means you can ship hardware products that can have their firmware updated or connect and sync with a web service without having to build/ship/maintain a whole app for it that will eventually stop working after an OS update.
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.
My guess is that hardware access with HTML will mostly bring about remote exploits and massive privacy problems. I disable all of it.
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.
Not just playing MIDI files, but interfacing with MIDI controllers (including ones that weren't designed to be accessible over the web leading to RCE).
I love the idea of a good cross platform sandbox to ship apps. I think it's really unfortunate that we chose a web browser to be that application platform.
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.
There is a possible future where HTML and JavaScript are relegated to historical shims for WASM and <canvas>. I don't know if this is a good future or not, but you want a future with cross-platform apps freed from "web technologies" that's probably the one that's most achievable from the state of things today.
One thing I miss about adobe flash was the software available to create flash games and animations. It was relatively easy to use and felt like it had a good combination of graphical tools and scripting to allow you to create what you wanted
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.
The Adobe Flash authoring software has a successor called Adobe Animate. I’ve only ever exported to MP4 video files with Animate, but I know Animate has some HTML5 export options. But I don’t know how comfortable it would be to use for creating graphics and animations for actual JavaScript games and/or web applications.
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).
I personally _love_ how the browser is becoming a very well-featured sandbox for shipping applications.
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.
>A lot of totally valid opinions out there about this, but I personally _love_ how the browser is becoming a very well-featured sandbox for shipping applications.
Unfortunately what's convenient for you as a developer is more often than not hostile and awful UX for me as a user.
If you make a manifest file and listen to the install event users can add your game to their home screen. Aka. PWA. Then you can listen to most keys! Works for chrome on desktop and all major mobile browsers. Safari don't have the install event and need to be "installed" manually
I have made a web editor that uses this. There is an example pwa app
Https://webide se/
The thing I don't like about the browser becoming that is that every web page will now have tons of prompts. Something we were trying to kill off with IE years ago because too many people just click "accept".
I used to think the browser could be a sandbox, but its evolution to one has been mighty slow- decades to pick up some basic features any desktop application developer has been able to take advantage of, easily, for decades.
I really really should. I want to un-abandon my home page and maybe start writing about it there. FWIW the code is here: https://github.com/ablakey/kestrel
Because the entire point is to learn and not actually to ship a product, I wrote my own. The biggest libraries I use that I didn't write are HowlerJS for audio, PixiJS for graphics, and React for UI. The actual "game engine" is a very primitive one I wrote myself. You can see it here: https://github.com/ablakey/kestrel/blob/master/src/Engine.ts
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.
This only applies to the free plan[0] - Higher plans work for excessive RPS, but of course it'll balloon your bill with millions of requests.
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.
In this topic, I wish more tools like databases, Big Data services, etc used WebSocket-based protocols. It would unlock so many cool applications straight within the browser.
https://nega.radioac.dev/
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 ]