Live data from Hacker News

Stop pushing the web forward

quirksmode.org

201–210 of 307 posts

Re: Stop pushing the web forward

#201

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

> The tools that it turns out were a bad idea will die. And those that are good will thrive. We saw that happen with WebSQL vs IndexedDB. A well-designed API (with a syntax every decent webdev knows) vs a bullshit spec (ohai callback hell FOR DOING A SIMPLE FUCKING SORT AND GROUP), and the bullshit won.

All because Microsoft wouldn't break down and embed SQLite into their browser like everyone else did for WebSQL. It's actually really disappointing.

IndexedDB could be built on top of WebSQL as a shim... you can't really do the reverse so easily. It's really disappointing... WebSQL/SQLite with a template string builder interface would be amazing. (I know it's an ES6 thing).

I will say, that I do want what's on deck for ES6/7 (2015/2016) to make it into the browsers... async/await is such a useful feature.

Re: Stop pushing the web forward

#202
>But why do web developers want navigation transitions? In order to emulate native apps, of course.

You got this one quite wrong. It's not about emulation, it's the feature. Reducing the perceived delay with an animation. There is nothing wrong with an improved webpage experience ...

Re: Stop pushing the web forward

#203

Earlier quoted context omitted.

Minecraft has no meaningful UI; the entire window is just an OpenGL canvas.

Look at Google Chrome. You can’t even use any or that looks natively in Chrome – it’s just as native as the old Swing styles.

Given that every other version of applications/oses changes the definition of what "native" looks like... I don't know that it's a huge problem...

Beyond that is the fact that Swing was fugly everywhere, and bootstrap looks decent everywhere.

Re: Stop pushing the web forward

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

Chrome has been the standard Android browser since KitKat, and it auto-updates since Lollipop. Ditto the system webview.

It's such a shame that there are still new Android 4.x devices being produced...

Re: Stop pushing the web forward

#205

ATM, The two top articles (Why Docker isn't Successful in Production) and this one are both cries for the world to slow down. It's not going to and everyone ought to strap in. If change is called for, it will be adopted. If not, it won't. Some technologies were rejected simply because they came about at the wrong time. Some technologies that are adopted now will later be deprecated as better solutions are found. Chan…

> If change is called for, it will be adopted.

Please elaborate. This does not seem to be true but it's too short to fully understand.

Re: Stop pushing the web forward

#206

Earlier quoted context omitted.

My reply was a bit ambiguous and snarky. I don't believe it's the wrong answer if it works. But people are commenting about moving the web forward to run apps in browsers and all and so there are parallels with what we did in the 80's. That's really what I was getting at. Nothing in computing is ever really new.

We're replacing a very nice custom SCO Unix backend developed at my work from 1980s onward (drops users into custom shell, multiple programs execute in the user context, leverages all the nice features of *nix) with a purchased desktop Windows ERP application and it makes me so sad. Literally we will move from having 1 to 2 admin who can manage 300 users, decades of automation, and totally instantaneous program execu…

A web based application could have a very similar backend, and you could run pretty much any modern OS client on the front end...

Though I think the development and training for your new front end will be a bit cumbersome no matter what you use.

Re: Stop pushing the web forward

#207

> We’re pushing the web forward to emulate native more and more, but we can’t out-native native. I can do better than native. I can update web apps without troubling the end user, fix bugs and make improvements immediately. I can balance processing where heavy lifting is done on my servers and simple processing done on the client. I can store immense data in the cloud freeing the end user's machine from any such junk…

Best comment so far! The web is a multi platform client-server application environment. Sanboxed so that unsecure (javascript) code can be downloaded and executed at runtime. THIS is the killer feature of the web. No other app environment has this and Web and JS will eat native apps in the long run because of it.

Re: Stop pushing the web forward

#208

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.

In fairness Visual Studio (and most IDEs) are pretty bloated and slow.

As to the grandparent, that is what asm.js was for, was a subset of JS that could be heavily optimized and JITed... I also really prefer .Net method of native invocation over JNI stubs.

Re: Stop pushing the web forward

#209

Earlier quoted context omitted.

> The tools that it turns out were a bad idea will die. And those that are good will thrive. We saw that happen with WebSQL vs IndexedDB. A well-designed API (with a syntax every decent webdev knows) vs a bullshit spec (ohai callback hell FOR DOING A SIMPLE FUCKING SORT AND GROUP), and the bullshit won.

All because Microsoft wouldn't break down and embed SQLite into their browser like everyone else did for WebSQL. It's actually really disappointing. IndexedDB could be built on top of WebSQL as a shim... you can't really do the reverse so easily. It's really disappointing... WebSQL/SQLite with a template string builder interface would be amazing. (I know it's an ES6 thing). I will say, that I do want what's on deck f…

Hmm... would it be possible, using Promises, to create a sorta-shim, you give it a SQL query and a callback function.

The shim does asynchronously all the stuff a DB engine does (most people are going to use "SELECT cola,colb,colc FROM x WHERE foo=bar and baz=quux ORDER BY cola ASC GROUP BY colb" and nothing more complex anyway), then tracks all the stuff it needs to do in its own promise tracker. Once all is done, it assembles the returned row(s), stores them and calls the callback.

The biggest problem I see is locking as all the crap is async so you'd need some sort of locking and query ordering to maintain data consistency.

Re: Stop pushing the web forward

#210

Earlier quoted context omitted.

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

Perhaps the choice lies outside of the actual functionality of the web itself but instead in the OS and browsers. Consider someone who ships their iOS app that is basically just a web page instead of using a web page. For doing this, they get two benefits that are not really related to the web. One, they get an icon to tab from the home screen to launch their app, instead of going to Safari and then going to their we…

HTM5 appcache to the rescue!

http://www.html5rocks.com/en/tutorials/appcache/beginner/

It's rad.

Post reply on HN