Remember Flash? Narrow the gap, add a bit of Steve Jobs and Boom! The web Won.
Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible. If we've just given up 10 years ago, saying to ourselves that the web should only be for documents, then we would be missing out big time right now.
It’s not for every site to try and push the envelope. And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try. That’s just sad.
And yet any media player beats it at its core functionality: video playback.
Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer.
There even are addons to export YT playlists to VLC and stream them.
pdfjs is great. but every 3rd scientific paper I read tends to be somewhat broken (missing diagrams/images) or sometimes fails to render completely. native readers provide a better experience and better render times.
>And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try.
Maybe sometimes it would be better to provide better integration with native applications?
Native applications and browsers really don't like talking to each other.
I think media playback is only part of the core functionality. The other key piece is discoverability, and on that front, YouTube is far, far better than a native media player. It also benefits hugely from urls, which allow users to share what they've found. So, arguably, YouTube's success is more about what the web does well than about it's media playback -- it just has to be "good enough" on that front.
Of course there are some business realities (ads, copyright, paying for storage) that make direct, free access to videos unlikely. But that's basically arguing that the web is a superior platform for monetizing things, not necessarily a superior platform as far as user-experience goes.
> The other key piece is discoverability, and on that front, YouTube is far, far better
I'll give you that one.
But then again there are dedicated media-discovery-sites (imdb, last.fm) that do not have playback as their core functionality, even though they may offer some playback.
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 is often much more complex than a single raw file.
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 playlists or categories).
Sure, now the user would have to go through the additional work of editing URLs if they want to access this endpoint manually, but then this article's points come into play: if your users expect more functionality than what the World Wide Web does well - delivering content - then a native app is probably preferable for everyone involved (and, indeed, exists for sites like YouTube).
When most people ask, "Who made this" they aren't looking for a character string that matches /[a-zA-Z_0-9]{3,12}/.
They're asking: what person or persons did this, what might I know them for, what do they look like, how popular are they, do they have a logo I might recognize? YouTube and Vimeo provide that information right next to the video, which is where people want it.
If a native app really is preferable, then I'm sure we'll see YouTube wind down their web interface once everybody stops using it. But my guess is that they'll still have an HTML version long after you and I are both in the ground.
This isn't much different from, say, reddit, where URLs are actually part of normal discussion; a redditor will talk about a subreddit called "/r/mylittlepony" or a user named "/u/Unidan" or somesuch, directly referencing paths (to https:/reddit.com/r/mylittlepony and https://reddit.com/u/Unidan, respectively). Granted, reddit's userbase is somewhat more tech-savvy on average than, say, Facebook's or YouTube's, but it shows that URLs are not necessarily opaque to typical users, and it's certainly not hard to even manually demonstrate such things to new users.
This also isn't much different from many (most?) news sites, which provide URLs that resemble the name of the article (with some adjustment to make everything lowercase, turn spaces into underscores, strip or substitute special characters, etc.).
More like any application that interfaces with a JSON-based API. Those API calls work by talking to a server over HTTP(S) and requesting something from a URL.
There's no reason why a native app can't do this - in fact, many native apps for things like YouTube and Pandora and such already do this.
But how would that serve ads to the eyeballs? You forget that most of modern webcontent is just packaging fluff for eyeballs to more easily digest the real content payload - the advertisments.
That's not my problem. If it were, I'd solve it by embedding ads in the video stream itself, which is how traditional video broadcasters have done it for more than half a century. In the audio realm, Pandora already does this with third-party clients perfectly fine.
I would like to complement that native youtube(the one used on mobile) is far better at playback while keeping nearly every other advantage that it has on the web.
> that native youtube(the one used on mobile) is far better at playback.
No, it is not. Playback would get stuck, sound would go away for no rhyme or reason and what not. Better experience? - no - quite the opposite.
I got rid [1] of the native nuisance completely. And the experience of search, comment and history on native was simply terrible. Much lesser control on ad-blocking too, and really the ads on YT are sometimes seriously irritating.
That is irrelevant. I prefer to not have ads and Google is generally kind of to comply and suggest developers respect ad-blockers as well, even though the vast majority of Google's revenue comes from ads. To suggest going native to provide revenue over UX only benefits the provider, not the user.
Well, if I click on the first link, a video doesn't play (that would be the case even if the link were to an actual MKV video). The second URL isn't even a hyperlink on news.ycombinator.com. But if I click on a valid YouTube link, a video plays nearly immediately.
Do you feel you made a point by listing services that exist only by breaking the law to exist as somehow related to business reality? Making your money by trampling the rights of others isn't exactly sustainable. The only way you have a point is to be rampantly intellectually dishonest, or ignorant of reality. Neither option is great, so charitably, it's best to assume you know this stuff and you're just trolling. Also not great. Do you have a 4th option?
I think grandparent just wished to say that "direct, free, downloadable videos" are technologically possible at large scale via p2p. Mentioning copyright is a bit off topic. It's possible to create a paid p2p service for video, and have tons of viewers without spending millions on infrastructure. Hence the bit about "business fictions".
>Making your money by trampling the rights of others isn't exactly sustainable
Well said, you should tell this to Disney, MPAA, and MAFIAA so they'll stop trampling the rights of the commons by extending the length of copyrights everytime something profitable to them is about to expire. https://en.wikipedia.org/wiki/Copyright_Term_Extension_Act
The violation of IP is a similar problem for torrents and YouTube alike.
The "4th option" is that you've got the causality completely backwards in your head: it just happens to be the case that the cultures where distributed tooling became important were the ones where it was necessary to promote an "all information is free" mindset, not that it's necessarily a part of distributed tooling that you take that mindset.
If we start with a centralized metadata server/peer tracker, a set of "base seeds" to keep videos alive, and a commenting system, we can still revoke access to individual videos (our app will simply not support peer discovery except through our tracker, we take down the seeds, comments, and tracker entry on a revocation) while distributing bandwidth for the viral videos that need it.
> The violation of IP is a similar problem for torrents and YouTube alike.
Not at all, YT solved it many years ago with ContentID.
Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.
> Not at all, YT solved it many years ago with ContentID.
Sorry, there is some ambiguity in English about this. I am regarding a "solved problem" as a "problem" (i.e. classification) whereas you are regarding it as "no longer a problem" (i.e. interface). Yes, right now YouTube's interaction with the problem is highly limited (though not nonexistent), but if one is, say, trying to disrupt YouTube or talk about YouTube's history, one still classifies it as a problem in general that exists within YouTube's problem domain.
> Now imagine having to install all the plethora of apps on every device, one for videos, one for music, 500 for different types of documents, etc. Instead, you install a (hopefully) standard-compliant browser, and done.
I mean, I agree that it helps that particular problem somewhat to have a cross-platform virtual machine (the browser) and to distribute an executable (your JS app) on that machine rather than (or sometimes alongside) your content. This also creates its own problems, of course, like simpler browsers (spiders, text-only browsers) not being compatible with your website, as well as some new buggy issues when, say, the JS doesn't load properly. But HTML+CSS+JS is not new in this town and the cemetery has some gravestones -- like the fact that there aren't many desktop Java applications, the complete failure of the Java browser plugin, and the waning of the Flash plugin. It is peculiar among these only because its dreams are less lofty: not "write once run everywhere" but "write once, then write a (hopefully graceful) downgrade path if they do not support the features that I want to use."
>> The violation of IP is a similar problem for torrents and YouTube alike.
>
> Not at all, YT solved it many years ago with ContentID.
I'm not sure I understand. AFAIK youtube currently makes money (from ads) and much of what people view is copyrighted music that isn't properly licensed, and which yt doesn't pay for.
Sure, some, music is taken off yt, and some content is properly licensed -- but are you seriously claiming that yt isn't (any more) making money from copyright infringement?
There's some digital content distributed via p2p legally -- and it'd not be a stretch that yt owes it's current market dominance to "flaunting copyright law" as the copyright lobby might put it.
If one relegated content (video, meta-data, comments) to torrents/magnet-links (there is an issue of loops in the links in content-addressed systems -- but with a pretty modest central server (cluster) serving up a few lists of magnet-links should be affordable)) -- I think it would be quite feasible to distribute digital media in way which the consumers shared in the meagre cost of distribution through mostly donating bandwidth.
>imagine having to install a plethora of apps on everydevice...
Well, I don't have to imagine this because Youtube and Netflix both make you install apps. Flash and silverlight. You can opt-into the html5 streaming on yt, but that's still a change you have to make.
I would compare and contrast the experience you are describing with a podcast player like pocketcast.
Synchronized play state and playlists on all the devices. Offline handling of the media files with streaming as an option. Feed subscription but also podcast repository and ranking/trending screens.
All media files are by definition in independant feeds, and sharing a file URL is supported.
It brings a hugely better experience than youtube pr any online video service I've seen. I actually switched to my podcast player all the youtube channels that also have a separate feed.
I think youtube is on your side, as it's heavily biased toward random one offs video watching.
I'm always baffled by the suggestions when watching videos from some common series. There would be mostly accurate suggestions, and consistently two or three videos completely unrelated taken from my viewing history. For instance there would be 'Howto repair your dishwasher' in the middle of all the videos of a math channel.
I tend to massively subscribe to channels and watch in batches, so I have (and want to have) a very good idea of what's coming next in my queue.
Before flash could play video, links that open in the media player of your choice were very common.
It was a nightmare. Each media player would try to hijack every link type it knew about each time it ran. But there wasn't full compatibility. So you'd click a link, RealPlayer would try to open it, and the player would crash.
The major players actively fought open standards, because they each had dreams of controlling a DRM & patent gated empire.
Flash brought some sanity to web video. Although initially it had performance issues (it had issues with hardware overlays on some video hardware).
I wouldn't say "initially"; Flash is still notorious for severe performance issues. That said, so are most native media players nowadays.
With that said, I'd be more optimistic of a kind of "media plugin renaissance" like what's being discussed in this day and age than I would be back in the 90's, what with all the insistence on standards-compliance and all that jazz. Eventually, with platforms like the .NET CLR / Mono catching on and becoming increasingly popular for cross-platform "native" (not quite native, but much more native than web-based) development, the chance of successfully reaching the goal that Java tried (and - arguably - failed) to reach back in the 90's is much higher nowadays.
I'm a bit less optimistic. Having different programs for each content type would restrict the developers' control into how they can interact with the users.
Simple playback of video? Not so bad. But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'? YouTube-like annotations? Show suggested videos after? Developers aren't going to want to support all environment configurations, so you'd likely end up with a separate supported player for each website.. which doesn't sound better than visiting a webapp tested against the popular web browsers.
Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.
> But if you want to swap the source of the video to your 240p version if the video is buffering 'too slowly'?
This sounds like something that should be a feature of the protocol used for streaming (in fact, I'd be surprised if most streaming protocols didn't support such functionality). Even without, this should be possible to do even with a native media player, and many streaming providers offer streams with different bitrates and encodings and such (for an example, check out soma.fm).
> YouTube-like annotations?
Most video players have subtitle and even captioning support; it shouldn't be hard to extend this to arbitrary annotations, be it as part of the streaming protocol, part of the media encoding, or even as a separate stream or file.
> Show suggested videos after?
Could be hypothetically done with an API call on the player's part to the video source (or some other source that indexes videos), which then provides the list. The player could then display said suggestions.
All three of these things could be worked around with a standard "metadata" path that such a video player would access and fetch an HTML page or JSON/XML document or somesuch.
> Developers aren't going to want to support all environment configurations
Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0. I don't use separate web browsers for different websites, after all.
> Additionally, there's a lot of great research going into browser sandboxing and user-driven permission granting. Allowing content-compatible-but-unsandboxed XYZPlayer to take over content playback negates a lot of the potential benefits.
Part of the issue is that operating-system-level sandboxing has historically been insufficient. Bringing some modern server-grade sandboxing techniques (containers, VMs, chroots, etc.) to the desktop and mobile realms in an easy-to-use manner would alleviate the need for browsers to try and implement this themselves.
I agree that those are all methods of solving each issue -- but I think expecting each player to implement them (and correctly!) is the real problem. And when the standards don't support the feature they want, many developers would fall back to the web. It's hard to compete with a full-featured layout, style, and scripting implementation when it comes to customization.
Nor should they; they should instead support agreed-upon standards, like how web browsers support agreed-upon standards for HTML/CSS/Javascript files and HTTP(S) 1.x/2.0.
There are web standards now, but, in practice, when you're supporting multiple environments, you're also testing against them. For webapps, fortunately, this usually just entails testing the top 5 browsers for a few versions, and mobile devices if you support them.
If the user comes to support saying something is broken with the video on their native app, trying to troubleshoot their native environment can be difficult, and telling them that their environment might be configured wrong often doesn't solve their problem. Which is why I suspect each site would support specific players.. not being a real improvement over the Gecko or WebKit <video>, <audio> in my mind..
Netscape could do this back in 1995. One of its preference settings let you associate external applications with certain MIME types; when you clicked on a link pointing to a resource of that type, it would automatically open the external program to view the file, as if you had double-clicked on it.
Similarly, you can do this right now on Android. When you click on a link, it fires off an Intent with the URL. Apps can register for this Intent and the user will be prompted for what program they wish to handle the link in. This is how the official YouTube/Google Maps/G+ apps work.
It turns out that for certain types of content, users really, really don't like to wait for external programs to load. It's not a technology issue; the technology has long existed to use rich clients, consumers just don't prefer it.
> It turns out that for certain types of content, users really, really don't like to wait for external programs to load.
And yet they click through full page ads, wait for "loading showcase" animations, scroll past parallax scrolling banner images and also wait for the ads on youtube videos and for the video to switch from 360p to HD.
Users are strange creatures.
I think if some effort were put into streamlining the native <-> web boundary then users would be quite happy with it.
> This is how the official YouTube/Google Maps/G+ apps work.
The question is, could this be standardized further? Basically a web standard that browsers agree to when it comes to talking to native apps that might offer specific services.
At the risk of getting stoned to death for this: WebD-Bus?
Although I think anything like that isn't going to happen. Browser vendors put security over everything else. Talking to native apps which already have access to the system would probably be construed as some sort of security risk, even if the user had to opt-in.
Ads exist in Native apps as well. At least in the web I have the option of browser extensions to provide a more customizable UX. With adBlock I don't get Youtube ads on Chrome so that point is null.
As for the last point, Spotify has some version of this. My native (mobile) Spotify app knows when I'm playing on my computer and vice-versa.
>It turns out that for certain types of content, users really, really don't like to wait for external programs to load.
I'm not sure how that's a valid point. My native media player loads in literally less than a second. (I timed it at 0.59s from when I double-click a file and it starts playback.) This is faster than any webpage can ever dream of loading. And unlike Flash or HTML5 video it gives me completely hitch free playback, whereas browser integrated player tend to drop frames quite frequently.
I would much rather use it than any player integrated into a web browser.
It wouldn't be hard to make that work on other sites that have a flash player. But we aren't quite sure if it improved the performance or anything, it just felt right.
This is an issue with the service not providing direct links to the video.
If you open an .mp4 file in Firefox you can set it to open in an application through your "Applications" settings. By default it prompts "Open with..." or "Save as..." in a dialogue.
If you open a direct link to a video you can open it to play in VLC (or player of your choice).
Some (most?) browsers still do this when presented with a media file. Firefox in particular will use VLC on my machine for that purpose (or, if it's not installed, some HTML5 barebones media player, or some other media player that can be embedded if one is installed).
the point is allowing independent applications to talk to each other (IPC) not to tightly integrate one application into another, that's a big difference.
Does anyone remember Google Video Player? I remember installing this to try and play videos and being disappointed that it was basically VLC with a rename and much functionality removed.
You mean, being able to set media type handlers for your web browser?
I seem to remember being able to do that two decades ago. I imagine you still can (assuming you're up-to-speed with the configuration UI of the week for your browser), but it's not something people seem to do a lot.
But having URLs or discovery or social features is orthogonal to using web tech, especially in the front end. Eg. Spotify had all of those in a tight little native client, before they rewrote it with web stack with controversial results.
YouTube's video playback problems might have nothing to do with the web. Despite having an iPad app that is otherwise mostly great, their iPad video player itself is abysmal. It's just flat-out broken, and they're presumably not going to fix it. If you start playing a video, the timeline at the bottom will start turning grey from left to right to indicate the part of the video that is buffered. But if you scrub to a position in the timeline that is buffered, the video player will spin for a rather long time, and sometimes just spin forever until you scrub to a new spot or manually change the video quality. Bizarrely, if you scrub to a position in the timeline beyond the buffer, the video will load nearly instantly like one would expect. Somehow the buffered video loads slowly, while unbuffered video loads quickly. It's a huge bug, it's been in the iPad app for as long as I can remember.
That happens frequently on the desktop website YouTube too. It also happens on my Android phone using the native app.
Related to that, if you try to scrub to a position BEFORE what you are watching right now (say, 1 minute before), which is obviously buffered since you have just watched it, it goes full loading-retard again. It's like it just throws away the data it buffered and showed you. It is insanely infuriating.
Yes, that is my workaround as well. I also sometimes use the jailbreak utility VideoPane to extract the iOS-native video from the YouTube app and play it in a popup. You get the native video player and controls, and funny enough, it works wonderfully.
Youtube's HTML5 video playback on my 3Ghz i7 is so bad that I rarely watch videos in browser. Now it's even worse as all videos play in low quality unless you use DRM enabled "tech".
This is what I use instead: mplayer -fixed-vo $( youtube-dl -gf mp4 $* "$link" )
HD-DVD was cheaper and required less immediate infrastructure changes, but rather allowed a staged switch from DVD.
Blu-Ray is the one that was better.
Actually this is exact reverse of a Betamax story - better and more expensive long term improvement won over short term and cheaper one.
You seem to be under the misunderstanding that video playback is YouTube's core function. No, the core functionality is to drive traffic to Google-owned sites, to be monetized as they see fit.
>And yet any media player beats it at its core functionality: video playback.
I would argue YouTube's core functionality is "making it easy to share videos with family, friends, and the world". Allowing playback of the videos on the page makes this functionality easier.
>Often I find myself using youtube-dl to fetch a youtube video and just play it in a regular media player because it just works better than what browsers have to offer.
I do this too - although only because an addon I have causes Firefox to memleak if I leave a YouTube tab open too long. Rather than finding the problem and fixing it - I download a video I want to watch and close the YouTube tab. Honestly my video player of choice (MPC-HC) does exactly what the YouTube player does. It plays the video. Not a whole lot of bells and whistles needed to do that.
Youtube used to be better before at video playback, not as good as VLC but much better than what it is today. I think they have to deliberately hamper the user experience in order to save bandwidth, just imagine how much bandwidth youtube must cost with the amounts of users they have. Even their native android app isn't exactly the greatest which makes the web vs native comparison a bit easier.
Examples of this hampering is that they only stream 20sec ahead instead of the whole clip in one shot. There are many other annoyances like this, like not giving you the HD version even though it says the video is HD and you've selected HD, or when it re-streams the movie when you switch from windowed to fullscreen, probably because the windowed version was too low quality.
web and native will eventually merge to the point that for most intents and purposes the user can't distinguish between them. It'll never be perfect, but it'll be "good enough", that whether an app comes from the web or from the HD, the user won't really notice except perhaps in the initial startup time, and probably not even then (everyone expects to "install" an app).
> And yet any media player beats it at its core functionality: video playback.
But can you build a democratic 24/7 music/video feed with a native video playback app? Maybe, but it is much easier with the web. And it has already been done:
> And yet any media player beats it at its core functionality: video playback.
That isn't its core functionally, it's a social video sharing site, not a video playback site. It's core functionality is social sharing and all that goes with that, comments, related videos, channels, etc.
shhhhssss there is no such thing as youtube-dl! I believe that the tool should be like Fight Club or it gets noticed and gets shut down through a drawn out war of changing code and apis.
Youtube is an interesting choice of example, since in a way it's "just documents" - those documents happen to be video, and are surrounded by hyperlinks to other video's pages. The real achievement here was cutting through the intellectual property thicket so that everyone could have an in-browser video player in HTML5.
The first site I ever saw that used Javascript to produce a useful application rather than annoying frippery was Google Maps.
(Rhetorical question: why does everyone use youtube rather than hosting videos on their own sites? Unpacking this question will show the obstacles that "redecentralisation" faces)
>why does everyone use youtube rather than hosting videos on their own sites? Unpacking this question will show the obstacles that "redecentralisation" faces
Two reasons: Bandwidth and Speed. Google has contracts with most major ISP's for caching Youtube videos. This gives them access to the best CDN money can buy! No matter how awesome or powerful your current datacenter/CDN is, it still wouldn't be able to match the fetch-straight-from-the-ISP performance. Interestingly this also creates a hidden monopoly since the barrier to entry is costly.
It's more than that. There's also legal liability (very few people would be comfortable hosting the amount of pirated content that appears on YouTube, nor would they have personal bandwidth for DMCA takedown requests), discoverability (YouTube recommends content you've never seen before, intelligently...by definition a personal site can't do this), and search (which only works when you have enough content to be worthwhile to search over). All of the algorithms used for the latter two points require a good amount of data, so Google gets large economies of scale there.
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 allowance get pissed away on a couple of bling websites. It can takes ages now for modern site to finally work as it downloads so much shite. Some big name sites used to render quicker five or ten years ago.
At least in the past, you could turn off scripting, images and styling and get to the basic content, but not even that works now due to crap developers.
It all sucks. Diseased turtles all the way down.
I keep hearing this argument touted, but if you view source on the HN home page it uses tables and a <center> 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 this."
No, you really don't. You have a plethera of choices, and one of those choices is to rock it like it's 1999.
You don't need to know the new hot stuff if (a) you currently have a job and (b) that job is with an employer where people carefully think about their user needs, product goals, and then pick tech and write code with those needs in mind (much like the article recommends).
Otherwise, there's an extent to which you have to accommodate the absolutely rampant fetishization of current fashion for How We Do Things Now Because It's Better(TM) so you can sell yourself properly.
In more concrete terms: right now if you're looking for a gig as a front-end dev, you're going to have a much easier time finding a job if you can put Angular and React on your resume. The fact that this isn't particularly rational (or fair) as a hiring filter doesn't really matter.
If you're good at web development... that means you understand HTML, CSS, and JavaScript and you understand them at the level you should if you want to call yourself a web developer, then learning whatever framework a hiring manager wants you to know this week is trivial because you understand how the web works.
The problem is a lot of people just learn Angular for a gig. Then they leave 12-18 months later and go learn something else. It's never enough time to actually get good at anything.
And let me tell you... the hiring managers are taking instructions from development teams looking for talent. Those teams often inform management what is the hot new tech that needs to be used. But none of these things that people think they need to know have been so battle-tested yet that they are for sure the "next big thing."
I think experimenting is great. I don't think developers should worry themselves to death over having to keep up with whatever's new this week. I think devs would be better off investing that time in getting really great at the web. Really learn what semantic markup is. Really understand floats, clears, various display types. Really understand the fact that the web, without any JS or CSS, works great on mobile, because when it started, screens were 640px wide, and as a gang of developers, we've layered on boatloads of code to make it not responsive, only to make it responsive again. :)
And then, I believe everyone will be in a much better position to make informed decisions on whether or not "hot new thing this week" is really worth learning.
I'm a little puzzled about the "I disagree" part -- it sounds like you and I have some similar ideas about how things should be for front-end development!
Perhaps where we part ways is on the question of whether the industry leans towards sensible agreement. My impression is that it doesn't.
I can't help but feel like a lot of this has to do with "business realities", but maybe more importantly, it is also due to a whole generation of "developers" who have simply failed to learn CS fundamentals or did not start out with more traditional languages. The bad practices of the web are far easier to spread
The framework problem is a real interesting one... I'm a hobbyist--I am not employed as a web developer, but I like too experiment and see what I can create, so for me, learning a new framework is always a fun little project to embark on.
At the same time, i can't imagine how hellish it would be to work for a company that always wants to use the latest technology -- the framework market seems saturated to me, and I would wager it's probably better for a company to find a few technologies and stick to them, tackling problems/weak points as they arise and brewing custom solutions for those if necessary. Having to stop and shift over to a new framework every now and then seems like it would be a massive productivity hit.
I also don't like it when a framework becomes a crutch. Though I don't think that happens too often for most people.
I've also run into the heavy weight problem -- there have been a few instance where I've wanted to create something simple, and in most cases using a framework in that situation becomes the very definition of over kill. So instead I'll usually just write a simple php script or something to do whatever I need to get done, but even that feels a bit unnecessary. While I'm not sure if javascript should be elevated to all the use cases it has been recently, I do think it should be a language that enables a developer to natively(that is to say, w/o a framework) handle any simple functionality that might be expected for a site that is just a little bit fancier than a static site, so handling very simple data such as bare-bones blog or a simple mailing system. While it is getting there you still can't do something like write a simple form based mailer in pure js as far as I know, you can only open the client's native mailing app. You'd have to write a single php file or some other mechanism for that simple purpose.
But yeah, it seems like bloat is a tricky thing to avoid these days, especially since frameworks are the easiest, usually most error proof, and quickest way to get your website full of some modern bells and whistles, when in reality you may only be putting half of the technologies features to use.
Sure. And you're also made out of meat and will die soon. And we're living on a planet that is in the long term doomed even if we half-evolved, tool-using monkeys get our shit together. (Did you know that we're half-way through the lifespan of forests? [1] That one day the conditions just won't be right for them anymore? That never fails to sadden me.)
But the interesting thing to me is what happens when we move past the existential despair that comes when we first recognize the true nature of things. Sure, things are fucked, but they always have been. What's next?
When I was as bitter as you sound here, I took a break. Burnout sucks. But eventually I found myself coming back to technology because it's my best chance to make the world suck slightly less. Or, put more accurately, to shift it in the direction of my irrationally high ideals.
So maybe take a break? Go hike the Pacific Crest Trail or work on a goat farm or something. You're not going to help anybody, yourself included, by soaking in something you hate indiscriminately. At least rest until you can come back and focus your hate in a laser-like beam on one particularly awful thing.
He didn't say all technology is diseased. He was talking about the web. Writing native applications is still as fun as it has always been. Not that there isn't disease there too, but it isn't scripted and marked up to hell like the technostew that is the current web, which is what the parent was describing.
>Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible.
What exactly is incredible about YouTube today (apart from it being a huge repository of videos, of course)?
That it almost works like a 2000 era video player, only slower and clunkier? The new fangled DRM? That it can bring a decent computer to its knees with the fans blaring playing HD video? The automatic non-skippable ads?
> 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. If you have a Chromecast, you can display the video on your TV instead.
Nothing in 2000 had a remotely similar feature set.
>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 before was limited bandwidth connections (a limitation of internet, not of being native).
>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. If you have a Chromecast, you can display the video on your TV instead. Nothing in 2000 had a remotely similar feature set
Again, nothing about what you describe is web specific. Native can do it all and do it better and with less battery crippling cpu usage.
And nothing described -instant seek, pitch shifting with retime, etc- was impossible in native video players in 2000 (or even 1995), while all of it was impossible for the web in 2000.
Which also means things possible for native apps now are impossible for web apps now, which makes sense since native is a superset of what functionality is available in a web sandbox, and with faster potential speed. (And of course being web is not a requirement for accessing internet resources).
> You were saying that YouTube is a slower and clunkier version of a 2000 native app.
You said: "Nothing in 2000 had a remotely similar feature set."
Not that Winamp 3 (released in 2002) was a svelte piece of software[0], but it could do realtime pitch/speed shifting and stream audio and video from the Internet. With a sufficiently fast connection, three seconds from link click to video stream start would be quite doable.
Streaming and decoding audio and video isn't anything new. The two new things that The Web brings us are "zero-install" and a the benefits of the large amount of sandboxing work that's been put into the major browsers.
[0] WA3 was slow because of the UI code, not because of the media stream and decode code. :)
Discoverability, and elimination of the downloading friction.
YouTube is about as proven as you can get. The fact is that it didn't just edge past 2000-era video players in popularity, it totally trounced them. I think we should try to figure out why that is instead of arguing against YouTube's viability—it's about a decade too late for the latter.
>The fact is that it didn't just edge past 2000-era video players in popularity, it totally trounced them.
How many people watch movies on YouTube? Because that's what video players are used for, not for small videos, music clips and curios.
>I think we should try to figure out why that is instead of arguing against YouTube's viability—it's about a decade too late for the latter.
We were talking about it's performance compared to native, not it's viability.
YouTube rules as a huge video repository. Other "web" apps that don't have that stronghold, don't fare so well compared to their native counterparts, especially on mobile.
It's interesting that you mention YouTube, because the thing that finally convinced me that a 'web app' could be indistinguishable from a native app was YouTube's Leanback interface (YouTube TV). Check it out:
Is it only for mobile? I didn't see any "mob" or something in the URL. Anyway, with regards to being indistinguishable from native, I guess there is nothing quite like being reminded that you are "native" than an app complaining that you are on the wrong native device. :-)
In Firefox (my default br.) the message is: "Youtube on TV is not supported on this device, for more info go to: www.youtube.com/devicepartners" which is unclickable and unselectable. Modern web...
You can spin this either way. Clearly, the web is just another UI for "your data." It's going to have a different set of tradeoffs than native or mobile. Why not just use tools for what they are the best at?
MPlayer can kick the pants off of YouTube in some contexts. Likewise, MPlayer wouldn't be viable for a vast number of YouTube use cases.
I can benefit tremendously from using both Audacity and SoundCloud. Why does one have to "win?"
> It’s not for every site to try and push the envelope. And mimicking native can often lead to bad results. But to go from that and say that we shouldn’t try. That’s just sad.
The article says exactly that! It just says we shouldn't shoehorn native stuff into the web (e.g look at Synology's UI mimicking a nested desktop and windows).
> We shouldn’t try to compete with native apps in terms set by the native apps. Instead, we should concentrate on the unique web selling points: its reach, which, more or less by definition, encompasses all native platforms, URLs, which are fantastically useful and don’t work in a native environment, and its hassle-free quality.
Youtube example perfectly fits that bill.
Yet there is also a critical difference to be made between "the web" and "web technology": while the former is operated in a browser, platforms such as Electron leading to apps such as Atom or Slack that totally don't try to mimic the native platform they're running on, powering cross-platform applications that nonetheless do try hard to respect† the platform they're running on, achieving something Java's cross-platform WORA GUI toolkit thoroughly failed to††.
† there's a clear, visible boundary between the native system and the webtech app, but that boundary is easily crossed, whereas historically we've been trying to erase the boundary and pretend it doesn't exist, only to veer straight into an uncanny valley.
†† dare I say Firefox sits right there too, forever battling the tide of mimicking native components with each OS release, from UI elements appearance (vanishing scrollbar, input fields...) to behaviour (non-"sheet" modal windows on OS X), in subtle but aggravating ways, if only because it erodes the product's image and detracts development resources from other efforts.
Maybe I'm misunderstanding something here, but I don't think the argument is to cede the web to documents, but I also don't think the idea is to cede all functionality to apps.
I think the problem is the hype about native apps and everyone wanting an app without understanding their purposes, utility, and unique characteristics. There are situations where a web app / site is the exceedingly more appropriate solution, but there are other uses where a native app is equally exceedingly more appropriate. The problem is that people are having a difficult time discerning the two and the appropriateness of each.
I don't agree with this article and the sentiment about the critical question being whether people want your icon on their homescreen as being the differentiating characteristic. What is not discussed is the possibility for putting the icon on the home screen as a link to a web view that can function the way a native app can function. It even addresses a question regarding distribution if you simply ask your user whether they want to "install" or add an icon to their homescreen to install your "app" / web app / site. It can be designed in such a fashion that it is indistinguishable from a native app of a certain type that has rather narrow requirements.
Youtube is the first thing I point to apps on my mobile devices... Why would you ask your phone to dl megs of crap everytime instead of having instant video load?
Over the chain of ownership of any website I would say starting out trying to mimic a native experience will inevitably lead to a bad UX. Maybe not at first but it will. Part of the reason I use HN as a web site on my phone/tab is because it doesn't try to get fancy and just gives me a great web experience. Shocker.
I'm not sure we'd be missing out; the abandonment of the document model has cost the web much of its democratic, decentralized usefulness, and it still isn't a very good application platform no matter how hard people try to make it act like one.
>Look at a site like YouTube today. All the tooling we've created and all the progress of the open web platform that has made that site happen is incredible.
Flash DRM replaced with another closed source DRM. No progress whatsoever. And now it has embedded in the browser itself, greatly increasing its vulnerability.
