The First Browser Dedicated to Developers Is Coming | Hacker News Reader

The First Browser Dedicated to Developers Is Coming

blog.mozilla.org

618 pointsflardinois198 comments

This seems to reinforce the mindset that the web should be experienced and built using different tools for users vs. developers, and aside from thinking that's fundamentally condescending, I don't see why new tools couldn't simply be extended from FF's 'web developer' menu into a different mode of operation or even extensions.

I think we're better off in a world where kids don't have to install ScaryFox on their tablets to start teaching themselves how to debug web applications, and deal with all of the various forms of other-ing that tend to alienate people away from starting to learn how to understand and help build the web.

I think it's actually quite important for Mozilla to assume that of course every user deserves built-in access to a high-quality suite of tools for debugging by default.

I understand the point, but I think there is a reality where developing and actually experiencing the product can be fundamentally different.

For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel.

Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite.

As you mention, settings in the developer tools could allow a myriad of options to switch from a "user" mode to a "developer" mode. But honestly I'd understand if it happens to be easier to build two different applications, even just for keeping the "user" side code simple enough to make it easy to maintain and secure.

Then eventually bundle the two apps together if you want to keep the "tools" right next to the "viewers".

I don't quite see it that way.

> For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel.

I don't see any inherent conflict between preventing sites from having access to the local filesystem, while having powerful local filesystem access from the browser's integrated devtools. One does not exclude the other.

> Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite.

Caching rules should be managed on the server, not the client. Properly configured servers/applications never need anyone to clear their caches explicitly. I don't see why you would need a special cache-less mode in the browser if you've set up your servers correctly.

In my view developer modes (in browser or framework) are counterproductive because they create discrepancies between how your users experience your site or app and how you experience it. Your browser should have the exact same app experience as the one your users use, so it shouldn't have any special developer-mode behavior. That doesn't mean you don't need powerful inspection tools, just that those tools should be built around that standard experience instead of altering it.

WRT caching, the experience of a developer is already completely different from that for a user - assets on a dev instance of you infrastructure (including both code and static files) are changing multiple times a minute.

I don't think that should necessarily be the case. By persisting resources in the cache after they are changed on the server there is an implicit promise of broken user experiences, since there is no control over which files are loaded from cache and which ones are not (so even for "harmless" images users will see mismatched artwork in the real world). Whatever caching strategy is used for production servers, it should involve a way to make sure users are fetching the latest version of a resource. The dev server can be configured identically and it will still do the right thing. Admittedly when you throw CDN's and other intermediates into the mix it becomes harder to have matching environments, but differences should be minimized as much as possible as a matter of development policy.

My dev server is set up identically to a production server, except that no concatenation or minification is done. I'm not happy with that last compromise, so fingers crossed that HTTP/2 gets here soon and we can stop concatenating, minifying and otherwise perverting our code and resources.

This is a lovely dream, but what if you're working on the caching software instead of the web app?

This discussion reminds me of Nescape Communicator of the old days, where a WYSIWG editor was bundled with everything else. Discovering HTML for the first time I actually used it to build small sites, but it got too heavy while being too limited very fast.

What I am saying is basically that I think we need powerful inspection tools, but Frankensteining editing and compiling tools to the normal browser would result in something way too complex, with lots of modes and settings to adjust, and it doesn't seem like a healthy path for something that is supposed to be user friendly, lightweight and high performance for everyone else.

In a way, I am afraid Chrome is precisely going in this direction, including all the features for the normal users (the Flash plugin for instance) with also progressively more and more power tools only relevant to developers.

> In my view developer modes (in browser or framework) are counterproductive because they create discrepancies between how your users experience your site or app and how you experience it.

I think we agree on this point, and having separate tools for building and testing a site would allow to switch between the two mindsets more easily. The testing would be done exactly on the same app, so on the same footing as the users, and not on an application with some hybrid half editing/half testing state. There would be fewer "it works for me, what's your problem people ?" moments I think.

Its not always caches being out of date, what about reproducing bugs that happen on page load? Sometimes you just need to force a fetch.

>For instance the security model for a browser should be ultra tight and protect the user from the site, but as a developer I'd want to access and modify my files directly through the inspector panel.

https://code.google.com/p/chromium/issues/detail?id=328026

>Another example would be the use of cache, where I want the minimum possible retention while a user would want the opposite.

Chrome Inspector -> [x] Disable cache (while DevTools is open)

Or Firefox Dev Tools -> Settings -> [x] Disable Cache (when toolbox is open)

I suspect a lot of the "dev edition" will just be a different set of defaults :)

> https://code.google.com/p/chromium/issues/detail?id=328026

Interesting. I think there is also a plugin for WebStorm to send back modification made in the style panel to the actual files. Sadly sass/less resources makes it difficult to edit CSS and have it applied back to the sass source for instance.

> Chrome Inspector -> [x] Disable cache (while DevTools is open)

Yes, that's what I use for all my projects. Also there is a "Disable Caches" option in the Develop menu of Safari.

A fellow developer in my office uses Incognito mode, and it seems to work fine for him.

