When IE gave us beautiful, fast touch interactions, and nobody cared
paulbakaus.com
paulbakaus.com
GNU/Linux is ~2% of the market.
They were responding to glesica's assertion that the reason nobody cares about IE is that it isn't cross-platform. To counter this assertion, adventured said that 90% of the desktop/laptop market uses Windows, so it seems unreasonable that the majority of people would not have access to IE as a reason for not using it.
Adventured was not suggesting that 90% of people are using IE; they were suggesting the exact opposite and asking why that is, because glesica's reasoning seems intuitively flawed.
I'm willing to wager the radical majority of developer work occurs not on a smartphone, but on a desktop or laptop. Whether we're talking coding, design or otherwise. Even the work for smartphone software occurs almost entirely off of a smartphone (with the phone mostly used for testing).
What I'm seeking to clarify from the parent, is the data to support the premise that Windows, despite having upwards of 90% of the market share of the environment being discussed, somehow has a small share of developers compared to eg GNU/Linux (which has 2% of said market share among users). I'm skeptical of that extreme ratio falling so much between usage share and developer share, that it supports the parents position that IE's big problem is that it needs to be cross-platform.
I can benefit all available *nix tools in it's native state ( not run by cygwin ).
I doubt there is statistics for this, but in my mind OS X is the most popular OS that people are doing web-development on.
Although I like what Microsoft are doing lately with TypeScript and many more additions to open source community, it is really hard for me to imagine a switch.
Like you say, it's incredibly difficult to pull any solid numbers for this - Github isn't even close to representative, web server hosting is skewed by domain parking, pretty much any statistic you can come up with to support any side, at least that I can think of, is going to have major problems.
But Windows-based developers have an entirely different workflow that completely obviates the need for Linux tools. Sometimes the workflow is different enough so you genuinely don't need it - the average ASP.NET developer probably doesn't have any need for them. Sometimes the developer just doesn't know any better - and you see that kind on all systems. Sometimes they've developed a PowerShell proficiency or something that lets them use analogous tools in an analogous ways. But this just isn't an argument. It's effectively saying, "well, if you do web development like I do, you need *nix." Well, of course! :) For most of them, it would be equally unimaginable to switch. I think there's very few like me, who have actively done and enjoyed both professionally.
There are, of course, exceptions: I think we can all agree that almost all ASP.NET developers are on Windows and almost all Ruby developers are on OS X or maybe Linux. Most of the amateurs are certainly on Windows - I don't mean that in a disparaging way, I just mean the people just starting out and putting together very simple, possibly static webpages, or playing around with whatever their CMS has set up for them. Then you have all the enterprisey web development, likely mostly internal sites, with somewhat less of a skew, but still probably majority Windows. For the professional, public-facing sort of stuff, I expect its a lot closer to 50/50. Of course, just like you say, it's very hard to demonstrate anything and anecdote-by-anecdote and gut-feeling doesn't really say much.
* bash
* all the GNU tools (grep, less, ...)
* vim
* emacs
* npm
* all the npm tools (gulp, grunt, &c; everything installable through npm)
* gcc
* make
* IntelliJ
* ssh (command line or putty)
It's all here. Without cygwin. The only problem I ever have is performance of the FS on many small files. That's just terrible.
If your corporate policy even allowed that. :P
This is the point issue: "but that it doesn't run on Mac OS or GNU/Linux"
The parent is arguing that IE needs to be cross platform for Mac OS and GNU/Linux. I'm curious if there is data to support that as IE's biggest issue.
I have no doubt that developers are a much larger proportion of Linux users (approaching 100%) than they are of Windows users. I suspect that may also be true for OS X users. But there's simply a huge, huge number of Windows users and consequently, a huge, huge number of Windows-based developers. Not necessarily bound up in the Microsoft ecosystem (.NET and the like), but developing on Windows.
But HNers, who are bound up with a tight-knit community that consists mostly of open source software, Github etc., quite naturally assume that they are representative. (Sidenote: Git and Github also have minority version-control market share. I would not be surprised if the biggest version control out there was no version control at all.)
In reality, I would be shocked if Linux/OS X-primary developers constituted more than one-third of total developers. Unfortunately, accurate statistics are hard to come by.
but Android/Linux is ~50%, and Windows/IE on a phone is 2%.
The parent is talking about developers, and arguing that IE's biggest problem is that it's not cross-platform, and that it needs to be on Mac OS and GNU/Linux because far more developers use those now vs Windows.
My question is: is that true, that IE's biggest problem is the need to be on Mac OS and Linux (emphasis that we're not talking about iOS and Android); and is it true that far more developers (and particularly those relevant to this) are on non-Windows platforms now vs on Windows.
It's not that "nobody runs Windows", it's that "relatively few people who would find snazzy new IE features useful" run Windows.
As for Linux, well, I don't think you'll go far there with proprietary programs. But let's assume a .NET like open source initiative. I'd give IE the application a pretty small market share then, but see no problem at all with programs using the rendering engine, i.e. a common "libIE" dependency.
(And, of course, if it actually is the same engine as on Windows, testing alone would guarantee a lot of installations)
[1] http://en.wikipedia.org/wiki/Tasman_%28layout_engine%29 [2] http://en.wikipedia.org/wiki/Internet_Explorer_for_UNIX
While I wouldn't generally praise (any of) the browsers of that time, Macs really didn't have much competition at that time when it came to web browsers.
Huh, really. When was this then? I remember from during my veteran days of the browser wars (2005-2008 or so), IE for Mac was the only browser that PPK (of the Quirksmode.org compatibility tables) actually outright dismissed and at some point stopped testing for. If I remember correctly, his words were "bug-ridden crash-prone piece of trash".
Hey Michelangelo, sign up for my art class and I'll show you how it's done.
Couching this in difficulties on the developers part is not a long term viable complaint.
The developers were virtually 100% Mac and Linux users. I don't think there was a single developer who actually used IE for anything other than testing features before code was merged. We definitely were not going to use IE-specific features, no matter how cool they were, because almost no one could actually run IE except in a crappy VM.
Maybe if IE was the only browser available on Windows, but it isn't.
"Developers, developers, developers, developers." - Steve Ballmer
Chrome is more widely used than IE.
There might be more gold on the ocean floor than all the gold we have ever mined, but we will never get that gold because its too uneconomical for us to get.
Same goes here, the 5th of the market is a non-consumer market for us. Those days are gone where every computer with a browser was a potential consumer.
At this point we have to ask the question, if you are still using IE, what business assumptions can we make about you, and are you really worth the cost spent to go after you?
Though, I will say you have not asked that last question. At least not in a meaningful. Otherwise, you would not be dominated by the larger fish in the ocean that do go after these customers.
Also, I admit I do prefer a non-monoculture in the browser landscape.
Just because a browser uses Webkit doesn't mean it uses the same version.
I already had to track down CSS rendering issues across Webkit implementations.
Also the JavaScript engine is not the same. Once we had sequence of Ajax calls failing in Safari, but working properly in Chrome.
I don't think Mac OS/Linux has a huge impact here. And as for the inability to test IE, try modern.ie - free Windows VMs with different IE versions. It's not that difficult.
I know that testing on IE is possible, but there's more to it than that. If I'm just going to test my stuff on IE every now and then to make sure it works, I'm not going to focus on, or experiment with cool new features the IE teams adds, because the only time I use the browser is when I boot up my IE testing VM.
If IE ran natively on Mac and/or Linux, for instance, I would spend a lot more time actually using it, not just clicking around my app to make sure it isn't broken before a release.
It's usually advisable for people get them from analytics tools on their own sites rather than looking at global stats. For example, IE stats from my Google Analytics account covering multiple different industries, company sizes, and types of sites and applications range from 6.78% to 13.19%, and I've seen similar numbers on every project I've worked on for at least 4 or 5 years.
It is bloody difficult.
Last time I tried using the VMs, the license expired after 3 months, and the VMs didn't work well under VirtualBox/Linux.
Touch support in particular is completely crappy. MSPointer events in IE10, with horrid corner case bugs. Changed to pointer events (no prefix) in IE11, with different bugs. Windows Phone 8.1 update to IE11 supports iOS style ontouchstart events.
Pinch zoom is different from page zoom, and pinch zoom doesn't act the same as iOS/android.
I hate Microsoft's bullshit touch support.
Oh, and about 0.1% (measured) of our users are using IE with touch... What a waste of my time.
(I admit that also reading the books "The Cathedral and the Bazaar" and "Hackers & Painters" influenced me a lot!)
This is off topic but seriously? You actually felt like you were going to vomit due to a business tactic?
I quit my last job because I could tell my boss had perverse incentives that he wouldn't admit to. I knew the codebase needed a refactor desperately and he insisted I work on something else (because he was leaving and didn't want to rock the boat). I can't work under those conditions. Turns out I was right... After I left, he announced he was leaving... right after his RSU's vested.
When customers start to leave because they hate the way things work, that's when the business bow downs to a refactor.
And if you've never clashed with your boss over ideological or philosophical issues (either productively or destructively), then I dare say you may not care very much about your work. (Or maybe, not far enough along in a career to have enough to say about it yet. I've been doing this for 18 years. I think that if you get to the point I got, where you care more about your work than your next paycheck... that that is a good thing.)
There were actually MANY times when I clashed productively with this guy. I respected him and he respected me. In fact I know that in the final battle we were both simply acting rationally. The directions were just completely at odds. And that is why I harbor no grudge or ill will towards that guy. Hell I'd probably have a beer with him still. I bet you that guy still respects me. It was just time to go.
We can start an entire conversation about how some people care more about their careers than their paychecks and about how some people don't, and about how still OTHER people can't even afford to care more about their careers than their paychecks.
I don't judge. I just know how _I_ felt.
That a business tactic based not on making a better product but instead hurting the market would shock someone unused to such matters seems perfectly reasonable. To feel you were supporting that would just make it worse.
It was also my first job out of college and I was wet behind the ears and perhaps not aware that the real world can be a cold and harsh place.
https://www.youtube.com/watch?v=9jh4Mpgbi4A
:-D
Its a really dumb move, because the percentage of people who upgrade windows to get a newer IE is probably close to 0%. Worse yet, it encourages people to use a competitors product, so when they do eventually upgrade its likely those users will install chrome/firefox/etc and continue to use it.
It was nice, and necessary, to use there because it made it relatively easy to make HTML5 apps that looked and felt like a native counterpart on the same platform. I don't know if they would have fit in on the general web, but it was cool to see them take a crack at nicer touch scrolling in CSS.
Regardless, this is a great example of how innovation should happen. That is browser vendors try out new things, and those experiments that succeed become standardized. In this case it sounds like this experiment is a step forward, but not quite reusable enough to support standardization across platforms.
We need better scroll APIs for sure, but in DOM JavaScript API not in CSS
That is, if you can statically state your scroll points, it would seem that CSS would make sense for that.
If it's in CSS, the browser can fundamentally optimize it better. DOM APIs have to run on the JS thread ("main thread") and contend with GC pauses, image decoding (in some browsers), layout (in all mainstream browsers), painting (in most browsers) and so forth. However, if it's in CSS, it can be proxied out to the compositor thread, which runs very little. This makes a huge difference in responsiveness.
-ms-scroll-chaining: chained;
-ms-overflow-style: none;
-ms-content-zooming: zoom;
-ms-scroll-rails: none;
-ms-content-zoom-limit-min: 100%;
-ms-content-zoom-limit-max: 500%;
-ms-scroll-snap-type: proximity;
-ms-scroll-snap-points-x: snapList(100%, 200%, 300%, 400%, 500%);
-ms-overflow-style: none;
I don't really know if any of that stuff actually belongs in CSS as the majority of people see it (and `snapList` certainly doesn't feel like CSS to me).(The right side of the article text is overlaid by the "Current Projects" sidebar.)
Hell even 30fps is not acceptable for some games (fighting, racing, first person shooters).
So having 60fps in the browser is incredible!
Now that they have finally repented they will still need to reap what they have sown. At least that seems to be a valid principle elsewhere. :-)
(Note that I say this as someone who is currently very close to be a fanboy of "new Microsoft")
Its unexpected when Android and iOS both freeze on the hover state.
Now if only there were a way to make applications that were delivered in the same fashion as documents, but not constrained by the same poor decisions.
It's remarkable to look at where I was 8 years ago compared to now, regardless of age really.
But the worst part of that sentence is the change in tense. ;)
But it's interesting -- people who have worked in tech during M$FT's heyday probably do want to dismiss this argument without consideration. Is the real story here that peoples' unconscious attitudinal memory is long enough that some companies' prior actions can never be forgiven?
Seems like a simpler age.
Really? Shoutcast was created in 1998, Digitally Imported has been around since 1999. I wrote a hacky thing to stream di.fm to my Nokia 3650 over the air in 2004 (the downloadable real media app could stream mp3, but not handle shoutcast data, so I had to strip it out; plus the achievable bandwidth was less than the lowest bitrate stream, so I had to downsample).