Stop pushing the web forward • Hacker News Board

Re: Stop pushing the web forward

#191

Post by huskyr » Tue, Jul 28, 2015, 9:05 PM UTC

rimantas wrote: post #160

dasil003 wrote: post #129

Earlier quoted context omitted.

The web is an anomaly yes, but it has broader reach than any other platform in the history of mankind. Thinking that native apps will kill the web is to miss the forest for the trees. None of these proprietary platforms have the reach of the web. No computing device maker can release a credible device without web support. It doesn't matter how much money you have, you can't make your proprietary platform cross the ch…

The web ten years ago was indeed different when clean markup, separation of concerns, accessibility meant something. Nowadays it is just a mess, cannon fodder in the battle nobody asked for.

It "meant something" for a tiny fraction of web developers. The vast majority of developers in 2005 was probably either using Flash or creating something that only worked in IE (with its 85% usage share).

Re: Stop pushing the web forward

#192

Post by huskyr » Tue, Jul 28, 2015, 9:10 PM UTC

aquilaFiera wrote: post #116

cwyers wrote: post #104

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

I wouldn't categorize Google as the leader anymore. Mozilla and Microsoft have caught up and are as much leading the charge as Google is. Four years ago I would have agreed but four years ago we needed Google to push the browser forward.

The stats seem to disagree (1): Chrome has risen from a global usage share of 20% in 2011 to almost 50% today. Compare that to Firefox (2011: 28%, now: 16%) and IE (2011: 44%, now: 18%).

(1): http://gs.statcounter.com/#browser-ww-monthly-201106-201506

Re: Stop pushing the web forward

#193

Post by simoncion » Tue, Jul 28, 2015, 9:14 PM UTC

Animats wrote: post #158

wmeredith wrote: post #73

Earlier quoted context omitted.

> But why do web developers want navigation transitions? In order to emulate native apps, of course. This is just a misunderstanding of good UI. Emulating native apps is NOT inherently "Good". There are terrible native apps and great ones. Navigation transitions would be nice as a another arrow in our quiver. Using it wisely is another can of worms.

Browsers should have one built-in navigation transition. When you click on a link that leaves the page, something should happen immediately . It may take seconds for the new page to load, especially on cell networks. There's no immediate user feedback, resulting in multiple clicking, which restarts the page load. So on page exit, something visible should happen. Dim out the page, zoom it down to a tiny rectangle, swo…

> When you click on a link that leaves the page, something should happen immediately.

On every browser I use, the UI changes immediately after clicking a new link.

Pay attention the next time you click a link that's not in cache. Look for messages in the status bar (which is usually hidden, but typically becomes visible on resource load or when hovering over a link), changes of favicons to spinners in tabs, and the change of the reload graphic to a "stop" graphic.

All of these UI changes are obvious to me.

I get that some people are impatient, but these same impatient people likely know how to and are licensed to operate a motor vehicle. Motor vehicle operation is a task that requires constant attention and much finer attention to detail than is required to notice the current browser UI cues that indicate that a new page is on the way.

Re: Stop pushing the web forward

#194

Post by yellowapple » Tue, Jul 28, 2015, 9:18 PM UTC

MacsHeadroom wrote: post #181

ForHackernews wrote: post #100

Earlier quoted context omitted.

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

>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. This is like saying "As construction workers we should be cheering for natural disasters, because there will be more work for construction workers to rebuild destroyed cities." Job security is great- but at what cost…

And honestly, whether as a construction worker or a programmer, I, too, would rather be building new things than rebuilding the same goddamn thing over and over again.

Re: Stop pushing the web forward

#195

Post by ctoth » Tue, Jul 28, 2015, 9:23 PM UTC

amyjess wrote: post #176

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…

> Let's not get started on the fact that HTML is a terrible language for UIs This is why I'm hoping that future web front-end frameworks will output UI elements to a instead of the DOM. If a DOM-like scene graph is needed, it should be managed entirely by the framework and simply be an intermediate layer between the application code and the .

As a blind user and developer I am absolutely terrified by such a prospect. We've just started to get decent accessibility for the plethora of new web features with ARIA and similar. But if you render everything to graphics output directly to a canvas you lose any capability of ever talking to my screen reader. Text is awesome for both people and machines, let's not throw it out.

Re: Stop pushing the web forward

#196

Post by pcwalton » Tue, Jul 28, 2015, 9:26 PM UTC

the8472 wrote: post #124

vezzy-fnord wrote: post #110

Earlier quoted context omitted.

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…

I'm not too fixated on posix + containers. It's just what I'm familiar with. It's more about what the complex web applications are trying to do: Run in an isolated context, run compiled code from whatever language the developer preferred and utilize various low level features in ways that people didn't predict in advance. Basically, what's irritating is that the web standards committees are trying to hand-craft poor…

I'm sure you can do better than the POSIX APIs, but I think it's hard to argue that POSIX APIs are better than the Web APIs. POSIX is a terrible API with decades of cruft.

