Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Web Can Do Today

whatwebcando.today

Post reply on HN
Print view View original

121–130 of 136 posts

Re: What Web Can Do Today

#121

Post by pdkl95 »

_urga wrote: post #119

Browsers are great at rendering. But they are terrible when it comes to exposing the raw power and capability of a machine to web apps that the user wants to trust. They spec their API implementations by committee (and committees of committees) and they rarely implement any spec in its entirety. The web is becoming increasingly fragmented as a result. The web is good for "web pages", but bad for "web apps". The web c…

> The web is good for "web pages"

That is, after all, what it was designed for. Making web pages interactive in any way beyond a has always been a hack.

> give web apps some way to access the filesystem

> And when will web apps (not "web pages") get TCP or UDP?

First, if it's in a browser, there isn't much of a distinction between "web apps" and "web pages". The browser, by definition, exists as a sandbox that renders unsafe data and code. Allowing any kind of access to the filesystem or TCP or UDP will hopefully never happen.

All networked software needs to implementing security concerns as the first and highest priority, If you aren't, you're putting the people that use your software at risk.

The browser must always[1] be limited in what it an do. If you want to do more (which is fine), write a standalone application. If your favorite platform doesn't let you write such applications, complain to the vendor or change to something that isn't hostile to software development.

> the module ecosystem and core power of Node.

That ecosystem is tiny compared to what is available in /usr/lib64/. I like Javascript, but there is a lot more to computing outside that single ecosystem.

[1] Unfortunately current browsers are already over the line with what they allow pages to access.

Re: What Web Can Do Today

#122

Post by [deleted] »

pdkl95 wrote: post #121
_urga wrote: post #119

Browsers are great at rendering. But they are terrible when it comes to exposing the raw power and capability of a machine to web apps that the user wants to trust. They spec their API implementations by committee (and committees of committees) and they rarely implement any spec in its entirety. The web is becoming increasingly fragmented as a result. The web is good for "web pages", but bad for "web apps". The web c…

> The web is good for "web pages" That is, after all, what it was designed for. Making web pages interactive in any way beyond a has always been a hack. > give web apps some way to access the filesystem > And when will web apps (not "web pages") get TCP or UDP? First, if it's in a browser, there isn't much of a distinction between "web apps" and "web pages". The browser, by definition, exists as a sandbox that render…

[deleted]

Re: What Web Can Do Today

#123

Post by TheAceOfHearts »

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…

I think this is because so many websites try to shove ads and tracking crap down your throat.

It's not even particularly difficult to pull off for certain websites. For example, my blog uses React and it does server-side rendering, so it'll work without JS at all. However, if you do have JS enabled, it'll let you avoid doing full-page reloads to navigate around. I totally agree that for content-focused websites, you tend to get a better experience by limiting gratuitous JS abuse.

However, this isn't very feasible when you're building highly interactive applications. In the case of something like Facebook, they do have a version of their app that works without JS... But how many people can afford to maintain multiple versions of their applications?

I think a good compromise is achievable by well documented APIs or even better with a public GraphQL schema! If I don't use magic APIs to build our frontend app, you can build a different frontend that's tailored for your needs.

Re: What Web Can Do Today

#124

Post by TheAceOfHearts »

dheera wrote: post #96
ebidel wrote: post #93

Earlier quoted context omitted.

Perspective is important :) Putting 1000 material design inputs on a page isn't something a sane web app would do. The same is true for a native app. Re. "bloat" of components. I think it's important to remember everything something like paper-input is doing for _you_. As a developer, I no longer have to think about: validation, animations, a11y, keyboard, knowing all the MD spec configurations, labels, underlines, c…

> Putting 1000 material design inputs on a page isn't something a sane web app would do. Why not? What If I want to make a material design spreadsheet app? Just a random idea, but again, the people who make basic OS-style UI elements shouldn't be judging what a "sane" app should and shouldn't do. This limits creativity. > However, if you were creating a highly reusable, highly configurable element, you'd be implement…

I would conjecture that any app that's doing thousands of inputs will probably use virtualized lists so performance is predictable. And you can do that with JS too :D.

Re: What Web Can Do Today

#125

Post by realityking »

eridius wrote: post #27

I'm very surprised to see this claim that Safari on OS X[1] can't handle Push Notifications, because it's been able to do that for a few years now. It's just not using Service Workers. It uses a separate solution built around the Apple Push Notification service. Granted, this isn't cross-platform and isn't a W3C standard, but it is a capability that can be used today. But of course the whole section on "Push Notifica…

If I'm not mistaken on iOS you can only do it if you wrap you r web app into a native app. On OS X however you can actually get real push notifications even for websites.

Re: What Web Can Do Today

#126

Post by TimJYoung »

bobajeff wrote: post #81
vezzy-fnord wrote: post #46

Earlier quoted context omitted.

