WebIDE lands in Firefox Nightly(hacks.mozilla.org)
hacks.mozilla.org
WebIDE lands in Firefox Nightly
https://hacks.mozilla.org/2014/06/webide-lands-in-nightly/
17 comments
> Putting an IDE inside the browser, having no other dependencies between viewing web-pages and making web-pages is an incredible first step.
I... um, it's a first step we took 17 years ago, didn't we? http://en.wikipedia.org/wiki/Netscape_Composer
I... um, it's a first step we took 17 years ago, didn't we? http://en.wikipedia.org/wiki/Netscape_Composer
http://www.w3.org/Amaya/ is not as old (1996) but is also pretty cool. I wish they had more funding to explore that idea that the web should be editable (as long as you have the authorization to PUT).
The very first web browser had editing built in. That's why HTTP has the concept of verbs in the first place! Otherwise GET would probably be implicit. Forms and POST came later, but PUT and DELETE was part of the original idea behind the web.
I totally agree that browsers should allow editing. Even if you are not authorized to PUT the page back to the server, it would still be useful to be able to edit before you print or save the page locally.
I really have no idea why we were robbed of this capability! It was probably just laziness from the people who wrote mainstream browser and httpd implementations.
I totally agree that browsers should allow editing. Even if you are not authorized to PUT the page back to the server, it would still be useful to be able to edit before you print or save the page locally.
I really have no idea why we were robbed of this capability! It was probably just laziness from the people who wrote mainstream browser and httpd implementations.
A first step on a sinking ship doesn't count.
Mozilla Composer was part of the Mozilla Suite (a predecessor of Firefox).
http://en.wikipedia.org/wiki/Mozilla_Composer
http://en.wikipedia.org/wiki/Mozilla_Composer
Yeah but Mozilla Composer was begat by Netscape Composer, which was part of the push into "enterprise" and being a "collaboration suite" that jwz lists as the #2 cause for sinking of the Netscape ship:
http://www.jwz.org/doc/groupware.html
Anyone who doesn't think the Netscape ship sank is probably too young to remember pre-Firefox (or too close to events to be objective); but the fact that the ship was salvaged from near the bottom of the ocean doesn't change the fact that it did sink.
http://www.jwz.org/doc/groupware.html
Anyone who doesn't think the Netscape ship sank is probably too young to remember pre-Firefox (or too close to events to be objective); but the fact that the ship was salvaged from near the bottom of the ocean doesn't change the fact that it did sink.
What? Kids ARE the experts and if you have spent time to become a professional you are already too old. Haven't you read the agism article on HN today?
> the computers are the very same.
What do you do when you run into a kid holding an iPad?
What do you do when you run into a kid holding an iPad?
Point it to one of the tens of programming environments for the iPad that also run on the iPad? Like this, for example:
http://twolivesleft.com/Codea/
And then I'll tell him that with just a Mac (which he might already own) and a $100 dollar subscription, he can program and even sell iPad apps worldwide, to a market of half a billion people.
People seem to forget how, in those 80s computers, to get a compiler (besides the built-in BASIC one) you usually paid lots of money. And that a worldwide distribution network for your apps, with automatic payment handling et al was also out of the question. As was an SDK even 10% as complete as Cocoa Touch or the Android one.
http://twolivesleft.com/Codea/
And then I'll tell him that with just a Mac (which he might already own) and a $100 dollar subscription, he can program and even sell iPad apps worldwide, to a market of half a billion people.
People seem to forget how, in those 80s computers, to get a compiler (besides the built-in BASIC one) you usually paid lots of money. And that a worldwide distribution network for your apps, with automatic payment handling et al was also out of the question. As was an SDK even 10% as complete as Cocoa Touch or the Android one.
An iPad could be a good stepping stone. For me it was Nintendo as a kid that then got me into computer games, which then got me into making my own stuff, which then made me into a programmer today heh.
This is a little bit like the early home computers. You could start writing code (basic) immediately after switching on the computer. Copy a few lines of code from magazine and see what it does.
The manual that came with the Apple IIc my family had when I was a kid included sections on programming the computer with Applesoft BASIC. What an optimistic thing to include in the manual that every user gets! And, yet, those were the first lines of code I ever typed into a computer and I'm still doing it 30 years later.
I remember small sections of BASIC in my school math book in something like 6th grade. We had a Mac with HyperCard so it looked really primitive to me :)
Yep. When I was a kid I had to type my games in from an Usbourne book. It was, in the long run, a hell of a lot better than a console and cartridges would have been.
This is a good point. I was in the same position as you as a kid. I was interested in computers, but I didn't know anyone that could teach me much about them. I assumed in college they would teach you all the secrets, I had no idea that all the tools I needed were available online. With this IDE, the barrier is super low, if Mozilla decided to market it that way.
The Webmaker project is sorta related to that.
https://webmaker.org/
https://webmaker.org/
I've never seen that before, it's pretty neat. The X-ray goggles are fun, and jumping from there to building your own page wouldn't be so bad
I know what you mean. I have multiple examples of experiencing this realization about different professions.
For example, the day I discovered that they sell surveilance cameras in regular electronics stores, I was very surprised. Up until then, I had thought that only special kinds of highly trained professionals even knew how to get them and that the whole thing was a giant unified system that cost close to infinite amounts of money.
For example, the day I discovered that they sell surveilance cameras in regular electronics stores, I was very surprised. Up until then, I had thought that only special kinds of highly trained professionals even knew how to get them and that the whole thing was a giant unified system that cost close to infinite amounts of money.
> I await the day any kid asks "How do I make my own webpages?" and we can answer "You've already got everything you need, just press F12."
Small correction: they'll ask "How do I make my own apps?"
And the answer will be the same.
Small correction: they'll ask "How do I make my own apps?"
And the answer will be the same.
From my experience, IDEs do not help in reducing the notion that programming is somehow "magic" - on the other hand, beginners will tend to develop an attachment to them, and that's where the "magic" shifts to. Basic concepts like "source code is just a text file" will be foreign to them (I'm surprised how many supposedly educated "developers" I've encountered don't understand this.)
I think the best way to start writing webpages is with a text editor - which almost any OS out there will already have, and that IDEs are like calculators - they're a great help when you already know what you're doing, but not ideal for starting out learning.
That said, if this makes it to the stable release channel it would be a big (and positive) change of direction for Mozilla, who have had a history of removing power-user-oriented features (and most developers probably started out as power users.) I remember a thread on HN (might've been about Australis?) in which others were wondering whether they would eventually remove the "View Source" function.
I think the best way to start writing webpages is with a text editor - which almost any OS out there will already have, and that IDEs are like calculators - they're a great help when you already know what you're doing, but not ideal for starting out learning.
That said, if this makes it to the stable release channel it would be a big (and positive) change of direction for Mozilla, who have had a history of removing power-user-oriented features (and most developers probably started out as power users.) I remember a thread on HN (might've been about Australis?) in which others were wondering whether they would eventually remove the "View Source" function.
True enough: bundling IDE with browser does not solve the problem, but it certainly lowers the bar for beginners to start programming.
This should be a separate tool. An add-on, or whatever, but it shouldn't be bundled with the browser. If you think about it, it doesn't make much sense.
Do you see audio mixing/mastering or video editing software being bundled with media players? Or do you see word processors/TeX IDEs bundled with PDF viewers? No, because you wanted to play your Black Sabbath .mp3, or read a .pdf scientific paper.
If you wanted to record your Black Sabbath tribute band and produce the recording, you'd get a digital audio workstation. If you wanted to write your own scientific paper, you'd get a TeX bundle. If you wanted to develop web apps, you'd want to download an IDE. Not use a web browser.
A vast, vast majority of people downloading Firefox wants to just look at damn web pages. The ones who want to make them are welcome to get dedicated software. Developers of that separate program for web dev could then go crazy and add a lot of features that wouldn't be possible so easily if it was bundled in a browser. Everyone wins.
So why this? No one is being done a favor by bundling a web IDE with a browser. A bullshit token reason like "it's easier for novices" will not qualify.
Do you see audio mixing/mastering or video editing software being bundled with media players? Or do you see word processors/TeX IDEs bundled with PDF viewers? No, because you wanted to play your Black Sabbath .mp3, or read a .pdf scientific paper.
If you wanted to record your Black Sabbath tribute band and produce the recording, you'd get a digital audio workstation. If you wanted to write your own scientific paper, you'd get a TeX bundle. If you wanted to develop web apps, you'd want to download an IDE. Not use a web browser.
A vast, vast majority of people downloading Firefox wants to just look at damn web pages. The ones who want to make them are welcome to get dedicated software. Developers of that separate program for web dev could then go crazy and add a lot of features that wouldn't be possible so easily if it was bundled in a browser. Everyone wins.
So why this? No one is being done a favor by bundling a web IDE with a browser. A bullshit token reason like "it's easier for novices" will not qualify.
We've gone full circle: Firefox/Phoenix was born as a way to separate the browser from (guess what) html-authoring, email, calendaring etc, which used to be "the same program" aka Netscape Communicator / Mozilla Suite. The split basically killed off most of the orphaned components.
Now Mozilla are busy rebuilding an html-authoring tool and packing it into the browser. I bet messaging will follow.
Now Mozilla are busy rebuilding an html-authoring tool and packing it into the browser. I bet messaging will follow.
> messaging will follow
Messaging is already here. Except it's called the Social Service API.
For example, there are two Facebook Services. You can go (right now) to the Mozilla Social Service Activations Portal, select Facebook Share, and click "Activate now":
https://activations.cdn.mozilla.net/en-US/facebook.html [Requires a Facebook account]
There used to also be a Facebook Messenger Service, but that appears to be gone for some reason:
https://support.mozilla.org/en-US/kb/how-does-facebook-messe...
There's developer documentation here:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/So...
Messaging is already here. Except it's called the Social Service API.
For example, there are two Facebook Services. You can go (right now) to the Mozilla Social Service Activations Portal, select Facebook Share, and click "Activate now":
https://activations.cdn.mozilla.net/en-US/facebook.html [Requires a Facebook account]
There used to also be a Facebook Messenger Service, but that appears to be gone for some reason:
https://support.mozilla.org/en-US/kb/how-does-facebook-messe...
There's developer documentation here:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/So...
Psst! They call the suite SeaMonkey today.
"Do you see audio mixing/mastering or video editing software being bundled with media players? Or do you see word processors/TeX IDEs bundled with PDF viewers? "
No, and that's a problem. Do you see programming languages shipped with every computer? No, but that's how it used to be. Most shipped with BASIC while Unix shipped with C. I guess Macs come with Python, but just CLI no IDE - not even idle. Is there some reason not to ship development tools? Do you not want the curious to have ready access to dig in and understand the stuff they use every day?
No, and that's a problem. Do you see programming languages shipped with every computer? No, but that's how it used to be. Most shipped with BASIC while Unix shipped with C. I guess Macs come with Python, but just CLI no IDE - not even idle. Is there some reason not to ship development tools? Do you not want the curious to have ready access to dig in and understand the stuff they use every day?
Macs come with Python (and Idle is included), Ruby, PHP, Perl, BASH, Apache web server, git, Vim, Emacs, Pico, Nano etc and XCode with clang for C/C++/Objective C/Objective C++ is a free download (used to ship on OS DVD but OS is no longer shipped on physical media).
Java used to be bundled too out of the box, but Apple has deprecated their JVM. Of course Oracle has up to date JDK for OS X now.
Really getting compilers and dev tools for Unix OSes is trivially easy. Almost everything is free if not open source.
Java used to be bundled too out of the box, but Apple has deprecated their JVM. Of course Oracle has up to date JDK for OS X now.
Really getting compilers and dev tools for Unix OSes is trivially easy. Almost everything is free if not open source.
> Is there some reason not to ship development tools? Do you not want the curious to have ready access to dig in and understand the stuff they use every day?
More and mroe macs are being sold with SSD's, and installing Xcode uses a good 4-5 gigs (+1GB per platform in documentation). That's a good enough reason for me to not install it when I don't need it.
More and mroe macs are being sold with SSD's, and installing Xcode uses a good 4-5 gigs (+1GB per platform in documentation). That's a good enough reason for me to not install it when I don't need it.
Does this argument apply to development tools in the browser, or do you think this is likely in the near future? As in, does it currently negatively affect performance or significantly impact the size of the browser (honest question)?
The curious won't be perplexed by such a simple barrier. They'd find this Web IDE, had it been an add-on, and happily continue exploring. Is that little convenience enough to justify bloating an executable millions of people use daily with a lot of code that only 5% of them (a very generous estimate) will ever use?
We should be splitting software into smaller components, and let the user choose what they need. There's no need to pander to lazy or unwilling-to-learn users by barfing up all they need into a single binary, thereby adding stuff most of the people won't ever use.
We should be splitting software into smaller components, and let the user choose what they need. There's no need to pander to lazy or unwilling-to-learn users by barfing up all they need into a single binary, thereby adding stuff most of the people won't ever use.
That's a solid point, assuming that it actually does create bloat (which I don't know much about, I admit).
Could another advantage of coupling browsers with development tools be that it makes it logistically easier to maintain 'parity' between the browser and its development tools? Or is that not how these things are done?
Edit: I see my question has been addressed elsewhere (https://news.ycombinator.com/item?id=7933515)
Could another advantage of coupling browsers with development tools be that it makes it logistically easier to maintain 'parity' between the browser and its development tools? Or is that not how these things are done?
Edit: I see my question has been addressed elsewhere (https://news.ycombinator.com/item?id=7933515)
We shouldn't really be asking if some excess software (and an IDE is pretty heavy) is causing bloat or not. If it's not needed by most of the people, it is bloat. If not so much for the user, then also for the development team.
I like when software is doing one single thing, and is great at doing that one single thing. With Firefox needing to address a lot of problems to stay on par with Chrome, the last thing it needs is more cruft to worry about in the browser itself.
I like when software is doing one single thing, and is great at doing that one single thing. With Firefox needing to address a lot of problems to stay on par with Chrome, the last thing it needs is more cruft to worry about in the browser itself.
They won't though. All you see in web dev tools is the UI as all the actual clever stuff is still hidden away from you on servers.
With an increase of client-side apps combined with server api's this is less the case, though, isn't it?
I can imagine quite a few 'web apps' that won't try to actively obfuscate how their client app operates. In those cases having browser-based development tools makes it much easier to tinker with and inspect the app...
I can imagine quite a few 'web apps' that won't try to actively obfuscate how their client app operates. In those cases having browser-based development tools makes it much easier to tinker with and inspect the app...
Well, with most single-page apps, bulk of the logic is running on the client, with the backend just exposing a REST API.
I have idle on Mavericks in /usr/bin/idle. There is also emacs and ruby.
>Do you not want the curious to have ready access to dig in and understand the stuff they use every day?
Yeah, pretty much.
Combine offshoring with the baffling obsession some programmers have with teaching EVERYONE their trade and you can expect compensation levels to plummet in the coming years.
Yeah, pretty much.
Combine offshoring with the baffling obsession some programmers have with teaching EVERYONE their trade and you can expect compensation levels to plummet in the coming years.
Right. Let's keep the rest of the world illiterate, as long as we keep making nice salaries.
The "baffling" obsession might come from the fact that many programmers realize that basic programming knowledge is the coming equivalent of literacy. And that they'd never be in the position they're in now if generations of CS people hadn't freely shared what they learned.
The "baffling" obsession might come from the fact that many programmers realize that basic programming knowledge is the coming equivalent of literacy. And that they'd never be in the position they're in now if generations of CS people hadn't freely shared what they learned.
There will still be a need for dedicated computer programmers, but I think that if everyone had basic scripting knowledge or at least was not afraid of gaining that knowledge, the world would be a better place for it. And if more people understood what it took to program, there might be less under or overestimating of the value of a good programmer.
That's the optimist's outlook.
I could just as easily envision an army of cheap, self-taught "programmers" making applications held together with spit and glue and causing a race to the bottom in the industry (see the residential construction industry for an example of this).
I could just as easily envision an army of cheap, self-taught "programmers" making applications held together with spit and glue and causing a race to the bottom in the industry (see the residential construction industry for an example of this).
Every browser already ships "developer tools" for inspecting and debugging webpages. And you can already use those tools to rewrite the pages. I see this as the next step of that. And audio or word processing tools are less related to the web than this IDE. I agree that I don't see the harm in making this an Add-on instead. Anyhow browsers are the new operating systems, and Firefox has a development IDE bundled.
Chrome has an option where you can save your edited JS back to the file system; it also feels like another step along this path.
I also think that including dev tools and even an IDE like this in a browser are fundamentally different from including a mail or calendar client in a browser.
I also think that including dev tools and even an IDE like this in a browser are fundamentally different from including a mail or calendar client in a browser.
The democratization of the web gives people who have been consumers the ability to be creators. The tools of creation belong in everyone's hands.
Yes but they don't all need to be exactly a single tool, a single process! Just like I really don't want a web browser in my file manager / operating system / text editor.... wait all of that already happened. sigh.
And? That doesn't mean it cannot be a plugin.
If it was an extension we would lose stability because our devtools have unit tests that test against every Firefox change.
If view source had been a developer plug-in in the 90's, I'll bet there would be a lot fewer web developers today.
I agree. I'd be happy with launching firefox in a more lightweight non-web-dev mode for everyday browsing and then web-dev mode with all the extra tools and UI elements. The cool thing about that would be that the developer tools could be more tightly integrated with the UI because they wouldn't have to be hidden from the majority of people who would never need them.
You can use Profiles¹ for that sort of stuff. about:config² is good for a somewhat complete list of components that can be enabled/disabled.
1: https://support.mozilla.org/en-US/kb/profile-manager-create-...
2: about:config?filter=.enabled
1: https://support.mozilla.org/en-US/kb/profile-manager-create-...
2: about:config?filter=.enabled
See also the profilist extension:
* https://addons.mozilla.org/en-US/firefox/addon/profilist
* https://addons.mozilla.org/en-US/firefox/addon/profilist
Modularity is a great idea, but modularity isn't always a solution. Sometimes, tight, monolithic integration is better, for both developers and end user.
As an example, some companies have a single source tree with every project. Why the hell would they do that? Make 100 repos on github is better - you know which repo is which repo. Maintenance and usage headache.
> A vast, vast majority of people downloading Firefox wants to just look at damn web pages.
So why bundle dev tools in the first place? Remove dev tools will definitely slim firefox's size and memory footprint. Forget about error logging (null them); if you are developer just install addon so you can pipe the errors. That's better! Lightweight browser for the rest of the non-developer user! Win!
Of course that won't work for Mozilla. They are not interested in maintain two separate set of builds. I am not going to do that for my software either. It's a lot of work.
> If you wanted to develop web apps, you'd want to download an IDE. Not use a web browser.v
Nope. I can do this with Word, python -m SimpleHTTPServer, and a web browser to write code, test code and see code in live action. Why I don't do that and use an IDE or vim? Because of convenience.
Firefox has a feature called scratchpad. See [1], and the point is that you can experiment your javascript code without having to squeeze your code into the console. It also reduces the headache of copy-paste code back and forth between console and some other places (you can't save your console code, so where do you get the code? Some file!)
I wrote one add-on and the workflow is awful. See [2]. I wish I could write add-on in scratchpad without having to repeat those steps and can see error immediately by a click on scratchpad. Maybe scratchpad has this feature I am not aware of...
The point is, I hate to switch back and forth between the browser, my vim terminal and the web console.
[1]: https://blog.mozilla.org/devtools/2011/08/15/introducing-scr...
[2]: https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Ge...
> A bullshit token reason like "it's easier for novices" will not qualify.
No this is not bullshit, because developers are users and some users turn into developers BECAUSE they poke around tools available to them.
As an example, some companies have a single source tree with every project. Why the hell would they do that? Make 100 repos on github is better - you know which repo is which repo. Maintenance and usage headache.
> A vast, vast majority of people downloading Firefox wants to just look at damn web pages.
So why bundle dev tools in the first place? Remove dev tools will definitely slim firefox's size and memory footprint. Forget about error logging (null them); if you are developer just install addon so you can pipe the errors. That's better! Lightweight browser for the rest of the non-developer user! Win!
Of course that won't work for Mozilla. They are not interested in maintain two separate set of builds. I am not going to do that for my software either. It's a lot of work.
> If you wanted to develop web apps, you'd want to download an IDE. Not use a web browser.v
Nope. I can do this with Word, python -m SimpleHTTPServer, and a web browser to write code, test code and see code in live action. Why I don't do that and use an IDE or vim? Because of convenience.
Firefox has a feature called scratchpad. See [1], and the point is that you can experiment your javascript code without having to squeeze your code into the console. It also reduces the headache of copy-paste code back and forth between console and some other places (you can't save your console code, so where do you get the code? Some file!)
I wrote one add-on and the workflow is awful. See [2]. I wish I could write add-on in scratchpad without having to repeat those steps and can see error immediately by a click on scratchpad. Maybe scratchpad has this feature I am not aware of...
The point is, I hate to switch back and forth between the browser, my vim terminal and the web console.
[1]: https://blog.mozilla.org/devtools/2011/08/15/introducing-scr...
[2]: https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Ge...
> A bullshit token reason like "it's easier for novices" will not qualify.
No this is not bullshit, because developers are users and some users turn into developers BECAUSE they poke around tools available to them.
>No this is not bullshit, because developers are users and some users turn into developers BECAUSE they poke around tools available to them.
And by moving the web IDE to a separate add-on, we make it unavailable to them?
It's just more easily available. That's a huge difference. You have a web browser, you ask yourself, "how do I create webpages?" Then you maybe Google how to do it, and the answer says "it's in Firefox, just press F12", or "get this Firefox add-on, and then press F12". The difference is negligible.
If someone was to stumble across some HTML via "View Source", the result would be essentially the same as above. If someone opened the web IDE out of curiosity, she would still need to know how to use it. Tinkering only gets you so far, it's a combination of tinkering and researching that makes you learn new stuff. And if you do even a modicum of research on that, you'd learn that there's an IDE in Firefox, or that there's an add-on for Firefox.
Talents show up, one way or another. How likely is it that this particular decomposition of a monolithic application into a core application and an add-on would make some talented kid never discover their passion? I'd say it's highly unlikely. But how likely it is that a huge amount of users would need to download bigger archives of the browser, or bigger updates, or suffer from some form of bloat if the IDE was included? I'd say more likely.
New developers have been emerging since the dawn of computing, without any thought given to whether or not including something would allow some kid to poke around and discover that he likes to do it. Why would it stop now?
And by moving the web IDE to a separate add-on, we make it unavailable to them?
It's just more easily available. That's a huge difference. You have a web browser, you ask yourself, "how do I create webpages?" Then you maybe Google how to do it, and the answer says "it's in Firefox, just press F12", or "get this Firefox add-on, and then press F12". The difference is negligible.
If someone was to stumble across some HTML via "View Source", the result would be essentially the same as above. If someone opened the web IDE out of curiosity, she would still need to know how to use it. Tinkering only gets you so far, it's a combination of tinkering and researching that makes you learn new stuff. And if you do even a modicum of research on that, you'd learn that there's an IDE in Firefox, or that there's an add-on for Firefox.
Talents show up, one way or another. How likely is it that this particular decomposition of a monolithic application into a core application and an add-on would make some talented kid never discover their passion? I'd say it's highly unlikely. But how likely it is that a huge amount of users would need to download bigger archives of the browser, or bigger updates, or suffer from some form of bloat if the IDE was included? I'd say more likely.
New developers have been emerging since the dawn of computing, without any thought given to whether or not including something would allow some kid to poke around and discover that he likes to do it. Why would it stop now?
As a developer, I like native integration. Why should an operating system bundle media player if they can just download a media player on their own using a browser? How many people start to play a video as soon as they get a new computer? A 5 minute research is enough to find out a variety of good media player.
In fact, OS bundle media player sucks because they can only play some formats. I shall say it sucks that we have so many different codec available and yet OS can only bundle a small subset of the free codec (forget about the one that are proprietary).
And you know what? This integration is done. It's in nightly. It probably won't be removed for a long time because it's a feature that has a use case. You don't have to like it, but it's in there.
I don't know about you, but sometimes the things I dislike turn out all right and I like them later because I start to use them.
Also, I own multiple copies and multiple profile of Firefox for development purpose (and testing purpose). I am not sure whether there is a global way to make add-on available across profile, but at least I don't know how and I don't want to re-install the same add-on five times a day. Minor use case but it's a use case.
Also, when I teach programming to students, I and the class can benefit from a single installation. Just need Firefox! I don't need to worry about different IDE and I can focus on showing them the result in the same browser they use to see live code and debug code. I don't use fancy IDE and I hate full blown IDE for web app.
This integration makes me happy, makes some of us happy and that's how a software is. You don't have to like this decision, but it's in there, so try it when you have a chance and you may like it.
In fact, OS bundle media player sucks because they can only play some formats. I shall say it sucks that we have so many different codec available and yet OS can only bundle a small subset of the free codec (forget about the one that are proprietary).
And you know what? This integration is done. It's in nightly. It probably won't be removed for a long time because it's a feature that has a use case. You don't have to like it, but it's in there.
I don't know about you, but sometimes the things I dislike turn out all right and I like them later because I start to use them.
Also, I own multiple copies and multiple profile of Firefox for development purpose (and testing purpose). I am not sure whether there is a global way to make add-on available across profile, but at least I don't know how and I don't want to re-install the same add-on five times a day. Minor use case but it's a use case.
Also, when I teach programming to students, I and the class can benefit from a single installation. Just need Firefox! I don't need to worry about different IDE and I can focus on showing them the result in the same browser they use to see live code and debug code. I don't use fancy IDE and I hate full blown IDE for web app.
This integration makes me happy, makes some of us happy and that's how a software is. You don't have to like this decision, but it's in there, so try it when you have a chance and you may like it.
Nope. I can do this with Word, python -m SimpleHTTPServer, and a web browser to write code, test code and see code in live action.
Wait, what is Word being used for, in this process?
Wait, what is Word being used for, in this process?
Writing an essay to the security folks justifying using Python in a corporate environment?
Writing code. at least in open office you can create a new HTML document, don't have Word with me right now but in the old days I believe it was possible.
Well, you sure can save a Word document as HTML, but it spits out some of the grossest, most xml-metadata-crammed, non-human-readable HTML and CSS you have ever seen. God help you if you actually want to use Word as a WYSIWYG HTML editor. And have fun trying to add JS to it...
I strongly disagree. Just because economics have temporarily separated the means of creation from the means of consumption in some domains, there is no reason that they should not be recombined now that it can be done freely.
Why shouldn't all systems be programmable?
Why shouldn't all systems be programmable?
Sorry, but this looks like you're attacking a straw man. I never said that "not all systems should be programmable". My actual belief is, as a matter of fact, completely opposed to that.
What I'm saying is that you do and will for a long time need a degree of technical expertise to develop webpages. The gap is shrinking, but will exist for at least quite some time. I'm not being an elitist, just real. The technical expertise needed to browse even the most complex websites versus the one needed to put together even the simplest ones is far smaller. Why would putting this Web IDE into an add-on ever accent the border between creation and consumption?
It's good to have software with a single responsibility. All other things equal, Mozilla's Firefox division can maintain a web browser without an IDE better than they can a browser with an IDE. If Mozilla was to develop an IDE, it would be easier to split it into a separate piece of software (say an add-on) and dedicate another, different development team to work on it. That would be another program with a single responsibility.
This is vaguely reminiscent of the Unix way, and I'm very respectable of it, for the main reason that it's aligned with my personal philosophy (KISS), but also because it was able to create and sustain such a big community founded on openness and contributions and not driven by profit margins and managers in suits.
What I'm saying is that you do and will for a long time need a degree of technical expertise to develop webpages. The gap is shrinking, but will exist for at least quite some time. I'm not being an elitist, just real. The technical expertise needed to browse even the most complex websites versus the one needed to put together even the simplest ones is far smaller. Why would putting this Web IDE into an add-on ever accent the border between creation and consumption?
It's good to have software with a single responsibility. All other things equal, Mozilla's Firefox division can maintain a web browser without an IDE better than they can a browser with an IDE. If Mozilla was to develop an IDE, it would be easier to split it into a separate piece of software (say an add-on) and dedicate another, different development team to work on it. That would be another program with a single responsibility.
This is vaguely reminiscent of the Unix way, and I'm very respectable of it, for the main reason that it's aligned with my personal philosophy (KISS), but also because it was able to create and sustain such a big community founded on openness and contributions and not driven by profit margins and managers in suits.
"What I'm saying is that you do and will for a long time need a degree of technical expertise to develop webpages."
This is simply wrong. I was writing web pages with very little technical ability starting way back in 1996 because view source was built in and not an add-on and that made it easy to learn without any technical expertise. Today the web platform is richer and so it makes good sense for the view source of today to also be richer.
This is simply wrong. I was writing web pages with very little technical ability starting way back in 1996 because view source was built in and not an add-on and that made it easy to learn without any technical expertise. Today the web platform is richer and so it makes good sense for the view source of today to also be richer.
> I was writing web pages with very little technical ability
Yes, a little. Similarly, I sad a degree of technical expertise. Not a lot, just a little, but enough to differentiate the creator from the consumer.
Today, even if browsers don't have "View Source", you can search Google for "how to make web sites", and a zillion results would pop up. It's not a roadblock.
Today, even if browsers don't have "View Source", you can search Google for "how to make web sites", and a zillion results would pop up. It's not a roadblock.
Not everyone learns by reading a book or article. Lots of people learn by tinkering.
It's hard, if not impossible, to learn stuff exclusively by tinkering. I developed my interest in HTML because I clicked an "Edit in FrontPage" button in IE6 (or was it IE5/4?), but I don't think I could learn HTML in thorough detail just by poking around FrontPage. The Internet then came to my rescue.
My point is, even if IE didn't include that toolbar button, I would've started up FrontPage on my computer sooner or later. It was just a matter of timing and a string of coincidences. Some other string of coincidences could've led me there, too. I say that the argument "some people would tinker and by moving the IDE into an add-on wouldn't let them tinker enough" is pretty weak. If you're curious about something, you tend not to get stopped by things such as that: that curiosity drives you to poke around incrementally until you either find what you're looking for or fuck up the computer (well, at the time, this was something I was prone to doing often because I loved messing with Windows' system files :)
My point is, even if IE didn't include that toolbar button, I would've started up FrontPage on my computer sooner or later. It was just a matter of timing and a string of coincidences. Some other string of coincidences could've led me there, too. I say that the argument "some people would tinker and by moving the IDE into an add-on wouldn't let them tinker enough" is pretty weak. If you're curious about something, you tend not to get stopped by things such as that: that curiosity drives you to poke around incrementally until you either find what you're looking for or fuck up the computer (well, at the time, this was something I was prone to doing often because I loved messing with Windows' system files :)
Your argument seems to be that this makes it harder to engineer the browser, and yet you don't explain that at all.
You simply assert that it would be easier for Mozilla if they split it into a separate piece of software.
I see no specific reason to accept this as true, and you have not provided any.
You simply assert that it would be easier for Mozilla if they split it into a separate piece of software.
I see no specific reason to accept this as true, and you have not provided any.
I vaguely agree with you but I think comparisons with media players and text editors sell short how central web browsers are to computer use these days.
Moreover, adding more functionality to an application increases the surface area for attack. Adding it by default increases the risk for everyone.
i've had this thought for quite some time about a lot of the standards/features being implemented into the core. many of these cool things can/should be done as addons. it may make sense to bake them in for Firefox OS, but not for the standalone browser.
> We’re working on a protocol adapter that will allow
> clients using the Firefox Remote Debugging Protocol –
> including the Developer Tools and WebIDE – talk to all
> mobile browsers, regardless of rendering engine or
> runtime. Our first targets are Chrome for Android and
> Safari on iOS.
(And if I'm just an idiot who's overlooking some simple way of debugging mobile Safari, please let me know.)
> If Mozilla truly reverse-engineers Apple's remote debugging protocol it would be a godsend for us.
Google did this a while ago: https://github.com/google/ios-webkit-debug-proxy It works well for connecting Chrome DevTools to Safari, automating Mobile Safari through ChromeDriver, or hooking up your iOS device to a private instance of WebPageTest.
Google did this a while ago: https://github.com/google/ios-webkit-debug-proxy It works well for connecting Chrome DevTools to Safari, automating Mobile Safari through ChromeDriver, or hooking up your iOS device to a private instance of WebPageTest.
Thanks, I've never heard of this before and it sounds very useful.
...Or rather, it would be very useful were it not for the fact that it only appears to run on Linux and OS X, whereas my employer-granted computer is running—drumroll, please—Windows XP! And like I said, these are all internal applications, and I don't have the authority to VPN in on any computer that I please.
Ah well. Enterprise bureaucracy strikes again. :\
...Or rather, it would be very useful were it not for the fact that it only appears to run on Linux and OS X, whereas my employer-granted computer is running—drumroll, please—Windows XP! And like I said, these are all internal applications, and I don't have the authority to VPN in on any computer that I please.
Ah well. Enterprise bureaucracy strikes again. :\
Have you ever thought about quitting and working for a company that doesn’t treat you like a child?
What, and not get paid to spend half my time on HN while the ravages of Sarbanes-Oxley grind productivity to a halt?
(The funniest thing is that we're not even a public company, and have no shareholders to defraud. That's right, we opt in to Sox-compliance.)
(The funniest thing is that we're not even a public company, and have no shareholders to defraud. That's right, we opt in to Sox-compliance.)
That sucks, though it would definitely be much easier to run a virtual linux instance on that box than an OS X one as someone else suggested.
I will say that being able to debug pages in mobile safari directly (via Safari on a mac) makes a huge difference, so if this works even partially as well, it's worth investigating if you can get it running.
I will say that being able to debug pages in mobile safari directly (via Safari on a mac) makes a huge difference, so if this works even partially as well, it's worth investigating if you can get it running.
There is is a windows version too: https://github.com/artygus/ios-webkit-debug-proxy-win32
Linux virtual machine.
And that work is key to the stuff we're doing. Thanks again, Chrome folks!
Mozilla didn't have to reverse engineer anything. Firefox, Chrome, and Safari all aim to support http://remotedebug.org/
Not accurate right now. Firefox and Chrome spoke about this at EdgeConf this year, along with the remotedebug founder, and basically said "Please go forth and develop a shim layer common protocol in the community. However, all browser vendors standardizing to a common protocol would slow us down too much."
Video: https://www.youtube.com/watch?v=tQG6PljqmLc#t=1013 (around this timecode)
Hear, hear. None of this needs to be a standard to show a web page so I'm personally happy to let developers hack on what lets them be more productive, and let browsers continue to innovate. It's way too early to get a committee process involved, and innovation will happen faster this way.
Actually this article points to the reverse happening - they build bridges to be able to connect to each others protocol to work around having to use a common protocol.
So instead of a one-time cost, they'd rather bleed money due to lowered productivity? I don't know how much time you spend developing internal tools, but I'd expect the cost in lost time to surpass the cost of a few (possibly shared) development machines rather quickly.
Never underestimate the ability of managers to be penny wise and pound foolish.
...or the inability of developers to properly demonstrate to their managers why something is needed. simply saying it makes it easier is not enough, learn to sell and spin in a way that does not make you seem lazy and you will be surprised what you can convince people to do.
That's true. But managing a company is still the managers task, not developers. It doe not excuse them.
Which is why I'm increasingly bullish on the idea that the best managers in the future are going to be engineers that learned management skills.
Historically, software engineers have been the minority of the worker bees in a company. As companies trend towards more and more technical folk at the bottom of the work pyramid (not just software engineers, but anyone doing highly technical work that increasingly incorporates ways of working that have been the status quo among developers), managers are going to need to be able to understand the technical side more and more.
We'll eventually reach the point where it will no longer be enough for a developer to spend inordinate amounts of time convincing the manager what the right thing is. That works for the low hanging fruit that most developers can argue for. Once most if not all of the low hanging fruit has been picked, not picking the higher hanging fruit will be as much the fault of the manager as the engineers that need to convince the manager of their importance.
There will come a time where technically competent managers become a requirement, not just a luxury.
Historically, software engineers have been the minority of the worker bees in a company. As companies trend towards more and more technical folk at the bottom of the work pyramid (not just software engineers, but anyone doing highly technical work that increasingly incorporates ways of working that have been the status quo among developers), managers are going to need to be able to understand the technical side more and more.
We'll eventually reach the point where it will no longer be enough for a developer to spend inordinate amounts of time convincing the manager what the right thing is. That works for the low hanging fruit that most developers can argue for. Once most if not all of the low hanging fruit has been picked, not picking the higher hanging fruit will be as much the fault of the manager as the engineers that need to convince the manager of their importance.
There will come a time where technically competent managers become a requirement, not just a luxury.
The sad answer is that your co' is what is incorrect. If you have "executives" plural you have the budget in your organization to buy a dev mac and a dev device.
I agree that they're being foolish (though hey, they're the ones paying me to waste my time), but I'm just as peeved at Apple for removing a perfectly-workable self-contained solution in favor of yet more platform lock-in.
> but I'm just as peeved at Apple for removing a perfectly-workable self-contained solution in favor of yet more platform lock-in.
Peeved, but not surprised, given their track record.
Peeved, but not surprised, given their track record.
Here's a crazy idea: what if we stop buying apple products until they stop pulling this walled garden crap and we are free to use the overpriced hardware we paid for as we damn please?
That sounds like lunacy. How is the world supposed to buy overpriced brush metal technology?
I have never bought an Apple product. Not even a iTunes file.
Apple is still doing well, though.
Apple is still doing well, though.
I've never tried it, but how about this?
http://developer.telerik.com/featured/a-concise-guide-to-rem...
Or, run OSX in a Windows virtual machine? You could us Safari remote debugging then.
http://developer.telerik.com/featured/a-concise-guide-to-rem...
Or, run OSX in a Windows virtual machine? You could us Safari remote debugging then.
Are OSX virtual machines allowed now?
I mean, obviously you can do it at home, but a company has to be a little more careful.
I mean, obviously you can do it at home, but a company has to be a little more careful.
It's crazy how history repeats itself ... This reminds me of Mozilla Composer (http://en.wikipedia.org/wiki/Mozilla_Composer) back when the Mozilla Suite was still a thing and Firefox was in its infancy!
Not really comparable. Composer was a WYSIWYG editor for web pages; the WebIDE is an editor, but more importantly it manages the packaging and creation of manifest files of apps for you. I started with Composer and the output was so awful that I learned HTML instead. This doesn't hide any code from you or generates things you don't want. The templates of the apps are maintained by the community on GitHub.
I've always wondered why developer tools are bundled with browsers. Shouldn't they be available as separate downloads as:
1. Most people use browsers compared to working with them for development, and
2. The additional tools just add to the package size and possibly increased resource usage (if they are running with the rest of the browser)?
Thanks in advance for the replies.
1. Most people use browsers compared to working with them for development, and
2. The additional tools just add to the package size and possibly increased resource usage (if they are running with the rest of the browser)?
Thanks in advance for the replies.
Our devtools have unit tests that run for every tiny change that is made to Firefox. Building the tools in gives much more stability. We are also using and exposing a lot of low level Firefox stuff and fixing bugs as a result.
So in short you get a better, more extensible browser, more stability and the chance to take a look at how something you use every day works.
It's a win-win in my opinion.
So in short you get a better, more extensible browser, more stability and the chance to take a look at how something you use every day works.
It's a win-win in my opinion.
Regarding #2: The developer tools don't run unless they're opened, so that shouldn't affect any normal users.
Although every now and then a 'normal user' might get an unexpected surprise when they accidentally open them. Reminds me of this http://www.reddit.com/r/webdev/comments/1tkld5/my_facebook_s...
Doesn't that still add to the package size?
Yes. Bandwidth and additional HDD space are used. But web browsers data footprint is small. Installed FireFox consumes ~68.1MB of disk space. Which is microscopic in the days of TB Hard Drives.
I agree. I feel like mozilla is going back to it's roots of a multifaceted beast.
This should be a plugin like firebug.
This should be a plugin like firebug.
Resource usage of devtools that aren't running is near zero (there's a tiny bit of overhead to manage the menu items to launch it).
Download size is affected, although for larger parts of the developer tools (things like firefox OS simulators and adb) we use addons. We think that tradeoff is worth the benefits - users can look under the hood (even if most of them won't), developers have quick and easy access to tools, and we don't have to worry about things like version mismatch/testing concerns/etc.
Download size is affected, although for larger parts of the developer tools (things like firefox OS simulators and adb) we use addons. We think that tradeoff is worth the benefits - users can look under the hood (even if most of them won't), developers have quick and easy access to tools, and we don't have to worry about things like version mismatch/testing concerns/etc.
I imagine it's in the same spirit as including "View Source", so that ordinary users are empowered to figure out how a website works, should they want to.
1) The idea of the web is that the boundary between consumer and creator is very blurred. It is a world-wide, distributed environment. Making the tool you consume also the tool to create empowers a lot of people. Consider yourself a budding publisher on a very bad connection in an emerging country: you download a browser to surf the web, and that one now also enables you to create something for it. Downloading xCode or Android Studio would take ages. For developers, this is also an advantage: you use the same browser your end users have. In the past developer add-ons interfered with the rendering of the page and the performance of the browser. This gave you false results.
2) Whilst devtools make any browser bigger in initial file size (including Chrome and IE), it is not a large part of the main download (fonts are actually a huge one). The performance hit is to the overall computation (much like a standalone tool would) but isn't impeding on the browser performance itself.
[deleted]
Should/shouldn't is hard to say. But the fact that they are bundled with browsers is absolutely amazing, not for the professional developer, but for the amateur. The fact that you can start messing with a website with almost no additional effort and with no additional software is amazing. IMO, it's what makes the web one of the environments with the least friction to start programming in. Visible results, full-featured programming (via JS), and readily available tools.
Once you start getting into complex frameworks and what have you, you start needing additional tooling, more knowledge, etc, but that's fine. The point is to start tinkering, you only need a browser. To start doing a little more than tinkering, you need a browser and a text editor (not like Sublime, like Notepad; on day 0 you don't care that much about syntax highlighting). Both of these come out-of-the-box on any computer.
Once you start getting into complex frameworks and what have you, you start needing additional tooling, more knowledge, etc, but that's fine. The point is to start tinkering, you only need a browser. To start doing a little more than tinkering, you need a browser and a text editor (not like Sublime, like Notepad; on day 0 you don't care that much about syntax highlighting). Both of these come out-of-the-box on any computer.
I'd rather have features than have them removed. Considering the dynamic nature, jitting, etc, most of the runtime needed for development is already there. Might as well throw a UI on it.
I don't think Mozilla cares about the file size anymore. 10 years ago they cared about the file size of Firefox, the mandate was that it could not be greater than ~5mb, the stable download is now almost 6 times that size.
That wasn't a mandate. It was my proposal so I know. I suggested that we target "about the size of an MP3" because that was the most common unit of download that a lot of people understood in the early 2000s and downloading software was something people weren't terribly comfortable with. I did some quick estimates and came up with 4MB as the goal based on the size of popular MP3s. By the time we shipped Firefox 1.0 in late 2004, we managed to get the download to about 4.7MB.
That was 2004 though. Today the Web is a lot more capable because browsers are a lot more capable. Also, typical download bandwidth for consumers is a lot more capable than it was in 2004.
Most of the growth in Firefox download size since then is a result of Gecko/Web platform feature growth, not the GUI features that users interact with.
That web platform capability isn't free. It takes code to make JS dozens of times faster than it was in 2004. It takes code to add HTML5 and CSS 3 features, WebGL, WebRTC, and all of the other great stuff the Web platform includes today. That code makes the download larger.
That being said, I'd love to see another round of evaluation to see what can be trimmed or slimmed. I don't consider that the same priority it was in 2004 though.
That was 2004 though. Today the Web is a lot more capable because browsers are a lot more capable. Also, typical download bandwidth for consumers is a lot more capable than it was in 2004.
Most of the growth in Firefox download size since then is a result of Gecko/Web platform feature growth, not the GUI features that users interact with.
That web platform capability isn't free. It takes code to make JS dozens of times faster than it was in 2004. It takes code to add HTML5 and CSS 3 features, WebGL, WebRTC, and all of the other great stuff the Web platform includes today. That code makes the download larger.
That being said, I'd love to see another round of evaluation to see what can be trimmed or slimmed. I don't consider that the same priority it was in 2004 though.
The web 10 years ago was a great deal simpler than it is today (and that's kind of insane that we can say that).
luckily, my internet speed has increased about 1500x since then, so I don't even notice :)
It's true that most people use browsers as opposed to working with them for development.
The question is, do you want this state of affairs to be built into the design of our systems, or do you think that it would be good if, over time, a greater proportion of people are able to express themselves through code?
The question is, do you want this state of affairs to be built into the design of our systems, or do you think that it would be good if, over time, a greater proportion of people are able to express themselves through code?
Cautionary tale: They were bundled separately for Internet Explorer, and everyone assumed they didn't exist. Even now you can see people complaining that say, "developing for IE 6 was hard because it didn't have developer tools".
I think most of the developers I knew were saying "because it didn't have any good developer tools"
View source, the original developer tool, is why the Web is so generative and has been for two decades, IMO. Today's developer tools are just an extension of that ancient view source capability.
The web is not like other platforms where there's a hard line between people who make it and people who use it. Many people, like myself, thought of themselves as users until the web's view source made it possible for us to become content producers with no significant additional tooling.
Today, the Web is a lot more complex a platform than it was in the early 90s and so our view source and JS consoles have evolved into more capable developer tools as a result.
The web is not like other platforms where there's a hard line between people who make it and people who use it. Many people, like myself, thought of themselves as users until the web's view source made it possible for us to become content producers with no significant additional tooling.
Today, the Web is a lot more complex a platform than it was in the early 90s and so our view source and JS consoles have evolved into more capable developer tools as a result.
Developing a moderately complicated plugins on Firefox and Chrome is a major PITA currently (not to mention that JavaScript is... somewhat moderately PITA to deal with as well).
I just wish that these vendors behind web browsers would put more effort on cleaning up their acts on the plugins development as well (stable and useful docs, tutorials, more tutorials, and mooooreee tutorials, sane development environment without jumping through hoops, better integration with IDEs and whatnot), not just building infrastructure upon infrastructure in which the development and deployment to the said infrastructure is PITA.
I just wish that these vendors behind web browsers would put more effort on cleaning up their acts on the plugins development as well (stable and useful docs, tutorials, more tutorials, and mooooreee tutorials, sane development environment without jumping through hoops, better integration with IDEs and whatnot), not just building infrastructure upon infrastructure in which the development and deployment to the said infrastructure is PITA.
This is amazing work. I hope it continues to go even further. I'd like to see a browser that is really just implemented on top of a kernel with full programmatic access to everything from the top down: just as Emacs happens to be a text editor built on the elisp kernel, Firefox could happen to be a browser built on a web kernel.
Everything that drives the UI are just functions that could just as easily be invoked from the scratch pad. If you know a bit of javascript you can write a few of your own functions to automate some common browsing tasks. And if you need even more functionality you can dig deeper and write your own libraries that seamlessly integrate into the kernel without a hitch and can be invoked from your own menus.
No plugin tom-foolery or artificial walls around the garden.
Looking forward to seeing how this develops!
Everything that drives the UI are just functions that could just as easily be invoked from the scratch pad. If you know a bit of javascript you can write a few of your own functions to automate some common browsing tasks. And if you need even more functionality you can dig deeper and write your own libraries that seamlessly integrate into the kernel without a hitch and can be invoked from your own menus.
No plugin tom-foolery or artificial walls around the garden.
Looking forward to seeing how this develops!
You are pretty much describing the Firefox architecture. We are invoking Firefox UI code from scratchpad all the time when prototyping things. Some parts of the UI do not use standard Web APIs (e.g. XUL and XBL), as there are different opinions on how the web platform should evolve to fulfill those needs, but if you include all the experimental technologies to this web kernel, we are already there.
It's neat and all, but please Mozilla, don't include this with Firefox. At the very least, have a separate lean-version that doesn't have this "fluff" included. And a developer/power-user version that includes it. I understand that web-app development is big, and it's the "new-desktop", but that doesn't mean that this awesome browser should include everything and the kitchen sink.
If it’s anything like the existing developer tools it’ll be fairly hidden and lazy-loaded when needed. I wouldn’t worry too much.
Looking forward to the new Pheonix when someone gets fed up enough with the current heavyweight Firefox to write it.
The challenge here is that Gecko is the heavyweight bit here, not Firefox. If you wanted to shrink the size of Firefox dramatically, you could not do so without removing Web functionality (as opposed to Firefox functionality.)
I'd love to see someone give that a shot. It was really three or four people who "Firefoxed" the old Mozilla Suite and there's nothing stopping some similarly motivated group from giving it a go.
Still, I don't think they'd get nearly as far as we did back in 2002 and 2003, because Firefox is actually very trim and fit. There aren't a lot of extra features to cut and the code implementing most features is smart enough not to waste resources when not in use.
I'd love to see someone give that a shot. It was really three or four people who "Firefoxed" the old Mozilla Suite and there's nothing stopping some similarly motivated group from giving it a go.
Still, I don't think they'd get nearly as far as we did back in 2002 and 2003, because Firefox is actually very trim and fit. There aren't a lot of extra features to cut and the code implementing most features is smart enough not to waste resources when not in use.
Google is working on an IDE inside Chrome, too. It's called Spark: https://github.com/dart-lang/spark
Yay! Can't wait to download an even bigger package to update my browser.. now with plenty of features I don't need.
Looking forward to the {emacs,Lua,Perl}-embedded-Firefox!
It makes sense so ship an editor with a reader. So that you can communicate both ways, both create and consume. Now we only need a way to share!
Anyone know how I can access this on Windows XP? Don't seem to see the option to click "Web IDE" on Developer tools?
App Manager. The label will be renamed in tomorrow's Nightly/
You have bigger problems then how to run "Web IDE"... Why are you running Firefox nighties on Windows XP? You trying to have the most unstable and insecure box possible?
You need to enable it by flipping devtools.webide.enabled to true in about:config first.
The menu option is still named "App Manager" in today's Nightly. It will be renamed to WebIDE in tomorrow's build.
Netscape had an editor way back when also.
Holy shit that's cool! Makes me want to get a FF phone.. just about now!
Always glad to see more things happening in this space, but most devs already BYOIDE and would probably just like better integration with their existing tools:
http://remotedebug.org/
http://remotedebug.org/
Integration with external editors/IDEs is a very important part of this project. A lot of what WebIDE brings to the party on top of normal editing is device/simulator management as well as the usual Developer Tools inspection and debugging.
So there are three layers of compatibility we expect to see with external IDEs:
0) No integration - Open a WebIDE window with editing turned off and use it (or command line tools that drive it) to manage device connections/pushing/etc. 1) Simple integration - Most of the basic device connection management will be available through command line tools, it should be incredibly easy to drive that through editor/IDE configuration. 2) The whole nine yards: Speak a remote debugging protocol and get full control over the debuggee.
As far as the whole nine yards, you can either use remotedebug's protocol and proxies (although development seems to have trailed off there?), speak each browser's protocol natively, or maybe down the road the protocol abstraction we're working on at Mozilla.
So there are three layers of compatibility we expect to see with external IDEs:
0) No integration - Open a WebIDE window with editing turned off and use it (or command line tools that drive it) to manage device connections/pushing/etc. 1) Simple integration - Most of the basic device connection management will be available through command line tools, it should be incredibly easy to drive that through editor/IDE configuration. 2) The whole nine yards: Speak a remote debugging protocol and get full control over the debuggee.
As far as the whole nine yards, you can either use remotedebug's protocol and proxies (although development seems to have trailed off there?), speak each browser's protocol natively, or maybe down the road the protocol abstraction we're working on at Mozilla.
Is this itself entirely a webapp?
As an aside, I'm amazed the way Mozilla have co-opted the term "Web" to mean whatever they want it to. The way they've branded all sorts of non-standard APIs in FFOS "Web" APIs to confuse people into thinking these are somehow more open than anything else is impressive.
As an aside, I'm amazed the way Mozilla have co-opted the term "Web" to mean whatever they want it to. The way they've branded all sorts of non-standard APIs in FFOS "Web" APIs to confuse people into thinking these are somehow more open than anything else is impressive.
> Is this itself entirely a webapp?
Actually, yes: http://dxr.mozilla.org/mozilla-central/source/browser/devtoo...
Actually, yes: http://dxr.mozilla.org/mozilla-central/source/browser/devtoo...
XUL is a web technology now?
That's my point. It's not.
EDIT: ici: http://dxr.mozilla.org/mozilla-central/source/browser/devtoo...
That's my point. It's not.
EDIT: ici: http://dxr.mozilla.org/mozilla-central/source/browser/devtoo...
There is no XUL in there.
Last time I checked, the vbox/hbox is XUL. https://developer.mozilla.org/en/docs/XUL/vbox
Sure, but that's only in index.xul, which is a very small part of the project. Everything else is plain old js+html (xhtml necessary for localization). Apologies, I didn't notice that when I said "there's no XUL in there".
As a meta-discussion, <vbox> is just a fancy way of saying:
div { display: -moz-box; -moz-box-orient: vertical; }
...which is the old flexbox implementation. But I digress :)
edit: link to the MDN article about `display: box`: https://developer.mozilla.org/en-US/docs/Web/CSS/box-orient
As a meta-discussion, <vbox> is just a fancy way of saying:
div { display: -moz-box; -moz-box-orient: vertical; }
...which is the old flexbox implementation. But I digress :)
edit: link to the MDN article about `display: box`: https://developer.mozilla.org/en-US/docs/Web/CSS/box-orient
We could probably rewrite the entire Firefox UI in HTML nowadays, but that'd mostly be busywork (and would break a bunch of extensions). I would bet that Servo's UI will just be HTML.
Servo is just the browser engine, like Gecko. The UI/browser-chrome will be a separate project (named Crow, but not started yet afaik). Also relevant is the fact that Servo wants to be embeddable, like Webkit.
Mozilla lost their focus long ago. They are now mostly political organisation with side busines of making software and financed by a competitor.
I loved them so much since the days of the Phoenix (I think it was 0.6 which I made my default browser), I admired Blake Ross. They had a great goal: to make the best browser.
Now? I couldn't care less. I don't know who the leader is, or do they even have one. I know they are good I writing manifestos and have some evangelists not too shy to lie.
Will those political games help anyone? I doubt so. But if once great organisation is determined to become irrelevant, how can you forbid that?
MDN is good, though.
Mozilla is not Apple, they can very much function without a leader.
They have the ONLY fully featured modern browser that is also free software. IMHO, it fits the "make the best browser" philosophy.
They have the ONLY fully featured modern browser that is also free software. IMHO, it fits the "make the best browser" philosophy.
As I've said elsewhere, a lot of kids still assume that programming is essentially "magic" done by professionals and they implicitly assume there is no way to getting started at their education level (This is especially true if their parents are non-technical, as mine were). All the resources in the world may exist, but they may not be obvious unless you look for them. When I was a kid I assumed that programmers were all professionals with a billion years of training and their own special equipment. Today I know the only difference between a programmer and a yet-to-be-programmer kid are bigger feet and a coffee addiction, the computers are the very same. But I didn't know that back then - I wish someone told me.
I think it is extremely healthy to have the lowest bar possible to go from "Hey I like that" to "Can I do that? Can I make it myself?" Putting an IDE inside the browser, having no other dependencies between viewing web-pages and making web-pages is an incredible first step.
I await the day any kid asks "How do I make my own webpages?" and we can answer "You've already got everything you need, just press F12."
There's an art to making seemingly insurmountable things appear doable, like becoming a programmer if you have no programmer role models, and I think we should give it more attention. The web makes it easier than ever, and while a bundled IDE isn't going to be the Geocities or Bob Ross equivalent, it's definitely the next step in reducing the friction of getting started.
Bravo, Firefox team.