That reminds me: It would be nice if you could open several different incognito windows, each with their own session. That way one can debug user interactions without needing as many browsers as users in the interaction (or half of it because each browser has it's own incognito session in addition to the normal session).

A workaround that I've used before is to connect to my site via the domain name in one tab, and the IP address in another - cross domain protection ensures I get two nicely partitioned sessions.

Yep, I also used that. And several entries in /etc/hosts.

These are great points but also speak to one of my concerns about forking--what if Firefox continues to receive lots of security scrutiny but this new-but-still-pretty-intimately-related product aimed at devs mostly doesn't, for whatever reason (e.g. far fewer people using it)?

I see more value for both developers and users currently because it means that in order to keep Firefox safe (for some definition of safe), the Mozilla security team also has to keep people like us--and the functionality we use--just as safe. It also means derivatives like the Tor Browser Bundle and Iceweasel might be more likely to preserve the feature set and benefit from security team's work in relation to it.

A live example: If you are developing a chrome extension on Windows, everytime you open Chrome you'd be bugged with a popup which suggests "Disable Developer Mode Extensions". [1] Although developers are annoyed as hell, the Chrome team insisted this decision on the ground of protecting users.

[1] https://code.google.com/p/chromium/issues/detail?id=337734

Their point is entirely valid though, and it all boils down to: there is no such thing as a secure backdoor.

I'm not sure I see condescension here.

Everyone does deserve access to built-in, high-quality tools. And everyone already gets that, with all major browsers. No one is taking away the built in developer tools in Firefox, Chrome, IE, Safari, or Opera. The problem is that they're always just a little bit older than the tip of the current development branch. And that's fine for folks who are starting to teach themselves how to debug web applications. Hell, that's fine for most people, developers included.

But there's a lot of development happening in this space, and sometimes you need access to tools or features that aren't yet stable enough for wide release. So you download Firefox Nightly or Chrome Canary. And you flip on something in about:config or enable experimental web platform features in chrome://flags. And you're off to the races.

That's not dividing the web, and it's not giving different tools to developers versus users. It's trading stability for slightly faster access to new, shiny things.

The announcement promises 'Soon, we’re going to bring you more, a lot more, in a package that you deserve as a builder for an independent Web.' My argument is basically that users deserve these things, too.

With huge respect for the work that you and Mozilla have been doing in this and other areas, I can understand that there are practical reasons why this may make sense for Mozilla (and even developers) internally.

But at least from the announcement, it still sounds like Mozilla is other-ing celebrated 'builders' like us from everyday users and segmenting our means of accessing the 'new, shiny things' you mention.

Thank you for following up. I'm just getting up to speed on what the devtools team has been working on, and it should meet with your approval when it's released.

The other-ing language is unfortunate, but is hopefully tempered by Mozilla's work to ensure that everyone can be a developer. Things like Webmaker, the Web Literacy Standard, Summer Code Parties, the Mozilla Science Lab, etc. Mozilla and Mozillians are pouring an enormous amount of effort into building digital skills and literacy every day. We want to help people understand that the Web is a medium that they can create.

Without spoiling the announcement, I suspect it will be more agreeable than it might appear from this press release. :)

agreed - i was probably responding mostly to language and jumping the gun in commenting on a product i haven't seen yet. that's pretty unfair.

but that hypothetical kid whose parents wouldn't let him use ScaryFox that i mentioned in a previous comment..that kid was me

What's the problem? The users can just download the same browser if they're really interested in the additional functionality.

Instead of working to ensure that my parents' computer running Windows 3.1 shipped with a C compiler by default a few decades ago, people inside Microsoft and Borland were probably thinking the same thing.

This line of thinking is basically the reason I had to wait a few more years until I could buy my own computer that could run Linux as a teenager.

For lots of people, the world is a very different place now, but just because something's trivial for people like us doesn't necessarily mean everyone else can very easily 'just download something else'.

Defaults can be tremendously powerful, especially when they enable others to build free software.

> > What's the problem? The users can just download the same browser if they're really interested in the additional functionality.

> Instead of working to ensure that my parents' computer running Windows 3.1 shipped with a C compiler by default a few decades ago, people inside Microsoft and Borland were probably thinking the same thing.

Er, no, they weren't. For Microsoft, they were not thinking users could just download top quality dev tools, in fact that would have been directly contrary to their interests -- they had a profit-based motive for assuring that quality dev tools were a separate purchase. Bundling them into the OS would have required them to sacrifice the additional cost that people making money developing software would be willing to pay for a dev tools .

And Borland was also trying to sell dev tools, but was really irrelevant to what Windows was going to be bundled with.

I agree that defaults are powerful, which is why a potential developer who can't figure out how to download a browser and has nobody around to help will either be using IE or Safari anyway. Anyone who can get a copy of Firefox installed can get another browser installed a LOT more easily than he could figure out how to USE any of the dev features.

The number of potential developers who COULD get Firefox downloaded but COULDN'T figure out how to get a second browser downloaded, yet who COULD figure out how to use the dev features if only they were in Firefox is a tiny fraction of the non-developers who would be confused and annoyed by having dev features they don't want cluttering their interfaces by default.

You are comparing "Go to the store and buy a box of 10 floppy disks to bring home and install" to "click a button on a website"

that's my point: it's clearly not mozilla's fault if everyone doesn't have internet access today or devices that aren't shared with/scrutinized/controlled by others, just like it wasn't redhat or mandrake's fault that the install CDs in computer shopper magazine didn't ship with drivers for my parents' computers a few decades back.

but then, as now, getting started ended up being more complicated for some number of people than it probably seemed to our predecessors at microsoft and borland--including reasons that had little to do with software--but that still could've been influenced by how software development tools were distributed.

maybe it was just me, but getting started is probably still more complicated for some people in the world than either of us can imagine. maybe that's no big deal, but my experience makes me pretty sensitive to access to free software development tools.

Building free software will never be a default mode, simply because building software inherently requires effort. Having the tools in one download or another doesn't appreciably change that.

sure--it's far from sufficient, but for some number of people, it's necessary. at least it was for me.

I think calling IE's development tools high-quality is a stretch. They got nice recently, but by far not as good as those of Chrome or even Firefox. Also it does not help that the development tools in the most recent IE are ok, I still have to maintain/debug older IEs. I think we can probably bin IE8 support, but it think only in recent IE11 the tools got good enough to not be a pain.

Not everyone agrees about IE11, but we are trying to make it better. Better emulation is one place we could do better - I'll shill a bit and call out that we do use our Uservoice [1] to prioritize feature development, so please feel free to add your votes/ideas. I can say that some of these are already in the internal builds :)

[1] https://wpdev.uservoice.com/forums/257854-internet-explorer-...

I recently had very good luck debugging an IE8 problem with IE11 in emulation mode (via Sauce Labs on my Mac, incidentally). Not sure if it works for everything, but it was by far the best experience I've had with IE.

Everybody gets developer tools today.

But if there's a special developer-only Firefox, the dev tools in "regular" Firefox will stop getting new features, will fall out of date, stop providing value, and eventually be removed.

Fundamentally condescending? You can't possibly be serious, or else you have some horrifically misaligned emotional responses.

I see no problem in principle with Mozilla releasing a version of their browser with only very basic debugging tools. I don't think they should, but I wouldn't get indignant about it.

In my mind, if you look at the sheer number of people who self-XSS themselves on Facebook and Google, that the average user shouldn't be able to trigger a JavaScript Console seems like a logical conclusion to me.

Is it condescending? Yes. Does it make the barrier to entry in programming higher? Yes, but considering that properly debugging a web application on a tablet seems to require a separate laptop connected at the same time (with admin privileges to install whatever crazy USB drivers), I'd say that barrier is already high enough that the kid can figure out how to download $DEVELOPER_FIREFOX.

No, those who self-XSS are following the path of ignorance, which only leads to more of the same. What's next, not allowing users to type in a URL in the address bar because they could visit a malicious site? (Remember when Chrome decided to hide the full URL?) Mollycoddling users will lead to a significant loss of freedom and the vicious cycle will never end as they increasingly think everyone else will "protect" them from themselves, leaving all the -- possibly important -- decisions to someone else. Trying to make it impossible for users to make mistakes will also make it difficult for them to learn anything.

