Stop pushing the web forward • Hacker News Board

Re: Stop pushing the web forward

#101

Post by kuschku » Tue, Jul 28, 2015, 4:29 PM UTC

apalmer wrote: post #61

pikzen wrote: post #52

Earlier quoted context omitted.

>there's almost no native-feeling cross-platform UI library for native apps at the moment Xamarin.Forms is the closest I can think of. Qt too, kind of. >The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence. It's true, the browser succeeded as a working everywhere…

I get where your coming from, and agree with a lot of what you say. BUT, Fundamentally... >The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page. Is just not a true statement. Or rather, the web sucks, but it is the only cross platform UI experiment that has 'worked' on any significant level.

Well, Java has succeeded, too. Look at Minecraft.

Re: Stop pushing the web forward

#102

Post by jscottmiller » Tue, Jul 28, 2015, 4:31 PM UTC

> Instead, we should focus on the web’s strengths: simplicity, URLs and reach.

How does new browser feature X prevent a developer from doing any of these things?

> Being forced to work around IE6’s issues required quite a bit of creativity, and although not every solution stood the test of time (most libraries and frameworks from that era, for instance), it still made the creative juices flow.

'Tools' are bad except when they are used to work around stagnant browsers, I guess?

Re: Stop pushing the web forward

#103

Post by kuschku » Tue, Jul 28, 2015, 4:31 PM UTC

jebblue wrote: post #83

teacup50 wrote: post #59

Earlier quoted context omitted.

The JVM itself got faster -- and in many places, relies on native code for particularly expensive functionality -- but it's still unusable for end-user applications because: 1) The long load time / hotspot JIT overhead when starting applications. 2) The large memory overhead of the Sun/Oracle GC's reserved heap. To some degree, Dalvik solved some of these issues, but has also retained the (very necessary) escape-hatc…

Minecraft alone shows your first two points are not valid. Write a hello world app in Java, the startup time is miliseconds, the memory is not humongous.

Yes, recently, Java actually became usable for a lot of seemingly native apps.

And it does this a lot better than the browser.

Re: Stop pushing the web forward

#104

Post by cwyers » Tue, Jul 28, 2015, 4:32 PM UTC

I think this is the key:

> The moratorium would hit Chrome much harder than it would the other browsers, since it’s Google that is proposing most of the new features nowadays. That may not be entirely fair, but it’s an unavoidable consequence of Chrome’s current position as the top browser — not only in market share, but also in supported features. Also, the fact that Google’s documentation ranges from lousy to non-existent doesn’t help its case.

I think the title and a lot of the rhetoric is misleading, really. It's not so much "stop pushing the web forward" as it is "stop letting Google decide where forward is and leaving everyone else to either ratify it or be irrelevant." And, uh, good luck with that. I mean it. I would love to see that happen, but I don't see how to get there.

Re: Stop pushing the web forward

#105

Post by mildweed » Tue, Jul 28, 2015, 4:34 PM UTC

This seems to be an appeal more to the W3C and browser developers than it is to the rest of us. He's not asking us to stop, in fact, he's asking us to double down and make use of the standards that we already have.

Re: Stop pushing the web forward

#106

Post by scholia » Tue, Jul 28, 2015, 4:34 PM UTC

ForHackernews wrote: post #95

scholia wrote: post #81

Earlier quoted context omitted.

The usual meaning is "native apps" for smartphones, as opposed to traditional programs like PhotoShop and AutoCAD. It's a broadbrush description but almost everybody gets it. Would you like to offer a simpler, shorter and more accurate way of making this distinction?

I think it's a silly distinction to make. Native applications (meaning software running on a computer, outside a browser sandbox) have always offered a smoother, more comprehensive user experience. That doesn't mean users get no value from the web, or that they're so spoiled by fast transitions in Microsoft Word that they won't want to use a website.

I agree, but that's not the point.

The point is that some -- perhaps many -- people want to distinguish between smartphone apps and traditional programs, and that's one way to do it.

It would be nice if there was a better way, but I don't know of one.

Incidentally, it's a distinction that people also make between "universal apps" (written for Windows Runtime) and desktop programs (written to the Win32 API) even when they do the same job on the same Windows 8 or Windows 10 PC.

Re: Stop pushing the web forward

#107

Post by ectoplasm » Tue, Jul 28, 2015, 4:35 PM UTC

ForHackernews wrote: post #100

apalmer wrote: post #61

Earlier quoted context omitted.

I get where your coming from, and agree with a lot of what you say. BUT, Fundamentally... >The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page. Is just not a true statement. Or rather, the web sucks, but it is the only cross platform UI experiment that has 'worked' on any significant level.

