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

91–100 of 136 posts

Re: What Web Can Do Today

#91

Post by ocfx »

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…

> Unfortunately, most "web developers" have made the web worse over the past 10 years because simple, functional, minimal technology is not impressive, and hipsters love to show off

No it's because when I go into work someone says to make it a certain way and if I want to get paid I have to. If you want to blame anyone blame designers who see proof of concept stuff from developers and throw it in designs.

Re: What Web Can Do Today

#93

Post by ebidel »

dheera wrote: post #73
venning wrote: post #69

Earlier quoted context omitted.

> 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…

I've definitely had problems with this. There's a lot of bloat that comes with the DOM, especially if you use a framework like Polymer or Angular. Even something as simple as a material-design text entry field requires a horrific amount of CSS bloat to accomplish internally, and if you multiply that by, say, 1000, you're in for trouble.

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, colors, fonts, typography, margins, composability, x-browser interop,... Sure, if you were implementing your own input, you could cut corners and/or leave out what you didn't need. However, if you were creating a highly reusable, highly configurable element, you'd be implementing the same amount of "bloat" yourself.

Re: What Web Can Do Today

#94

Post by ebidel »

venning wrote: post #74
dheera wrote: post #73

Earlier quoted context omitted.

I've definitely had problems with this. There's a lot of bloat that comes with the DOM, especially if you use a framework like Polymer or Angular. Even something as simple as a material-design text entry field requires a horrific amount of CSS bloat to accomplish internally, and if you multiply that by, say, 1000, you're in for trouble.

Polymer and Angular 1.x do come with a lot of bloat. I wouldn't call a MD text entry field "simple". Material Design was released ahead of web technologies really being able to manage it well, at least on mobile.

Polymer itself is 47KB. If you add the web component polyfills (16KB), that's 63KB minified and gzipped. I tend not to consider the polyfills because they're not Polymer and are a stop-gap that goes away over time.

Re: What Web Can Do Today

#95

Post by ArleneBarlow »

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…

The web got better according to most people. The devs responded to what people wanted, and that's flashy, interactive stuff.

What the web was 'meant' to be is irrelevant, because the web has grown far beyond what it's original designer intended. On one hand you imply that it's good that the web is open, and part of being open is that people can make it what it wants, and not obey the original intention of the first designer.

It's unfortunate that your vision of the web is in disagreement with the 'general users'.

Re: What Web Can Do Today

#96

Post by dheera »

ebidel wrote: post #93
dheera wrote: post #73

Earlier quoted context omitted.

I've definitely had problems with this. There's a lot of bloat that comes with the DOM, especially if you use a framework like Polymer or Angular. Even something as simple as a material-design text entry field requires a horrific amount of CSS bloat to accomplish internally, and if you multiply that by, say, 1000, you're in for trouble.

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 implementing the same amount of "bloat" yourself.

Sure, if I implemented it in JS. Implemented natively, a MD paper-input consumes very little resources because it isn't a nested div hell with CSS and a shadow DOM.

What would be more awesome is if there were a way to, using HTML and JS, "ask" the browser to call and insert a native element and be able to interact with it. On iOS, it should be an Apple-styled element, and on Android 5.x, it should be a MD element. They should be the genuine native element inserted right in place, not a DOM hell designed to "look" like the native thing.

Re: What Web Can Do Today

#97

Post by Pxtl »

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 tend to think rants like this are just being luddites, but all this JavaScript and external resources rest are ruining the experience of the web. Holy crap is everything slow now. On desktop we've all gotten into the habit of tabbing the new stuff and waiting for load while doing something else, but on mobile where that workflow isn't as easy and you have to watch a page load? I'd say HN is one of the very few sites I can stand anymore.

Re: What Web Can Do Today

#98

Post by initself »

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…

The web is whatever we want it to be, but sad that lack of agreement on standards and openness of platforms severely limits what it can be now without a massive sea change. Because collective agreements tend towards entropy, those with the power in the agreements hold on tight to prevent decline. When we become more conservative and restrictive in order to keep collectives in place (open web >> Facebook), it limits our freedom to innovate and development becomes "a fight to maintain" that benefits the few rather than "a forward thinking step-by-step process" that benefits more and more people.

Re: What Web Can Do Today

#99

Post by dheera »

bzbarsky wrote: post #84
laughinghan wrote: post #59

Earlier quoted context omitted.

I think the parent knows exactly what CORS is and you're misunderstanding. There's no fundamental reason browsers can't be configured to not send the user's cookies when making XHR requests, and in fact there's already a mechanism for a webpage to ask certain kinds of CORS requests to be "anonymous": The "anonymous" keyword means that there will be no exchange of user credentials via cookies, client-side SSL certific…

What you characterize as an "arbitrary technical limitation" is there for a good reason, unfortunately: even anonymous requests made by the _browser_ are not equivalent to anonymous requests made by the _server_ the web page came from. That's because the browser and the server have different routing tables. Or to put is more simply, the browser can see the stuff on your LAN, behind your firewall, while the server can…

IMHO the true point of a web app is to replace the native app and kill the need for developing every app twice (Android + iOS), as well as moving toward the vision of putting ALL apps "in the cloud" and fully OS-independent.

In order for this to happen, those web apps need to have every capability a native app can have, including access to the local area network, if you want to do "things that native apps do". What if I want to write an HTML5 SSH client so that I don't have to rewrite it twice for iOS/Android? An SMB client? A custom streaming protocol? An HTML Arduino IDE that can flash code over the LAN?

Ideally, a web app could simply have a manifest of permissions, present this list to the user at an appropriate time, and the user decide whether or not to grant them. Opening arbitrary TCP sockets should also be a permission, just like native apps need to add this to their manifest. Native apps already ask for permissions when installed; web apps should be required to do the same, and in return, be granted the same set of capabilities.

The idea that "web apps should be restricted" is at odds with the vision of using web apps to realize a true cross-platform app programming ecosystem.

Re: What Web Can Do Today

#100

Post by pdkl95 »

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's too hard

It's only hard if you want it to be hard. Your tools should be handling most of it for you. If they don't, pick tools that aren't broken or badly designed. When I was writing websites in Rails 2.x, progressive enhancement was usually automatic (same views are rendered as a page or a dynamically-loaded partial).

Saying "It's hard because I want to write over-complicated pages with badly designed tools" isn't good engineering or good design.

> most users run with their browser's default settings

How, exactly, do you know this? If the answer is "analytics", you are missing an increasing amount of data.

> constantly evolving platform

Which is why you progressively enhance pages. Those of us that disable javascript for safety usually get blamed when this topic is brought up, but the main reason for progressive enhancement is that it's defense in depth. You don't know what the browser is, what options it has set, what bugs it may or may not have, or if extra page assets even made it successfully over the network.

Not bothering with progressive enhancement is shoddy programming for much the same reason you shouldn't skip the test for NULL after calling fopen(3).

edit: grammar

Post reply on HN