The "I don't know what this piece of code does, but I'll run it anyway without even so much as Googling" mentality is what needs to change, if we are to have better netizens. You don't need to be an expert to know what JavaScript is and what it can do. Despite the Internet being such an easily-accessible body of knowledge, and the influence it has on our lives, it's quite disappointing that people have generally not become more knowledgeable of it and instead are mostly consumers like they were before with TV and radio.

If you translate your entire comment to the non-browser development arena, it seems totally nuts. Should everyone have a full development toolchain on the 12" laptop they use to check email and read the news? I have four C compilers, three versions of Python, two Fortran compilers (and a partridge in a pear tree) on my laptop for my day-to-day development activities. Should we stuff all that in a browser? That's obviously extreme, but the point is that insisting on shipping a full developer environment to normal users just serves to limit that developer environment; at some point developers are going to want some crazy stuff that's just unreasonable to force everyone to download. By all means, leave basic debugging stuff in every browser but don't limit the tools pros can use to just that.

> If you translate your entire comment to the non-browser development arena, it seems totally nuts.

Translate it to literacy then. Should everybody be a prolific author or an avid reader? No, it's okay if they're not. Should everybody have the option, the basic ability to? Yes, I wouldn't be surprised if it was considered a human right, or implied by human rights. It's not okay for people to be unable to read, just like poverty is not okay. And what's more, you don't need to know about the chemistry of ink or paper to be literate, just like you don't need to be able to solder a CPU from toothpicks to be computer literate. It's all a matter of degree, with no hard lines, but still, I'm not happy to give up that easily on that much.

We already accepted that making a website is too hard for "normal" users, that just everything taking place in the equivalent of malls is fine, with people hardly interacting in private or public spaces, except for a bunch of wizards in ivory towers, and that is a shame and cannot stand. Especially since the poison of planned obsolescence has already permeated anything to do with computing; if "normal" people can't create their own software and robots, it will not lead to better software and robots made by experts, it will lead to marketing departments shoveling regressing bloatware to people, ultimately. Yeah I'm exaggerating, too, this is FUD in a way, I know that... but I can't help it, this is the one thing to do with computers that really gets to me. I can live with not everybody being a programmer, but I cannot live with not every programmer wishing everybody could program. Being able to make a static website is not even a tiny subset of that, but if I can't even give up on general coding literacy, I can't even consider giving up on general web literacy.

So while it's totally silly to worry over the announcement of something when we don't even, and that will be freely available to everyone, I absolutely love that so many brought this issue up! It does give me hope. But so far, Mozilla has brought me nothing but joy, so I'm not anxious. Whatever it is, it will be open source, right? Right :D Anyone from Mozilla reading this, you guys rock.

TL;DR: I had a dream of a world where the words "developer" and "user" were out of use, just like "free citizen" as distinction to the default case of slave or woman is out of use today (well okay, those problems are also not overcome, but at least there is a consensus amongst smart people that they should be).

My perspective is this: Mozilla (to my knowledge) isn't getting rid of the developer tools in the standard Firefox. Those will still be there for people who want to get into development, and while their features will seem comparatively limited, thats actually a good thing. They're getting access to a concise set of tools that isn't overwhelming, and the same set of tools that millions of people use for development every day. Then, if they want to take their development to the next level, they have a whole new set of tools that can help them do that.

This isn't widening the gap between a user and a developer, since they aren't getting rid of the 'middle ground'. It's just giving the developer more breadth with a better tool.

That's correct, the devtools will remain in mainline Firefox ( source: I'm the PM ). We are starting to add in guards against things lke self-xss in mainline though, and dev edition will not have these sorts of things.

Makes sense--I just think it may be slightly easier to get users to become developers with a default of everyone having the same easy access to the best tools.

I see no harm in a browser dedicated for developers, best serving the web development purposes just as much as I don't see any harm with building mobile and desktop applications using IDEs and Simulators and then releasing them to the numerous platforms.

I believe this separation will lead to the possible introduction of many cutting edge implementations on the browser/engines level(s), for experimentation, before a more general deployment to the end users, which would be quite interesting imho.

Not to mention, developing new debugging tools that the end user doesn't necessarily need to have running in the background of his browser package. This would definitely alleviate the resource consumption of existing browsers and allows the developers to have a focus on the end user experience and not worry about developer specific branches.

I wonder if resources related to debugging tools are responsible for using lots of users' system resources; if that's the case, it could probably be addressed in other ways.

I could definitely see functions like setting the render resolution and rotating between landscape and portrait being useful for testing.

The world that developers and users live in is quite different. And a lot of people won't think of it as 'ScaryFox', but rather as 'CoolFox' which has all of these interesting and advanced-use buttons and knobs that let you see the plumbing of the web page you are using.

Developers want a lot of stuff in their face that the average user doesn't want to deal with. I can see the value of having a 'switch to development mode' button, but having something that's from-the-ground-up built for developers sounds like potentially a much nicer tool to use.

Time will tell if it's a good move on Mozilla's part, but I'm excited for the announcement.

These are good points, too, but what I was getting at is...wouldn't Mozilla be fulfilling its mission even more if the way it designed and released tools helped to bring the worlds of users and developers closer?

When I buy a TV I don't want the chip on the outside so that I can easily tweak it.

Why is there this arrogant idea in the development world that everybody has to get into programming. If a kid wants to program (great!) she can easily download the development version. Calling it scary fox is just scaremongering. If anything getting the special development version might make her feel empowered.

No, debugging web apps is inherently different from using them. Kudos to Mozilla for this one!

And if you need a "high-quality suite of tools for debugging", then all you need to do is look for them... Preferably not in Firefox Extensions, because they are malware-prone...

Really? Which ones?

Deleted comment

Yes. The stuff on addons.mozilla.org is checked by real humans.

I dont think this is an "alternative" to using usual browsers for development and testing. This is an additional tool. There are vast number of use cases where such developer focused browser can be useful.

No. Because specialization.

This is like one of those startup websites/videos that tells you absolutely nothing about what they are doing.

It's pretty much text out of the article shoved into a video with some random background images & graphics accompanied by some epic LoTR music.

It's like a trailer for a trailer. Annoying.

Mozilla has been developing a web browser that will make web development easier for web developers. They are going to be sharing it with world on November 10. Not a lot of info, but I'm excited.