> the only cross platform UI experiment that has 'worked' on any significant level. Users do not care about cross-platform compatibility, at all. They only care that it works on their platform. As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc. The only people who sho…

> Users do not care about cross-platform compatibility, at all.

I've heard that some users have both a phone and a laptop.

Re: Stop pushing the web forward

#108

Post by cwyers » Tue, Jul 28, 2015, 4:36 PM UTC

bcg1 wrote: post #60

kabdib wrote: post #49

Earlier quoted context omitted.

I've spent the last two years doing "full stack" [yeah, those words, sorry . . . but going from bare metal to C++ to PHP/JavaScript to frobbing routers all on the same day probably qualifies], coming from a background of C/C++ driver and native code development for 30 years. What I see is an immature community that cannot make up its mind. I see fads, I see awful tools, and even more awful tools that try to fix the a…

This is the problem with what PPK is suggesting. The Firefox and Chrome developers are mostly certainly professional developers who are well qualified to create a standardized cross browser feature set that will obviate the need for the cruft. Only recently have we started to emerge from the Silverlight-Flash-JavaApplet-ActiveX-webish ghetto that we were mired in for years as Microsoft refused to add new standard fea…

Can I sing a few praises for the ghetto for a minute? It had more features. It was friendlier to non-developers because of things like Flash. It had more features. You could directly port native code through things like ActiveX (which we are now only recently getting back through ASM.js, with performance within an order of magnitude). It had more... you know where I'm going with this. The problem with that paradigm is the rise of resource-constrained mobile devices and security issues. But I'm unconvinced that the new paradigm won't just regrow the security issues and the performance problems as the features catch up.

Re: Stop pushing the web forward

#109

Post by tedunangst » Tue, Jul 28, 2015, 4:44 PM UTC

pbhjpbhj wrote: post #99

rgbrenner wrote: post #21

We need a break. We need an opportunity to learn to the features we already have responsibly — without tools! Also, we need the time for a fundamental conversation about where we want to push the web forward to. How about this.. YOU take a break. Stop trying to keep up with every little new thing that comes out. Wait a while. And you'll get exactly what you want. The tools that it turns out were a bad idea will die.…

Do you know PPK and his work? He's been at the cutting edge of web-standards and implementations for at least 12 years if my memory serves me correctly. >And you'll get exactly what you want. // If he wants to avoid the web being badly negatively effected by short term views of current browser companies and standards bodies then he won't get what he wants by sticking his head in the sand and ignoring the direction he…

> I find it funny that web pages are trying to be native apps and many mobile apps are shipping when they're ostensibly just web pages.

Which provides some insight into what's missing from the web. It's almost good enough for most companies. They just need a little something extra so that they can "own the experience." But soon the browsers will catch up and then websites will be able to own your experience, too.

Re: Stop pushing the web forward

#110

Post by vezzy-fnord » Tue, Jul 28, 2015, 4:46 PM UTC

the8472 wrote: post #96

vezzy-fnord wrote: post #58

Earlier quoted context omitted.

There's a standard for most things happening in a browser There's POSIX, too. In practice, divergences are plentiful. Differences among current browsers are more among performance and experimental features The fact that are huge web tables meticulously documenting feature compatibilities across browsers implies differently. Besides, a lot of web standards are done post-facto. I don't see the situation as being any be…

> There's POSIX POSIX + a standard library for UI components + containerization + webassembly would be the "correct", cleanroom solution in my opinion. If you want to build and run "native but untrusted" applications on the user's computer on heterogenous environments and can't anticipate which APIs someone is going to need next. Well then give them access to a walled-off part of the computer. Same-origin policy? Rep…

Sounds like you're really poorly reinventing Inferno. I don't even understand why you would need WebAssembly in this hypothetical scheme.

Container namespacing isn't fine-grained enough, and much of this is the result of traditional Unix-likes having large disparities between different ways of naming things that cannot be composed. The Spring solution was to have all of these descend from a name service, and the Plan 9/Inferno solution to have all resources be multiplexed into virtual file systems (i.e. one way of naming things).

Furthermore, the inclusion of containers here gives you a worst-of-both-worlds approach. You're not even detaching resource subsystems from a unit of execution's POV, you're cloning the entire OS namespace modulo disallowed subsystems for every unit of execution. That's a combinatorial explosion of the state space.

It also means complicated solutions to the problem of resource management and communication within and between containers, which is a problem when virtualization occurs at a too high level. In contrast, virtualization at the process/task level with OS-wide capabilities for single-system imaging and a heavily integrated subsystem for naming things (either a one true approach or a prototype-based one) means you can configure a system like it's a whole unit without sacrificing security.

Then it's not like POSIX is even that great. Why should a process be associated with one uid? Why can't I dynamically attach and remove capability tokens from processes while they're running, like the Hurd does it?