Re: Stop pushing the web forward

#197

Post by PSeitz » Tue, Jul 28, 2015, 9:29 PM UTC

> Quick, name all the new features browsers shipped in 2015! You see? I don't know all features shipped of any year, so I guess this point is invalid. I don't see anything bad in moving forward, when the things are well thought. And most are imho.

Re: Stop pushing the web forward

#198

Post by codeshaman » Tue, Jul 28, 2015, 9:29 PM UTC

That happens all over tech, not just in web browsers.

Just for fun, I've spent a couple of minutes compiling a list of technologies, just for the backend side of things, which many of us know or have heard of, which ilustrates the complexity and diversity that we have in our industry atm.

It's both beautiful and scary at the same time - how will we be able to move all of that into the future ? How will we scale our brains as we get older ?

So here it goes.

You want to implement something on the Backend ? Nothing can be easier!

Step 1. Pick a language.

C, C++, Go, Java, Ruby, Python, Dart, PHP, Hack, Erlang, D, Xhp, Javascript/CoffeeScript, TypeScript, Perl, Scala, Scala, Clojure, Lisp, ColdFusion, or ASP.NET (C#, VB, F#)?

(https://en.wikipedia.org/wiki/Programming_languages_used_in_...)

Step 2. Pick a framework for the selected language:

ASP.NET, Ruby on Rails, ASP.NET MVC, Django, Meteor, Laravel, Spring, Express, CodeIgniter, Symfony, JSF, Flask, Flex, CakePHP, Zend, GWT, Play, Yii, Sinatra, Tornado, Grails, Struts, Dojo, web.py, Wicket, Bottle, Pyramid, Kohana, Koa, web2py, Yesod, Revel, (fab), Gin, Compojure, Martini, Vaadin, beego, CherryPy, Ring, Scalatra, Mithril and many more (http://hotframeworks.com/).

Step 3. Pick a database:

Oracle, MySql, MSSQL Server, MongoDB, PostgreSQL, DB2, Access, Cassandra, SQLite, Redis, SAP Adaptive, Solr, Teradata, Elasticsearch, HBase, FileMaker, Hive, Splunk, HANA, Informix, Memcached, Neo4j, CouchDB, Couchbase, Firebird, MariaDB, Netezza, Azure SQL DB, Amazon DynamoDB, Vertica, Riak, MarkLogic, dBASE, Ingres, Sphinx, Endeca, Greenplum, Ehcache, Interbase, Amazon Redshift……. http://db-engines.com/en/ranking

Step 4. Pick a hosting provider: Classic or Cloud and pick from just several hundred providers with different APIs and architectures.

Step 5. You're all set! Enjoy your backend. Now it's time to pick a front-end !

Given that most of these have been created in just the last 15 years or so, what will the next 15 years bring ?

Re: Stop pushing the web forward

#199

Post by yellowapple » Tue, Jul 28, 2015, 9:33 PM UTC

simoncion wrote: post #190

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…

> [The JVM is] still unusable for end-user applications because [it makes application startup slow and uses too much RAM.] I can't agree. The poster child for "bloated, overweight, slow-as-shit Java application" is Eclipse. Circa 2013, I found it to be not substantially slower or any less usable than Visual Studio on the exact same hardware.

That's implying that Visual Studio isn't also bloated, overweight, and slow-as-shit - three traits which VS serves as the textbook definition of. It makes Emacs look like ed in comparison, yet without offering any actual improvement in functionality.

In other words, "but it's on par with Visual Studio" does absolutely nothing to counter the argument that the JVM is unusable for end-user applications; if anything, it proves it.

Re: Stop pushing the web forward

#200

Post by rpedela » Tue, Jul 28, 2015, 9:34 PM UTC

jeena wrote: post #90

rco8786 wrote: post #45

Earlier quoted context omitted.

I think this is shortsighted. In 5-10 years browsers will be more Virtual Machine than Web Browser. You can almost argue that they already are. As browsers and phones get more and more performant, the idea of emulating native apps in the browser won't have the performance stigma attached to it. This same thing played out with Java et. al. It was dismissed for being non-performant when compared to C/C++(aka native cod…

But the only languages available are HTML, CSS and JavaScript which are just more than bad for application development because of so many reasons. I would rather see something like Ubuntu Touch tries where they write the frontend with QML and you can have backends in C++ for speed.

> But the only languages available are HTML, CSS and JavaScript which are just more than bad for application development because of so many reasons.

I would have completely agreed with that a few months ago. HTML/CSS/JS is fine for most websites which are primarily text, images, and a couple buttons. But it breaks down quickly when trying to build an application. Then React was invented. I don't know if React will be the thing people use to build web applications in the future, but I think the concepts it introduced will be. The reason is because React provides a foundation that makes it feel more like building a desktop UI or video game than building a traditional website.

Performance will improve over time with faster hardware, faster networks, and software optimizations. Javascript V8 is already one of the fastest scripting languages especially for string handling.