
WebIDE lands in Firefox Nightly - codepo8-hn
https://hacks.mozilla.org/2014/06/webide-lands-in-nightly/
======
simonsarris
This is _fantastic_ and I'm really glad it's being bundled with Firefox and
not as a separate download.

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.

~~~
akx
> 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](http://en.wikipedia.org/wiki/Netscape_Composer)

~~~
zimbatm
[http://www.w3.org/Amaya/](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).

~~~
tbe
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.

------
thegeomaster
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.

~~~
phkahler
"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?

~~~
fidotron
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.

~~~
mercer
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...

------
kibwen

      > 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.
    

My company expects all of our internal web applications to function on the
executives' iPads, but they refuse to purchase Macs on which to debug issues
that manifest only on mobile Safari. And since the mobile Safari developer
console was disabled in iOS 6, I haven't come up with anything better than
alert-based debugging techniques (Firebug Lite was broken the last time that I
tried, though admittedly that was a while ago). If Mozilla truly reverse-
engineers Apple's remote debugging protocol it would be a godsend for us.

(And if I'm just an idiot who's overlooking some simple way of debugging
mobile Safari, please let me know.)

~~~
stebemops
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?

~~~
bergerjac
most customers don't realize the garden is walled.

~~~
gress
Most customers have a better experience _because_ it is walled. Those who
care, should indeed not buy Apple products.

------
makmanalp
It's crazy how history repeats itself ... This reminds me of Mozilla Composer
([http://en.wikipedia.org/wiki/Mozilla_Composer](http://en.wikipedia.org/wiki/Mozilla_Composer))
back when the Mozilla Suite was still a thing and Firefox was in its infancy!

~~~
codepo8-hn
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.

------
Deutscher
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.

~~~
jaredmcateer
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.

~~~
asadotzler
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.

------
edwinnathaniel
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.

------
agentultra
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!

~~~
past
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.

------
zo1
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.

~~~
robin_reala
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.

------
mongrol
Looking forward to the new Pheonix when someone gets fed up enough with the
current heavyweight Firefox to write it.

~~~
asadotzler
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.

------
niutech
Google is working on an IDE inside Chrome, too. It's called Spark:
[https://github.com/dart-lang/spark](https://github.com/dart-lang/spark)

------
dschulz
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!

------
z3t4
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!

------
BaconJuice
Anyone know how I can access this on Windows XP? Don't seem to see the option
to click "Web IDE" on Developer tools?

~~~
codepo8-hn
App Manager. The label will be renamed in tomorrow's Nightly/

------
chippy
Netscape had an editor way back when also.

------
dingdingdang
Holy shit that's cool! Makes me want to get a FF phone.. just about now!

------
binarymax
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/)

~~~
campd
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.

------
fidotron
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.

~~~
blueveek
> Is this itself entirely a webapp?

Actually, yes: [http://dxr.mozilla.org/mozilla-
central/source/browser/devtoo...](http://dxr.mozilla.org/mozilla-
central/source/browser/devtools/app-manager)

~~~
fidotron
XUL is a web technology now?

That's my point. It's not.

EDIT: ici: [http://dxr.mozilla.org/mozilla-
central/source/browser/devtoo...](http://dxr.mozilla.org/mozilla-
central/source/browser/devtools/app-manager/content/index.xul)

~~~
blueveek
There is no XUL in there.

~~~
spacefight
Last time I checked, the vbox/hbox is XUL.
[https://developer.mozilla.org/en/docs/XUL/vbox](https://developer.mozilla.org/en/docs/XUL/vbox)

~~~
blueveek
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](https://developer.mozilla.org/en-US/docs/Web/CSS/box-orient)

~~~
tedmielczarek
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.

~~~
ehsanu1
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.

