Live data from Hacker News

A new Microsoft browser?

quirksmode.org

121–125 of 125 posts

Re: A new Microsoft browser?

#121

Earlier quoted context omitted.

There are definitely supported APIs for extending IE (starting with IE 4.0 in 1997), but you do have to write native or .NET code, it's not "hack together some javascript and CSS" like Chrome/Safari/Firefox. First couple of Google results: http://msdn.microsoft.com/en-us/library/aa744101(v=vs.85).as... http://stackoverflow.com/questions/5643819/developing-intern...

Why " write native or .NET" but " hack together some javascript and CSS"?

Because the latter is a lot quicker to get started with. I'm not making a value judgement.

With the IE model, you need to create a VS project, add a ton of boilerplate (see that stackoverflow example), and generally it's a ton of work just to get started. With a Chrome extension, you get an itch (some website has some jank, or you just want to hide all images with a certain dimension), you peek at it with the inspector, write some lines of JS or a custom CSS file, add an XML file and you're good to go.

Being able to write a quick hack to scratch an itch makes the Chrome/FF/Safari model more approachable. Once you have your foot in the door you're then more likely to make the step to write a full-featured extension (your MVP gave you a bunch of ideas).

It's similar to why PHP is popular. "I have this HTML page and I just want to add this one dynamic visitor counter. Do I want to build a Rails application, or paste in 3 lines of PHP and change the filename extension?"

Re: A new Microsoft browser?

#122
post #118

Earlier quoted context omitted.

Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs. Serious security issues should be fixed as soon as possible anyway. This has absolutely nothing to do with a regular schedule for planned releases, and all of the major browser developers will already issue an immediate out-of-band update for a sufficiently dangerous vulnerability. What argument could be…

Is it not possible to run beta versions of these browsers to catch issues early?

You can, but you still have to test against N different versions per year instead of 1, which is still an N-fold increase in testing overhead compared to annual releases.

You can automate some aspects of that testing to reduce the burden. However, in the nature of web sites, some things will always need manual examination. No unit test is going to tell you that Chrome has a layout bug where your element that is styled to have a 100px width is being calculated at width 50px anyway and your entire home page doesn't render properly as a result, nor that resizing a responsive page in Firefox so it satisfies different media queries and then changing it back to the original size might result in a different layout (both real examples I've personally seen in recent months, BTW).

Re: A new Microsoft browser?

#123

Earlier quoted context omitted.

One of the things I really want to see is both IE and Safari move to the six weekly update cycle that Firefox and Chrome are using. Whereas I would really like IE not to do that, and ideally Firefox and Chrome to move to longer cycles (minimum 6 months, preferably annual) for their main public releases. One good reason for this is that there is no point in having browsers support new features within moments of someon…

I think it shows the difference between Browsers that support Operating Systems and Browsers that have their own internet agendas.

I'm not sure I follow. Could you explain your point a different way?

Re: A new Microsoft browser?

#124

One of the things I really want to see is both IE and Safari move to the six weekly update cycle that Firefox and Chrome are using. IE still has a major slice of the browser market share and this probably ain't going to change soon. IE>9 have all been decent browsers for the time that they were released, although they do seem a bit out of date 6 months later. At the moment, if both Firefox and Chrome implement a new…

One of the things I really want to see is both IE and Safari move to the six weekly update cycle that Firefox and Chrome are using. Whereas I would really like IE not to do that, and ideally Firefox and Chrome to move to longer cycles (minimum 6 months, preferably annual) for their main public releases. One good reason for this is that there is no point in having browsers support new features within moments of someon…

Chrome and Firefox don't support features within moments of someone conceiving them. I've seen discussions about what features will be coming to Chrome in the future - rarely does a feature take less than six months to go from idea to stable implementation in Chrome. Firefox is a little different because Mozilla is pumping APIs into Firefox OS and then moving them to the main Firefox browser.

IE has issues with implementations even with their slow release cycle, as does Safari. While in theory a quicker release cycle probably should result in less stability and more bugs, there doesn't really seem to be this correlation in practice. A good way to check this out is to have a look at caniuse.com and see which browsers have issues with feature implementations (although caniuse is lagging behind a bit of recent). IE, Firefox, Chrome and Safari will all have issues. To Apple's credit, Safari is the only browser which seems to be willing to regularly remove buggy features.

Re: A new Microsoft browser?

#125

Earlier quoted context omitted.

One of the things I really want to see is both IE and Safari move to the six weekly update cycle that Firefox and Chrome are using. Whereas I would really like IE not to do that, and ideally Firefox and Chrome to move to longer cycles (minimum 6 months, preferably annual) for their main public releases. One good reason for this is that there is no point in having browsers support new features within moments of someon…

Chrome and Firefox don't support features within moments of someone conceiving them. I've seen discussions about what features will be coming to Chrome in the future - rarely does a feature take less than six months to go from idea to stable implementation in Chrome. Firefox is a little different because Mozilla is pumping APIs into Firefox OS and then moving them to the main Firefox browser. IE has issues with imple…

While in theory a quicker release cycle probably should result in less stability and more bugs, there doesn't really seem to be this correlation in practice.

Anecdotally, the bug tracker for every major project I currently work on would disagree. That's a fair range of projects, using very different sets of browser features but including quite a few relatively recent developments.

A good way to check this out is to have a look at caniuse.com and see which browsers have issues with feature implementations

Caniuse is great, but it's not even close to the level of detail I'm talking about here. For example, it currently lists no known issues with HTML5 video elements, where IIRC one project I work on that uses that feature extensively was tracking 17 related open issues as of a few days ago, including at least one for every major browser.

When I write about that kind of experience, I sometimes get asked why we don't do more to support the browser developers by filing detailed bug reports when we find these issues. Sadly, the answer is simple: the projects I work on all have relatively small teams and would literally have to hire another full time employee just to report browser bugs, because we find that many. And a heavy majority of them are in Firefox or Chrome.

Post reply on HN