The canonical example:

http://www.zombo.com/

Even better, here's what I get:

http://i.imgur.com/QCyCMDH.png

http://html5zombo.com/

Welcome to the future!

Wow, I am both happy and sad.

Happy because I always wished for an html 5 version, sad because I wish I had done it myself

That's awesome, although I'm a little sad they didn't make a custom font for the text.

I'm glad you got the reference.

It did seem odd to me that Mozilla would create a "trailer" for a web development debugging app. I didn't see the point.

Then I looked back at the comment thread and can see it has 400+ karma right now. So I suppose it worked.

I didn't watch the video (atwork), and I don't even know what the name of this new thing is.

I think this is a logical development. Firefox gets more and more Developer tools by default, but most users will never touch them. So it sounds logical to exclude Developer tools from the default package and instead offer an Developer version of Firefox.

Firefox is my default browser for a long time (switched briefly to Opera, but when they came with the new Chromium-version I switched back because I didn't like it) and I'm very satisfied with it. The developer tools are getting better and better, and I almost never touch Firebug anymore. Also I like Firefoxs tools more than those of Chrome, but that is a question of taste.

I think there is one thing Firefox can really make better for developers and that is addon development. I personally never developed an addon but looked briefly into it and from what I heard was that in comparison to Chrome, developing for Firefox is difficult. I hope there will be progress on this level too.

Why a different browser and not just an extension? I feel like different browsers leads to different versions of engines, languages etc. aka a lot of headaches. As a web developer, I want to see what my users see, not what "developers" see..

Actually, this version of Firefox activates a number of web features that are not activated in the release version, to let webdevs test against features that are either not 100% stable or not fully standardized yet.

But other than that, it's basically Firefox.

So it's just like Chrome Canary? Not exactly "the first" then.

Canary is equivalent to https://nightly.mozilla.org/, or http://nightly.webkit.org/

This is different.

It's not revolutionary (we're not releasing Servo yet), but it is pretty fantastic. I'd be shocked if most Firefox Aurora users don't switch over to the developer browser next week. :)

> This is different.

Is it? Sounds like a side-by-side Aurora with a toolbar button for DevTools. No separate feature set AFAICT, but you tell me if I'm wrong.

Well, we have had Firefox Nightly (which is the equivalent of Canary) for, well, as long as we have had Firefox. But activating some experimental features for webdevs is new.

I have no idea what Mozilla has been building, but I would guess building a browser from scratch with development in mind gives more possibilities than the most advanced extension for a browser. As long as the rendering engine remains the same as Firefox it wouldn't technically be a "different" browser, just a developer flavoured Firefox.

I think it's great that Mozilla is exploring new territories; it may or may not turn out to be a good idea, but give them the benefit of the doubt, at the end of the day no matter how good web developers tools currently are, without experimentation there would eventually be stagnation.

Well that's how developer tools for Firefox started out as (Firebug), however that was also dependent on a plugin API that gave access to all of those things; by building it in natively, the dev tools have access to all of the APIs, not just the ones exposed by the plugin APIs.

That is not really very relevant when building a Firefox add-on. Firefox add-ons get incredible access privileges to the browser internals. That is part of what makes it hard, but also powerful. An example of what I mean, it was not overly complex for Sunbird (the calender app) to be turned into a add-on. There is no reason also for example that Thunderbird could not be turned into an add-on for Firefox. Except then you would have SeaMonkey...

But my 2c, is that even if the project does not work out as hoped, what ever they are doing can put turned into ad add-on.

We have no plans to remove the tools from Firefox release.

So I'm actually a fan of leaving dev tools installed and available in a normal user's web browser; whether it's IE, Chrome, FireFox, or whatever.

If a user is reporting some bug or issue that's difficult to reproduce, I like being able to just hit F12 _on their computer_ and diagnose and debug. Sometimes I can guide the user, sometimes I do it remotely.

Having the ability to debug software like that is phenomenal.

It's not like anyone has taken that away from you.

And as for the new tool, since it also shares the Mozilla engine, it's as if you're using Firefox (+ some plugins) with regards to web behavior.

This would probably start the trend of the dev features being reduced in regular browsers, I'd guess. But you're right no one is taking it away yet.

Why would any browser vendor have an incentive to remove or restrict developer features in released browsers?

Funny story came to mind: You ever have a client accidentally hit F12, then tell your boss that your product was broken because there was a weird thing taking up half the screen?

Seriously: My guess would be download size, performance, maintenance. Especially with Moz aiming to target super cheap hardware with their OS.

It seems like it’d be beneficial to many web publishers if browser users couldn’t easily access underlying resources, and those companies could incentivize popular vendors to go in that direction (and every decent browser auto-updates, of course). Suddenly bypassing Flickr’s spaceball becomes too complicated for regular user.

On the other hand, no one would bother with that in a world where non-mobile computers are increasingly becoming developer-only machines, so this is probably just mild paranoia.

That's a really important aspect, are desktops going the route of developer only? (Non-web) Designers and other white collar probably don't need it, but they use machines that wouldn't notice the difference...

With FFOS, Android/Chrome, and MS there's a conscious effort to eliminate the difference in development between desktop, tablet and phone. With more people using computers, not as many people need or want desktop apps and those features on all of their desktop apps. If I suddenly need to edit an image, I don't need PS or even Gimp, I'm often fine with a web app.

It's not about already released browsers, but possibly future versions.

There have been some phishing attacks that relied on users accessing the dev tools.

How?

Generally by asking them to paste code into the JavaScript console. Here's an example:

http://sdpcfix.com/security-alerts/facebook-scam-helps-trick...

We should instead remove access to the keyboard, that would be a way more effective way to stop any situation where theses users would cause a security issue.

Seriously, it's not the first kind of attack that appear because users are too naive. At one point we need to trace the line somewhere. Should we also block copy-paste to a file in case they create a batch file?

Greasemonkey has similar protections around copy-pasting userscripts, for this very same reason. It's not so unreasonable

We no longer trust the user for anything, instead we block him completely and we move features on another application. I don't believe that's the right way to do it. This only make him more stupid, not more secure.

Apparently, WebIDE is part of Firefox proper not just nightly. You'll have to toggle a pref in about:config (devtools.webide.enabled) to make it visible in the developer menu. It's pretty cool.

Looks like it's enabled by default on Beta (34), so it should come to release Firefox very soon.

First of all this is analogous to the irritating tendency of car manufacturers to "tease" models ahead of time. This may cut it for the average consumer, but here you are targeting the developers, and a straightforward, honest approach to launch would be more effective, in my view. Developers are blasé to any of the mind-tricks which marketing will dream up.

