What Web Can Do Today • Hacker News Board

Re: What Web Can Do Today

#61

Post by ams6110 » Mon, Nov 30, 2015, 1:03 AM UTC

bad_user wrote: post #55

majika wrote: post #48

What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that. All non-application websites should provide all their content in semantic HTML at appropriate HTTP endpoints, with CSS styling (in as few requests as possible) as required per the design, and JavaScript (in as few requests as possible) that takes the semantic HTML…

You're talking about " progressive enhancement ". It's a romantic idea, but it never happened, probably because it's too hard and the cost is not justified given most users run with their browser's default settings. The precursor of the web made by Tim Berners-Lee dates back to 1980, but it was not based on HTML or HTTP. These happened later in 1990 and early 1991. But then CSS happened in 1994. And Javascript happen…

It was Microsoft with Outlook Web Access that really was the first big example of what was possible. I worked with several folks around that time and we were doing "rich" web apps in IE5 with XML data delivered from the server via xmlhttp and building the presentation in the browser with XSLT. It was really slick, especially at the time, to be able to filter and sort, do summary and detail views, etc. all without a page refresh.

Re: What Web Can Do Today

#62

Post by mei0Iesh » Mon, Nov 30, 2015, 1:05 AM UTC

majika wrote: post #48

What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that. All non-application websites should provide all their content in semantic HTML at appropriate HTTP endpoints, with CSS styling (in as few requests as possible) as required per the design, and JavaScript (in as few requests as possible) that takes the semantic HTML…

It's the Flashification of the web. People who wanted to show off, or code web apps, used to use Macromedia Flash. People complained about it, in part because sometimes if you accessed a site without the Flash plugin you'd see a blank page.

But Flash was great in many ways, and it was self-contained in objects, so websites were mostly still websites. JavaScript had been around for a long time, but there was still a cultural norm that most people respected about not requiring JavaScript. This was mainly because a lot of browsers still didn't fully support it, or people had it turned off. It was also when some people had cookies disabled.

Then once Adobe bought Flash, and then Apple blocked Adobe Flash, it really killed the Flash way, and all that spilled over into HTML with HTML 5 and the new cultural norm of kids who are more concerned with showing off socially than the meat and potatoes of hypertextual information.

It should've been obvious that there was a need for a new web, for code and multimedia. But in the .com boom nobody would dare try to start with something unpopulated, since it'd risk losing their chance at fortune.

Today, instead, maybe we should go in the opposite direction and create a new old web; a hypertext network that specifically only works for HTML, so people can have this one to morph into an app network, and we'll not lose the text-linking place we've grown accustomed to.

Re: What Web Can Do Today

#63

Post by BurningFrog » Mon, Nov 30, 2015, 1:08 AM UTC

majika wrote: post #48

What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that. All non-application websites should provide all their content in semantic HTML at appropriate HTTP endpoints, with CSS styling (in as few requests as possible) as required per the design, and JavaScript (in as few requests as possible) that takes the semantic HTML…

Strong opinions on how things should be, but no arguments for why.

That is never going to convince me.

Re: What Web Can Do Today

#64

Post by _puk » Mon, Nov 30, 2015, 1:08 AM UTC

deathanatos wrote: post #56

dheera wrote: post #50

More stuff the web can't do that native apps can do: * Request stuff from arbitrary URLs without a CORS proxy * Open TCP and UDP sockets * Be in the play store/app store AS a web app (home screen installation isn't enough; people still search for your thing in the app store, so even if the other problems aren't issues for your app, you still have to wrap your web app in a dummy native framework and upload it if you w…

