Earlier quoted context omitted.
That's certainly not what I want to share. One of the things that good video sites provide is context. E.g.: Who made this? What else have they done? How can I find them? Has this been widely seen? What do people say about it? Raw streaming urls don't get me any of that. URLs aren't just pointers to bytestreams. From a user sharing perspective, they're humans pointing to a unique thing. And what they're pointing to i…
You could easily address those concerns without turning what should be a simple video into a clusterfsck of Javascript. For example: https://mytube.com/$username/my_first_video.ogg With such a scheme, you immediately know who made it - $username - and (if this hypothetical mytube.com built a proper website) navigating to mytube.com/$username would return a list of videos (maybe with some additional routes for playlis…
Web vs. native: let’s concede defeat
411–420 of 515 posts
Re: Web vs. native: let’s concede defeat
#412Earlier quoted context omitted.
You went on to list a bunch of niche app classes except for two: 1) Office suites --> Largely a legacy app suite... and web use is increasing for both Office and due to Google Apps. 2) Media Players -- Playing local media is done by native apps, but that is becoming an increasing niche scenario. I posit that Netflix, Pandora, and YouTube dominate other media players. The most important native app that most people use…
I'm sorry to say, but your definitions of "niche" and "legacy" are extremely heterodox and I can't have much of an argument under these semantic constraints.
Not that I think it's particularly true. I think the desktop form factor is going away, but what replaces it is not so much web as it is responsive / adaptive, and web is a subcategory of that, with mobile being another. Having a UI which is only usable through keyboard and mouse sitting behind a desk just doesn't cut it anymore.
Re: Web vs. native: let’s concede defeat
#413Earlier quoted context omitted.
> That it almost works like a 2000 era video player, only slower and clunkier? What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet. You can instantly seek to any part of the video, even if it hours long. You can speed it up to 2x, or slow it down to 0.25x, without changing the pitch of the sound.…
> What are you even talking about? If you click on a YouTube link, a video your computer has never seen before is playing in less than five seconds, streaming over the internet. Nothing about this is "web" specific. That's just "streaming over the internet" as you said. Lots of native apps do it too (for both music and video, internet radio, iTunes video rentals, etc.). The reason we didn't have this as widespread be…
Moving the goalposts. You were saying that YouTube is a slower and clunkier version of a 2000 native app. Now you're comparing 2015 native vs web.
> native is a superset of what functionality is available in a web sandbox
Web sandboxes have a killer advantage over native: no install.
And if we're talking about native desktop, there's another killer advantage of the web: you don't have to trust the app.
Re: Web vs. native: let’s concede defeat
#414Earlier quoted context omitted.
The problem is two-fold: it sucks for web developers who end up having to learn a new shitty framework every day, dogshit tools to even work with CSS and JS, endless preprocessor and transpilers, perverted markup and tag hell to support said shitty frameworks and having to deploy massive fuuckton heavy sites for a simple blog post. It also sucks hard for the end users : they can see their whole months mobile data all…
I keep hearing this argument touted, but if you view source on the HN home page it uses tables and a tag. You do not have to learn a new framework to do things on the web. The browsers all seem to support stuff that's worked for years. The problem is that web developers feel the need to learn new things because they fear getting out of date. "oh, dude, I learned React this weekend. It's hot stuff! You need to learn t…
Re: Web vs. native: let’s concede defeat
#415Earlier quoted context omitted.
Disagree. Currently I'm running Audacity, Sococo (network conferencing tool; soon to be a web app), NetMon, Outlook, WeatherEye and a few services. Also have 3 browser tabs open. So from here it looks like native apps are winning. Especially since I despise two of the three web apps (TeamCity, Jira) for being laggy, buggy and very slow.
OK, but are you a mainstream consumer? No, you're a developer and have specific needs that are solved better with native desktop software.
Re: Web vs. native: let’s concede defeat
#416Earlier quoted context omitted.
> What do people say about it? you want to share youtube comments with people? they are a significant value-add to you?
Youtube comments are great for finding out the name of songs in the background of the video.
Re: Web vs. native: let’s concede defeat
#417Earlier quoted context omitted.
I think UIKit (and possibly Android, which I haven't worked with) has the right idea: nested, texture-backed views that can render their own content. You might argue that canvas and WebGL nodes in the DOM already serve this role, but I disagree. In their current form, these nodes exist inside the document-based world of the web rather than containing it, an inversion of what I see as the proper hierarchy. This arrang…
Beyond views you need a way to layout them. Would you not be simply reinventing the DOM?
Re: Web vs. native: let’s concede defeat
#418Earlier quoted context omitted.
You could easily address those concerns without turning what should be a simple video into a clusterfsck of Javascript. For example: https://mytube.com/$username/my_first_video.ogg With such a scheme, you immediately know who made it - $username - and (if this hypothetical mytube.com built a proper website) navigating to mytube.com/$username would return a list of videos (maybe with some additional routes for playlis…
URLs are opaque strings to the typical user.
Re: Web vs. native: let’s concede defeat
#419Earlier quoted context omitted.
Both Android Studio and XCode will give you usable iOS and Android code from visual layouts. I've found that usually the easiest way to prototype an interface is just to build it for real - it's faster than Photoshop, even. The hard part about X-platform mobile development is that oftentimes you need different product concepts on Android & iOS, because the idioms, best practices, device capabilities, and user expecta…
Both Android Studio and XCode will give you usable iOS and Android code from visual layouts. Well, for some definitions of "usable" and "visual layouts"! Our goal is to make a designer's tool that can output complete, store-ready projects for simple apps and for both platforms. That includes three things that neither Xcode nor Android Studio does: 1) Interface Builder and Android Studio's layout editor are not meant…
Re: Web vs. native: let’s concede defeat
#420Earlier quoted context omitted.
The no-install, and especially the sandboxed environment, is an argument that hasn't been discussed much here yet but which i think is a big factor to take into account. Sure, device and browser compatibility is nice but really, being able to open a news site without having to share my contact list, my location and my photo album is what makes the web a no-brainer. If native installs could cater more for this scenari…
Java offered no-install sandboxed apps well before the webapp craze. But of course being based on Java made that attempt quite stillborn. http://en.wikipedia.org/wiki/Java_Web_Start
But it never caught on because it was a poor implementation of a dubious idea. It started up many hundreds of time slower that Flash, required you to context shift out of the browser, was pretty ugly, and obfuscated the fact it was getting unrestricted access to your machine behind confusing security dialogs.
I think the underlying programming language was the least of its concerns.