Second, please do some moonshot stuff. Please just don't give me tweaks on javascript. Yes I know js is fine for the front end guys, but more and more, deep data guys like me are having to interact with this language which leaves a lot to be desired. While I appreciate the casual, almost refreshing functional aspects of js, the rest is clearly inferior to almost everything else (not least forcing multidimensionality into this hierarchical JSON strait jacket). Here's an idea: put python numpy native into the browser, and give us expressive power for things other than dom manipulation. Or put Haskell in there. Do something meaningful. I don't want a spit-and-polished js debugger.

Chance to shine here, Mozilla, to regain the long-lost initiative. No chrome-catchup again please.

I'm likewise pretty surprised that this made it to the top of HN. If you want straightforward, technical announcements, watch https://hacks.mozilla.org/ instead of https://blog.mozilla.org. The latter is predominantly press releases and less-technical announcements.

Not that those things are bad, they're just meant for a different audience.

If you want more moonshot-y stuff, emscripten, asm.js, rust, and servo are all pretty worthy of your attention. :)

As interesting as the concept is, I can't help but think it'll only make the already widening divide between "developers" and "ordinary users" even bigger... or maybe everyone will jump over to the "developer" version once they realise what they're missing, which would be the ideal situation.

No information there about what exactly it is, however. It could be not much more than regular Firefox with their WebIDE thing bundled and some UI changes.

It's going to lower the barrier to entry for young people who want to get into more than just the kiddie stuff. I know when I was a kid, I was smart enough for BASIC and Pascal but C++ just looked weird and complex and hard. HTML, CSS and Javascript were awesome and I jumped into that instead. Neat integrated tools are great for beginners.

What drives a divide is when you go build an entire ecosystem and hand it off to a cloistered priesthood. Then you make the toolchain so long and complex that you need 5 years before you even gain the first feeling of accomplishment.

> I know when I was a kid, I was smart enough for BASIC and Pascal but C++ just looked weird and complex and hard. HTML, CSS and Javascript were awesome and I jumped into that instead.

When I was a kid, C++ was easy and I didn't start learning javascript until a few years ago. I also learned TI-BASIC in AP Calc, and Java (CS II-Honors) was presented at my school as harder than C++ (CS I). A lot of what is labeled difficult is very very subjective. A coworker of mine stumbled over Intro to CS/Programming because he was stuck trying to understand how to program hello world without understanding how the compiler worked first. Without a teacher to talk to, this very intelligent student could be seen as one who can't even grasp 'the basics'. I stumbled over my programming languages class because I confused the machine interpretation of Scheme, while we developed a interpreter in Scheme. I'm still confused over it.

> What drives a divide is when you go build an entire ecosystem and hand it off to a cloistered priesthood.

It's not so much that it's handed off to, it's more that people aren't very vocal about what they don't understand. This leads sort of to a 'survival of the fittest' cycle of development, on a macro scale, with the people who have a direction, at all, making important decisions, and the people who are most cautious, staring blankly in confusion. The reality is that everyone is probably missing some part of what is considered 'the basics' to someone else.

A responsive community dedicated to bringing people into development is also what lowers the barrier to entry. Students that are so afraid of their teachers and the 'scary aesthetic' of the material raises the barrier to entry. If you have someone to ask "what does this symbol mean?" or "am I thinking in the right direction, or am I making this lesson more complex than it was intended to be?" then complex and hard become more approachable (not more simple, however). Sometimes having a person reply back, "I don't know" can actually help a lot.

When I was just learning to program, I was afraid to ask questions, to talk about what I knew or thought. I don't know if many young developers struggle with that today, given how much the landscape has changed. Then I wonder, has it changed so much, or did it just take me about 15 years to become comfortable in chaos?

Just some thoughts.

> When I was just learning to program, I was afraid to ask questions, to talk about what I knew or thought.

I suppose you're right. When I was learning, there was no one to ask questions to. Glad that's changed.

I don't think I'm right or wrong. I still have problems asking people for help.

Your point about this is poignant:

> Then you make the toolchain so long and complex that you need 5 years before you even gain the first feeling of accomplishment.

Given that I started writing (and still write) webpages with nothing more than a browser and a text editor, I think the "barrier to entry" has always been quite low. It's only if you want to make a full "web app" using JS and all the latest frameworks/libraries/etc. that the complexity becomes overwhelming, and I wouldn't consider that "entry level" anymore; anyone who is doing that sort of stuff should already be well-versed in writing basic static pages.

(And given how unfriendly to deep linking, accessibility, archiving, and sharing these increasingly popular JS-only single-page web apps are, it would be better if more people, including the beginners, stayed with simply styled, accessible and readable, static pages.)

Lower the barrier? The barrier IS lower enough even for kids... Javascript is the basic of this generation. There aren´t any barriers for new programmers to just sit and learn programming. The tools are already available in the browser. You can learn web programming with your PC, mobile, chromebook, macbook, "any"book.

But yes, I would really like to have more mature and integrated developer tools.

I think the big difference today is that the runtime (often cloud) and toolchain are much more involved. Nothing is self-contained any more. Dependencies are out of control.

Web apps make it easy for the user to access almost any service from almost any device. Unfortunately, this puts the burden on the developer to handle ongoing delivery, hosting, cross-platform compatibility. This can be intimidating, even insurmountable, for young developers in training.

It's a complicated world, these days.

When I started coding at the age of 10, typing hexadecimal dumps from magazine listings was the alternative to BASIC.

C++ is way more user friendly than that.

Well, it's a fundamental issue that a lot of people miss. You can't keep arguing that everything should "just work" because those poor end users might get intimidated otherwise (which is really a codeword for dumbing it down and hiding it behind layers of nested abstraction, then serving it over a thick GUI), and then expect that everyone should learn to code.

It's a total disparity. I also completely disagree with the idea that "JavaScript is the new BASIC" and that every beginner should be introduced to web programming immediately, but it's better than nothing, I guess. Not that web application development isn't less of a clusterfuck than anything else. It's also far more prone to hype cycles and wheel reinvention.

I'm getting a bit weary of announcements that don't really announce whatever it is that they're announcing.

It's easier to wait until a de-hyped Wikipedia entry has been written, and just read that instead.

Hold on to your hats and glasses folks! We're totally stoked to announce the coming announcement of a browser we'll be releasing shortly after that announcement! Stay tuned for the follow up announcement letting you know when we'll announce the release date! We can't wait for you to help us bug test it!