I'm not saying that native apps > web apps isn't true, but… > * Request stuff from arbitrary URLs without a CORS proxy CORS isn't a proxy; it's a browser policy/algorithm that allows a site the opportunity to say "yes (or no), other websites may (or may not) make AJAX requests here". The native app (unless you've informed it somehow, or it has done something malicious) doesn't have the user's cookies, whereas the bro…

> CORS isn't a proxy;

I don't think the GP was implying that.

If you don't control the upstream content you don't necessarily control the CORS settings. Hence the need for CORS proxies to work around an ideal introduced by the major browsers in the last few years.

In the real world you may well have the right to access third party content, but in many cases you require them to expend engineering resource to perform the very simple task of enabling a simple set of headers, so end up having to proxy content.

Take Chromecast for example - it takes CORS to the extreme requiring it set on HLS manifests and .ts video files, meaning any proxy solution has to take the full cost of proxying the full video content. MP4 files don't have this restriction, nor do any browsers.

To me it very much feels like the web is splitting into two - Sites that you stumble upon and want completely sandboxed, and those you come back to repeatedly and provide enough value for you to click "yes, have my location"..

Re: What Web Can Do Today

#65

Post by tjohns » Mon, Nov 30, 2015, 1:14 AM UTC

deathanatos wrote: post #56

dheera wrote: post #50

More stuff the web can't do that native apps can do: * Request stuff from arbitrary URLs without a CORS proxy * Open TCP and UDP sockets * Be in the play store/app store AS a web app (home screen installation isn't enough; people still search for your thing in the app store, so even if the other problems aren't issues for your app, you still have to wrap your web app in a dummy native framework and upload it if you w…

I'm not saying that native apps > web apps isn't true, but… > * Request stuff from arbitrary URLs without a CORS proxy CORS isn't a proxy; it's a browser policy/algorithm that allows a site the opportunity to say "yes (or no), other websites may (or may not) make AJAX requests here". The native app (unless you've informed it somehow, or it has done something malicious) doesn't have the user's cookies, whereas the bro…

>> * Barometric sensors >You mean like current air pressure? Are there common devices out there with these? (None of my computing devices have anything like this, for example.) (and what would I want this for?)

Most modern phones have a barometric (yes, air pressure) sensor included. Having semi-accurate altitude data helps the GPS receiver obtain a faster location fix, but it can be used for other things as well.

Re: What Web Can Do Today

#66

Post by tschuy » Mon, Nov 30, 2015, 1:16 AM UTC

deathanatos wrote: post #56

dheera wrote: post #50

More stuff the web can't do that native apps can do: * Request stuff from arbitrary URLs without a CORS proxy * Open TCP and UDP sockets * Be in the play store/app store AS a web app (home screen installation isn't enough; people still search for your thing in the app store, so even if the other problems aren't issues for your app, you still have to wrap your web app in a dummy native framework and upload it if you w…

I'm not saying that native apps > web apps isn't true, but… > * Request stuff from arbitrary URLs without a CORS proxy CORS isn't a proxy; it's a browser policy/algorithm that allows a site the opportunity to say "yes (or no), other websites may (or may not) make AJAX requests here". The native app (unless you've informed it somehow, or it has done something malicious) doesn't have the user's cookies, whereas the bro…

> Are there common devices out there with these?

Most Android devices since maybe late 2012 have had one. It's used for enhancing GPS lock, and whatever developers can dream up. All I've heard about it being used for is a distributed air pressure sensor network used for weather prediction, tracking, etc. [0[

0: https://www.pressurenet.io/

Re: What Web Can Do Today

#67

Post by m_fayer » Mon, Nov 30, 2015, 1:23 AM UTC

dheera wrote: post #50

More stuff the web can't do that native apps can do: * Request stuff from arbitrary URLs without a CORS proxy * Open TCP and UDP sockets * Be in the play store/app store AS a web app (home screen installation isn't enough; people still search for your thing in the app store, so even if the other problems aren't issues for your app, you still have to wrap your web app in a dummy native framework and upload it if you w…

* Offline mode:

If you have large amounts of structured data and high performance requirements for it... well, good luck.

Re: What Web Can Do Today

#68

Post by frankensmith » Mon, Nov 30, 2015, 1:23 AM UTC

majika wrote: post #48

What the web is increasingly unable to do today: provide text content without requiring a code execution environment. This site is another example of that. All non-application websites should provide all their content in semantic HTML at appropriate HTTP endpoints, with CSS styling (in as few requests as possible) as required per the design, and JavaScript (in as few requests as possible) that takes the semantic HTML…

This comment reminds me of Maddox and his 90s' style html blog: http://www.thebestpageintheuniverse.net http://maddox.xmission.com/

Re: What Web Can Do Today

#69

Post by venning » Mon, Nov 30, 2015, 1:23 AM UTC

dheera wrote: post #50

More stuff the web can't do that native apps can do: * Request stuff from arbitrary URLs without a CORS proxy * Open TCP and UDP sockets * Be in the play store/app store AS a web app (home screen installation isn't enough; people still search for your thing in the app store, so even if the other problems aren't issues for your app, you still have to wrap your web app in a dummy native framework and upload it if you w…

> Scroll like a native app without Safari's stupid rubber band scrolling the entire app at very erratic times

This is defeatable, either with `-webkit-overflow-scrolling: touch;` or other techniques.

> Background geolocation, background anything really

You mean, Service Workers?

> Display long lists of styled content and scroll without stalling

I could be wrong, but I think this is a Safari-specific concern. Android Chrome has never had this problem for me. In older versions of iOS, Safari was not able to execute Javascript while scrolling which could be perceived as "stalled" rendering. I'm not sure if that's what you mean, but Apple has been gradually working to allow JS execution during scroll. But they're so behind (in years) that I wonder if there are still some cases where the execution can't keep up with the scroll.

Re: What Web Can Do Today

#70

Post by johncolanduoni » Mon, Nov 30, 2015, 1:23 AM UTC

bobbles wrote: post #45

eridius wrote: post #29

Earlier quoted context omitted.

Which is usually a correct assumption. But it's more than just metered, it's also assuming that my wifi connection is likely to be faster and therefore downloading a bunch of assets in the background will have less of an impact on my available bandwidth.

'usually' you mean in the US? While I was in the UK I had unlimited data on my mobile but a 100GB limit/month on my landline connection

Metered landlines aren't uncommon in the US, especially in areas with poor telecom infrastructure. I think if your app is worried about amounts of data relevant for metered cellular (which can be in the 2GB range in some places, including the US), the metering on landlines is virtually infinite in comparison.