[surreal]

Some helpful tips, thanks William. It would be helpful if you explained WHY these are better than jsfiddle though - I'm not disputing that they may well be, but most of the points you list apply to jsfiddle too making your opening remarks a little confusing. What do these do better?

[rm82]

Well, most of those use the ACE editor component, rather than the CodeMirror editor component.

I don't know why and obviously, this isn't true for everybody, but i'm always at war with CodeMirror. It auto-outdents and reformats things exactly how i do not want them. Whenever i'm forced to use CodeMirror, i'm undo-ing more than i'm typing and swearing about once every 5 seconds.

So, if you are one of those people, like me, that is always getting furious at jsFiddle, try an ACE based alternative.

Interestingly, once you realize that these code-editor components are quite simple to implement on a web-site, you also understand why there are 100+ jsFiddles clones. Most, if not all web-devs should be able to create one in half a day. They may think it's harder before they begin, but they will be pleasantly suprised.

This is likely also, why we're seeing a new "Online IDE" every week these days. GitHub's new Atom.io editor is the first one in a long time, to not use CodeMirror or ACE at its core.

[filearts]

Given how easy it is these days to re-implement jsFiddle, I agree that it is not surprising to see clones popping up all over the place. The fact that we have access to high-quality editor components with simple API's means that we can do this sort of thought exercise in a day.

What becomes interesting, though, is taking these ready-built components and trying to improve on the paradigm and the user experience.

With Plunker (which was originally inspired by jsFiddle and some of its short-comings) I've been trying to build tools around the core experience to make prototyping easier for the modern web developer.

Something that you won't find anywhere else is Plunker's package catalogue [1]. What is particularly unique about this is that it allows you to quickly find and 'insert' package dependencies into your markup in a way that resolves dependencies and in a version-aware fashion. These packages can be combinations of js and css. The web-based-IDE lets me take an approach that isn't viable for offline alternatives like bower and component but that is much easier from the user's perspective. A side-benefit of this approach is that all templates on Plunker can be made to auto-update to the latest (matching semver) version when they are opened or on-demand.

As I continue working on Plunker, this is the sort of feature that I hope will help it distinguish itself from the hordes of look-alike clones. Right now, I'm working on a new UI for the editor to allow a more flexible approach to editing files in a column/row grid [2].

1: http://plnkr.co/edit/?p=catalogue

2: http://embed.plnkr.co/TUbrV6UdmTgl61eAlRj4/preview

[filearts]

  "Wow, plunker seems really nice. You really do make a strong case with the package catalogue."

Thanks!

Server-side processing:

If you make a style.less file and link to style.css from your markup, the less will be transpiled by the preview server. This applies to most compiled web languages (including ES6: script.es6.js -> script.js). If something is missing, I'll do my best to add it.

Collaborative editing:

Yes, this is true collaborative editing thanks to ShareJS [1]. However, at the moment, I have an issue hidden away somewhere whereby a streaming session may be corrupted when several users are concurrently editing. I have been unable to boil it down to a reproducible case though.

1: https://github.com/share/ShareJS

[rm82]

Wow, plunker seems really nice. You really do make a strong case with the package catalogue.

Some questions though:

Would you consider adding automatic server-side proccessing in the future based on file-extension? For example, compiling .less to .css on the fly?

I think, one of the more interesting directions of a web-based IDE is that they can stop pretending to be a file-editor on a file-system.

I also notice streams. Is this true collaborative editing?

[williamnewton]

+1 for plunker next, hell yeah. Thanks for sharing.

[Uehreka]

I love that it's easy to implement an editor in the browser these days. It means that if you have an innovative IDE concept, you can push out a prototype in a day and not have to worry about all the yak-shaving that goes into making a basic editor.

[rm82]

I'm actually hoping for a transition to a situation where your favorite web framework, will come with its own web-based IDE.

Esspecially at the web-development side of things, IDE integration isn't optimal. It's not so much that the languages themselves need better integration; it's the frameworks, and the abstractions and tooling they bring.

When it gets this easy to create a web-based IDE, why even bother trying to develop a one-size-fits-all super IDE? Why not just have a simple IDE that targets one particular framework and its (likely opiniated) workflow? I mean, right now, most of that stuff, targets the command line as their primary UI.

[Touche]

Many of these are open source, which jsfiddle is not.