I would like a strict mode in js and rendering engine, which shows syntax error like a compiler instead of eating them and failing later at random places. Ffat fingers and typos take disproportionate time while development.

Beyond ES5 Strict Mode ("use strict";), Firefox has a "javascript.options.strict" about:config pref that will log extra warnings (such as accessing undefined object properties) to the JS console. These warnings are not enabled by default because they are non-standard and can report false positives.

When developing Firefox Addons they have logging that is kind of like what you describe – doesn't break running but problematic code, but does complain. I found the result unusable. Normal development involves using libraries like jQuery, Google Analytics, or whatever other framework that sometimes acts weird, or makes seemingly odd choices for compatibility reasons, or has code that is effectively dead for everyone but IE6 but does get loaded. And since I didn't write jQuery or whatever other library, I don't care about those warnings.

It could be useful if there was a way of indicating what scripts are actually under development, and therefore only complaining about things the developer can fix.

That sounds like a good idea for a dev version. Do you want to file a bug?

You might be interested in looking at TypeScript: http://www.typescriptlang.org/

It does something very similar to what you're suggesting, adding in static type information for JavaScript and giving you compiler errors if you mess things up.

I'm still on the fence about having separate browsers for developers. It sounds nice as a concept but when I think about it more it seems like a disaster waiting to happen.

For instance, when I want to debug my website I go to the dev tools within the browser I'm viewing because I know that my users are viewing the same browser (typically). Having an entirely different developer browsers makes the debugging experience less realistic. It puts you in a position where you don't truly experience what the user does but what you feel more comfortable experiencing.

I completely agree that we want to view what our users are seeing, but as a counterpoint, that isn't even necessarily possible in any mainstream browser. We still have to do the majority of our development in our primary browser of choice and then load up Chrome, Firefox, IE, Opera, etc to see what the rest of the world sees.

I think it would be a mistake to completely remove the developer tools from the non-developer version of Firefox, but I'd also be fine using a different developer-centric browser for the majority of my development understanding that there may be small differences and edge cases that need to be tested on numerous other browsers.

You can't compare that. Chrome, Firefox, IE, Opera, etc all try to do the same stuff, they have the same goal and want to do the same. A developer version of a browser won't have that goal, it's goal is to do something else... it will do it differently.

One of the PM did a comment and gave as an example that they will block self-xss on Firefox, which won't be blocked on the developer version. It won't affect much but you can already see how it's affected. You will be able to run something on a browser but won't be able to do the same on another.

I seriously don't see why we need a developer version of a browser, except removing developer stuff from the real browser and/or adding different support (which will give you issue when you will move to a real browser).

> Having an entirely different developer browsers makes the debugging experience less realistic. It puts you in a position where you don't truly experience what the user does but what you feel more comfortable experiencing.

I don't really agree with this part; it's going to be using the same rendering and JavaScript engine so I wouldn't expect the experience to be different at all it'll just have far better access to developer tools.

Having said that, Mozilla didn't exactly put much of any content into their blog post so I could end up being wrong.

That's a valid point. However, my point is that it's simply a different browser that'll be built on different software, considering it is different.

This speaks to the general low quality of web specifications and/or inability of browser developers to create robust implementations of those specs.

In the vast majority of scenarios we don't think about using the same processor to experience the same thing a user does. (Certainly driver developers and other low level h/w people will occasionally run into h/w bugs but they're in a very niche field).

The web platform is a lot more complicated than any ISA. The right comparison is having the same operating system version as the user, and anyone that develops native apps does have to care about that.

>The web platform is a lot more complicated than any ISA.

Talk to intel engineers and you'll soon be disabused of that notion ;)

Well, I hope that the following two profiler bugs land before then:

Bug 1008435 - [e10s] Port the built-in Gecko profiler to e10s https://bugzilla.mozilla.org/show_bug.cgi?id=1008435

Bug 974832 - WebGL EXT_disjoint_timer_query may now be implemented https://bugzilla.mozilla.org/show_bug.cgi?id=974832

This appears to be a simple rebrand of Aurora with some extra features[1].

[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=1076914

The linked bug's access rights are limited; Mozilla won't show it to me. Is that the right bug?

They seem to have made the bug report private overnight.

Is there a firefox plugin that lets me edit CSS in the developer tools AND lets me save the edits back to the actual CSS stylesheet on my machine? I'd love to see that functionality.

You don't need a plugin for that. In Firefox Nightly that is already enabled.

You can check this article that shows editing LESS and SASS inside the browser and saving it to the original location on your HD:

https://hacks.mozilla.org/2014/02/live-editing-sass-and-less...

Firefox has lots of awesome devtools but people still think in terms of Firebug and haven't noticed all the new goodies.

This is already built into all supported versions of Firefox, including the Extended Support Release. Hooray!

Menu -> Developer -> Style Editor, edit a stylesheet (or add / import a new one), then click "save" in the left panel. Done!

More info: https://developer.mozilla.org/en-US/docs/Tools/Style_Editor

That would be cool actually...

Good intentions, but content and video leaves much to be desired.

The idea is awesome tho, using lots of different tools which doesn't communicate/integrate with each other is a huge blow to productivity.

This is the first time I've ever found a roadblock when looking at the inner workings of FF/Mozilla - https://bugzilla.mozilla.org/show_bug.cgi?id=1054353

Even their etherpads/sprint sheets/team chat logs are public. Not necessarily saying the bug SHOULD be public, just thought it was intriguing. Makes me wonder what other - if any - bugs are private (excluding security ones of course).

Sounds cool. Shame that Mozilla's developer tools are in some respects that are important to me still inferior to Chrome.

How so?

I'm asking because two Firefox devtools people sit in my office, so if you have feedback, I can forward it.

It's starts with GUI issues where you can't resize certain things (e.g. columns in the network tab) or only in a very limited way (it got better). Not being able to inspect objects inline in the console is very annoying. Is there no "clear network log" button? No option to retain/not retain the network log on page loads? I want a way to view an element that got logged to the console in the DOM inspector (Chrome has: context menu -> show in DOM inspector). I want an auto-completion menu in the style editor in the DOM editor. And there seems to be no way to search in a script as shown in the debugger. That's such a basic function, it really makes me wonder. I want a reload menu like in Chrome, where with open inspector I can choose between "normal reload", "hard reload" and "clear cache and reload".

In Chrome's console I like that I simply can write the function name and press enter to see it's source. In Firefox I have to write "String(functionname)". That's only a minor thing. The best thing would be to get the function source expandable inline similar to what you can do with objects in Chrome's console. There should also be a link that lets you jump to the definition of the function in the JavaScript source.

There is no resource tab in Firefox. Basically I want exactly the resource tab from Chrome, with a list of all loaded images, scripts, styles etc., grouped by their origin. I want to see and be able to edit/remove all cookies, local storage, session storage etc.

You can't select a certain iframe as the context of the console, which makes it completely useless when you have to debug iframe based widgets.

I just had the case where the debugger statement starts the debugger but it did not focus on the source line where it occurs, because the debugger request the script again instead of showing the already loaded resource and the script was generated as a response to a POST request.

I don't use Firefox for debugging anymore (unless it's a Firefox specific bug I have to fix) so I don't quite remember the next bit: There where some kind of big annoyances concerning debugging and exceptions which are caught anyway. I could not get it to "halt on exception" but not on those that are caught.