It certainly has advanced the most, but that's a misleading presentation. It has advanced the most technologically only relative to its own starting position, i.e. it spent all this time catching up from blank state to where everyone else already was (and still is).

The web does things those other platforms don't. Like run unsigned applications from any server ephemerally on any machine or system. It's not playing catch up so much as adding powerful features without sacrificing it's core attributes.

Yes, and yes. The things it can't do are a pain, but the things that it can do are things that are very difficult to do in a standardized way with desktop/mobile. A cross-platform UI that simply works on just about any device was considered the holy grail of computing at one point. Everyone gave up on it after a while, and very quietly the web just "became" the platform that enabled such a UI, without limiting how such a UI can be created.

Re: What Web Can Do Today

#127

Post by talmand »

spion wrote: post #120
TeMPOraL wrote: post #83

Earlier quoted context omitted.

Also note tat the separation of content and structure is mostly nonexistent as it's currently practiced. People like to talk about it as a Golden Rule, a holy virtue, and then proceed to write even worse code than they did with tables. Generally, if you find yourself writing a tangled mess of divs in order to support CSS tricks, you're not really separating content from the structure. HTML5 semantic tags helped a lit…

Have you considered that there may be an actual reason why people write a tangled mess of divs. Could it be because the entire model is crappy and people don't know what to do to make it show things the way they (or their client) want(s)?

In my experience, as a front-end developer, the usual reason I need a mess of divs and spans is to support a design that's not a good idea for a web page to begin with.

Re: What Web Can Do Today

#128

Post by spion »

talmand wrote: post #127
spion wrote: post #120

Earlier quoted context omitted.

Have you considered that there may be an actual reason why people write a tangled mess of divs. Could it be because the entire model is crappy and people don't know what to do to make it show things the way they (or their client) want(s)?

In my experience, as a front-end developer, the usual reason I need a mess of divs and spans is to support a design that's not a good idea for a web page to begin with.

What is a web page, and why would a particular design not be a good idea for it?

If a web page is not a good idea, then what other technology should be used to achieve that design, as well as remain equally easy to distribute?

This mindset is precisely why native mobile applications continue to exist on the market, and why articles like this one fail to convince me. Nobody (except perhaps Facebook with React) tries to really fix the web to meet the demands its been given. Instead everyone insists that the demands should change to meet the original vision and limitations of the web.

Regarding the HTML/CSS interplay, flexbox gives me some new hope that reconciliation is possible (getting both semantic markup and powerful / precise styling).

Re: What Web Can Do Today

#129

Post by KingMob »

rimantas wrote: post #25
slimsag wrote: post #7

This is really awesome :) The truth is that the 'web' is really becoming the cross-platform application architecture. Just a few years back I despised the very idea of this -- I want to program in my favorite language, not JavaScript (no matter how nice it is these days). I'd love to write applications that can act like native ones while also being cross platform (and use multiple threads at that!). The fact that Web…

The truth is that web is getting deeper and deeper into identity crisis. And if any platform is further away from having coherent architecture, it is web.

The web has problems, for sure, but it's still way more unified than apps, which have two major, largely incompatible, ecosystems: Android and iOS.

Re: What Web Can Do Today

#130

Post by talmand »

spion wrote: post #128
talmand wrote: post #127

Earlier quoted context omitted.

In my experience, as a front-end developer, the usual reason I need a mess of divs and spans is to support a design that's not a good idea for a web page to begin with.

What is a web page, and why would a particular design not be a good idea for it? If a web page is not a good idea, then what other technology should be used to achieve that design, as well as remain equally easy to distribute? This mindset is precisely why native mobile applications continue to exist on the market, and why articles like this one fail to convince me. Nobody (except perhaps Facebook with React) tries t…

It's easy to find designs that are bad ideas for web pages. The most obvious culprit is a design that's excellent for a magazine layout. Such designs typically don't take into account the document flow nor the idea that different people open their browsers to different resolutions and browser window sizes. Heck, some won't even take into account different browsers with different capabilities. I think I understand where you're going with the "what is a web page?" bit, but it doesn't necessarily apply. Especially since a web page can be whatever anyone wants within the limitations of a browser, but that doesn't mean a design works based on some person's idea of what they think a web page is. In most cases a design is limited by the browser, not necessarily by the code of the page.

I have no idea what you mean by your second sentence.

And then, are you referring to my mindset or some other mindset? Because I fail to see how you can know my mindset on the matter. If it's the other, I would agree. Except I would say that "fixing" something in terms of making it do something it wasn't intended in the first place may possibly create more problems than we are attempting to fix. I would suggest attempting new things to see if they work, which there are some doing just that. I would point out that flexbox is an example of this.

I'm excited with flexbox and have started pushing to make use of it more often, when warranted. It's hard to switch current code to it, but I think it's worth it. But, in the end, someone will eventually start complaining about its limitations and that it needs to be "fixed". Then we'll be back where we started, it's inevitable.

Post reply on HN