That's all I can think of right now, but I'm sure I forgot something.

But granted, it is always getting better. Maybe some day it is as good as the Chrome Inspector. There is one point where it (or Firefox) is better: Error messages. They are much less cryptic and show the source line of the error. It says things along the lines of "in foo.bar foo has no method bar" instead of "undefined is not a function". Also a rethrown exception retains the original source line, which is very useful.

Firefox's font inspector is nice. I hadn't had a use for it yet, but I can imagine to have one some day.

In course of writing this comment I looked at the Firefox development tools again and a lot of things got indeed much better since the last time I looked.

OT: There are also a lot of things that annoy me about Chrome: Since many month now Linux integration got extremely worse. They dropped gtk for their own thing and screwed up big time in doing so. Context menus look totally alien and have no shadow, tooltips (title attribute) look alien and are no real windows (they get cropped, which makes them useless in certain contexts), there are lots of graphical glitches, e.g. when dragging stuff (white bg of the dragged image/text and for the drop marker arrow in the tab bar) and the scrollbars got the brain dead Windows behavior that not even IE uses anymore. IE implemented it's own scrollbars, apparently. Other scrollbars in Windows (and in Chrome) jump around and stop working when you drag the scrollbar and move the mouse an unknown invisible distance from the scrollbar. Oh and dragging tabs got unusable bad in Chrome. It's a complete disaster. The tabs aren't transparent but full sized when you drag them and you can't drag them down so the bottom border of the window gets outside of the screen, which makes it impossible to drag a tab to a different window that is located down in relation to the window you ripped the tab out of. And sometimes tabs move at an offset form where you grabbed them. WTF? There was a time where Chrome looked less of an alien under Linux than Firefox. Not anymore. Firefox didn't get any better, Chrome got much worse. At least you can use the mouse wheel on the tabs. That is something it does better than Firefox. And the tab size handling when closing tabs one after another. But enough of that.

Oh I want to add: I'm a big fan of the Mozilla foundation and the work it does for the free web. I just currently don't use Firefox. I do use Thunderbird and Chatzilla and I'm a fan of Rust. I hope the Phone will be a success, just so it finances Mozilla.

But while all that features of Chrome are really nice, sometimes they stop working and you need to reload the inspector. The "show element in DOM inspector" context menu for elements logged in the console is what breaks most frequently.

PS: The monitorEvents helper function is a nice thing in Chrome. But that's not so hard to do inline using e.g.:

    foo.addEventListener("mousemove", function (event) { console.log(this,event); })

It's only a few characters more than:

    monitorEvents(foo,"mousemove")

* Handles large scripts very slow (try loading up 4-6M of script) * Issue mentioned of dealing with alternative script loaders * WebWorker debugging * SourceMap support seems brittle * Profiling tools (compared to Chrome)

Actually, callahad has suggested a much better interface for sending feedback to the devtools team: https://ffdevtools.uservoice.com

So did you forward all these comments? What did they say? "We know, but we have other things to do right now"?

This is my issue: https://news.ycombinator.com/item?id=8551692

In addition to going through Yoric, the Dev Tools team actively monitors and responds to feature requests on this UserVoice forum: https://ffdevtools.uservoice.com

If you have an idea, submit (or upvote) it there. It will get seen by the right people.

I can see where a dedicated browser for development could be a little more helpful during the 80% phase of development. My main concern however is that some of that remaining 20% is cross-platform stuff that you can't get right in a single browser.

Unless they incorporate tiled views from different rendering engines. That would be awesome.

^Tiled views would be really awesome!

> Mozilla: The First Browser Dedicated to Developers Is Coming

But we need markup and scripting languages dedicated to developers...

I remember people arguing in a thread a while ago about the financial longevity and user-base sustenance of FireFox. Many were arguing that FireFox needed something fresh and different and also needed to identify their target audience.

When Mozilla releases this, which is at least remotely intriguing, many are quick to find small deleterious criticisms.

The fact of the matter is that they are not removing the earlier dev-tools and nobody is forcing anybody to migrate to it. They are just trying to make another tool to help people. Honestly, if you put these arguments in any other context, either software or real life, they sound absolutely ridiculous.

This is marketing at its best. Create a browser that developers like to use so they can build Mozilla compatible products for consumers. Then more the consumers will adopt this browser as their default browser.

The developer browser also includes Firefox Tools Adaptor which supports remote device debugging of mobile browsers like Chrome on Android and Safari on iOS:

https://hacks.mozilla.org/2014/09/firefox-tools-adapter/

The ultimate feature for hackers is how hackable something is. That means it is easier to develop the version for hackers first, and then package a specific version for end-users. Therefore, if they do develop a hackable browser and allow everybody to innovate on it, they may well be in their way to create the next best browser.

This paradox is similar to creating a new microcomputer only for hackers (Apple I/II) which in turns allows them to develop cool stuff on it (Visicalc) which in turn makes it the standard for all users.

The video and article is full of hype, made me laugh however.

I like the idea of a full browser for developers, but at the some time I fear the granularity of browsers differences increases also. Currently developers cannot stay focused on new features of web App itself but they need to check the compliant with all browsers IMHO that's is one of the major issues why the web technology is going slow especially in the mobile environment.

I wonder if they'll remove (or at least most of it) developer tools from the main browser and try to get developers to use this version. Common criticism of Firefox these days is it feels (and in most cases is) slower and more bloated than Chrome. This move could help Mozilla make FF faster, no?

Well, the main advantage that Chrome has vs Firefox is not speed (these days, Firefox is faster than Chrome on most benchmarks I have seen), but smoothness, which is largely due to the multi-process architecture of Chrome.

Developer tools have strictly no influence on this, and the multi-process version of Firefox is currently being tested. I don't remember whether there is an ETA.

To me it looks like speed is one of the major advantages. JavaScript speed is only one thing. There is also render speed. E.g. this runs totally smoothly (with a bit of flickering (z order problems?)) in Chrome: http://keithclark.co.uk/labs/css-fps/nojs/ In Firefox it seems to have something between 1 and 5 fps and is totally glitched out.

JavaScript speed is not what needs to be worked on currently. Render speed is.

Last ETA was Firefox 36: http://www.ghacks.net/2014/07/12/mozilla-plans-release-elect...

Developer tools don't add any overhead unless you enable them.

It really would be a godsend if editing your CSS in the browser could make changes to the underlying files (probably SASS these days). Difficult but would shave so much time off the make a few changes and rewrite them in an editor process that so many of us follow these days.

Considering all the "helpful" features in chrome that get in the way of development (copying the url prepends "http://", even for IPs, for example), this is an important change.

What's wrong with prepending the protocol? And why should IP addresses by any different?

"We can't wait telling you about it, so wait until the 10th please." Zzz.

This sounds great, but what's with the SV wantrepreneur vaporware video trailer?

I don't like google because of privacy concerns but chrome developer tools is a bit ahead of firefox DT. I hope this new one will give me a good reasons to switch from chrome to firefox

The recent developer tools improvements/additions to FireFox in the nightly (and maybe aurora) have, in my opinion, surpassed Chrome's.

That's great news. Thanks

One part of the Firefox dev tools I find useful in every-day browsing is the ability to delete a DIV (or similar) element whenever something causes a bad layout or otherwise gets in the way.

SQL queries in address bar to manage your bookmarks or manipulate data from the websites would be nice.

They should fix the URL bar. When I used a webserver on local network, the URLs got constantly mangled.

If you use a module loader that uses eval to load modules, those modules will not be shown in the Debugger's Sources in Firefox. It works fine in Chrome. This is absolutely killer for me, I can't use Firefox for development until it is fixed.

Of course, if this dedicated browser happened to be based on Servo then this teasing would largely be worth the wait ;)

Waiting 7 days for Servo? Sign me up :)

just what are addons for? an extra special Xtraordinary XPI could deal with this..

Why dont yu simply accept existance of FireBug ?

Sure. Firebug is awesome to hang/freeze Firefox, even in modern computers.

This is like a landing page for a startup - or idea. They first test the assumption that developers need/want this. If they are proven right, they will build it. In the next seven days. ;-)

Is this really needed? I feel like Mozilla are inventing problems to solve.

Mozilla is competing with Google Wave now?

Meanwhile Chromium is a perfect hybrid offering the best of both worlds and doesn't need _another_ browser 'dedicated to developers'. Mozilla is more than ever feeling the slippery slope of market share under its shoes and this feels like yet another attempt to recapture a market (web developers) which was once theirs.

Yeah...we'll see. If the current state of Firefox's Dev Tools is any indicator of what they have to show, I'm not optimistic.

Firefox's developer tools are good an improving at a fast pace. I would argue that they in most aspects have surpassed Firebug and the Chrome developer tools.

I've never liked Chrome's, but I've been trying to go with native dev tools only on this machine and so far it's gone really well.

Can you provide better info on what you think are the shortcomings?

The DevTools team is really interested in that type of feedback...

At Mozilla we know that developers are the cornerstone of the Web, that’s why we actively push standards and continue to build great tools to make it easier for you to create awesome Web content and apps.

Like canning WebSQL for spurious reasons and forcing people to use a half-baked spec like IndexedDB instead? As much as I applaud most of what Mozilla has done to further the interests of the open web it's hard to forget how profoundly they sabotaged the development of the browser as an application platform with this particular piece of political NIH grandstanding.

It's hardly grandstanding when it's the standard everyone agreed on.

I agree that IndexedDB is awful and WebSQL was much better, but go shout at the W3C, not Mozilla.

The filesystem API was also nixed, so now people take to implementing fake filesystems on IndexDB, and implementing fake-SQL on top of IndexDB. On top of that, IndexDB performance isn't as great as it should be.

With something like SQLite, I think it's fine to take a super mature platform and retroactively extract a specification from it (while 99% of the people just keep the original implementation), than to start with a crap spec and try to make it mature.

IndexDB set the state of offline storage back, meanwhile Android and iOS developers are using SQLite or equivalents.

Well, the FileSystem API is still being worked on. Just quite different from what Chrome implemented (which was very Unix-centric, iirc).

Well, that's good to hear. My concern is, we need APIs that are predictable, straightforward, and easy to use for devs to create offline web apps. Right now, it's quite difficult, and hence hardly anyone does it. ServiceWorker may help a lot with one part of the equation, but it doesn't fix up the persistent storage story of the Web.

I find the IndexDB API maddening to use personally.

Agreed on all accounts.

I seem to remember that the current WIP is here: http://w3c.github.io/filesystem-api/Overview.html

Its not just you, it is maddening to use. A sane wrapper is mandatory.

It was Mozilla's insistence on IndexedDB that tipped the balance. WebSQL was already well supported in Chrome and Safari and if Mozilla hadn't inexplicably come down on Microsoft's side we would have a reasonable client-side database solution today.

Lest this particular piece of villainy be forgotten: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

It takes a special kind of myopia to call a decision inexplicable, and then to link to a very explicit description of their reasons for that decision.

Refuted by almost every single comment on the post, yes.

There's a difference between inexplicable and an explanation you disagree with.

Unfortunately, WebSQL had simply _no_ specifications. That's not good for a standard, and that's why IndexedDB won in the end.

> canning WebSQL for spurious reasons

The way to implement WebSQL is to copy SQLite 3.1.9. That is not exactly a baked specification, that is the kind of crap companies used to pull to make unimplementable "standards" for everyone who doesn't license their code and doing that a few times over a decade would make w3c compliant browsers pretty crappy.

So instead, invent something that's a piece of crap, and make the Web worse than what Android and iOS developers get for offline storage.

SQLite is public domain, there's no need to license it.

Sometimes worse is a better, and insisting on standards process purity in this case I think harmed developers and didn't help the Web at all. There was nothing wrong with SQLite from a licensing standpoint, and everyone could have used it, and reverse engineered a spec later.

Reverse engineering a spec from an active product which regularly fixes bugs or adds new features? I'm not saying that it couldn't work, but I am not very optimistic.

Plus, I don't remember that anybody in w3c or whatwg actively defended that approach.

It would have made much more sense to use that as a basis for a new, more formal spec than to pull some new NoSQL spec that nobody wanted out of their ass.

Reply on news.ycombinator.com