HTML is ASCII.
Right now the terminal is our window and it is nothing but colored ASCII. You can create something interactive and "graphical" like vim or emacs inside of it, but then you can't ship that complete dev environment very easily... it has to be rebuilt from scratch by the individual programmer.
The web makes it very easy to ship interactive, dynamic documents and environments around.
I understand what you're saying, but the problem is, I don't want to have to use the preferred editor of the person that happens to be maintaining some random projects I'm editing. I like my VIM and my grep, and my colleague likes her Eclipse and her InstaSearch.
Now, that doesn't mean we should eschew all metadata, but I rather see some structured data formats that can be interpreted by the editor and fitted to the user, instead of the other way around.
In fact, I'd rather see the web itself move more in that direction. HTML/CSS may be wonderful in terms of the freedom they give to the developer, but it's no free lunch: we lost a lot of potential interoperability by going with free-form, unstructured formats instead of more content and less design driven ones.
Can I please point out that building graphical interfaces in ASCII is just about as bone-headed as my suggestion? :)
We can, that's not the issue. The problem is that if you embed an editor - any editor - into the project, you're forcing everyone to use it, while currently each developer has the freedom to choose his own.
And if don't embed the editor, then there's nothing to discuss; one can already use web based editors if one wants to, and I can use VIM ;)
Can I please point out that building graphical interfaces in ASCII is just about as bone-headed as my suggestion? :)
The whole reason I like VIM is because it barely has any graphical interface. The whole experience is extremely content focused, without a mess of buttons and toolbars obstructing the vision. I talk to it[1], it does what I tell it, and it stays out of my way.
So I agree, but it doesn't apply in this case :)
[1] http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...
But then, how do we ship around the source editors meta data that is REALLY important, like, custom DSL syntax highlighting?
Do we need a universal syntax highlighting engine? What other universal engines do we need to build interfaces in to Emacs and Vim and Eclipse and XCode and Visual Studio in order to tackle some of these issues?
Why not embed the whole OS? Now it is starting to sound like the apple ][ days.
Running editors (or whole operating systems, for that matter) in a browser seems like a backwards way of solving this. If you really need to ship a whole development environment including the editor, and not just the config files, project files or syntax highlighting plugins, you might as well use a virtual machine. If a programmer has no idea of how to set their editor of choice up for what they're developing, they won't be building a decent development environment in Javascript.
And this isn't about developers knowing how to set up their editors. It is more about DSLs. It is more about the fact that there is more to coding than just writing source. Hell, it is about trying to come up with a way that we aren't totally beholden to source! It's just data, and frankly, not the most important data around software!
Sometime other paradigms, and I don't just mean other languages, but things like spreadsheets, graphs, and visual languages can be great DSLs that properly model and convey information MUCH better than source... but you can't really embed those in eclipse or vim, can you?
Think about if you released a project on GitHub and it didn't have tests, documentation, or example use. Would anyone use it? What if it was competing with other projects that DID have tests, docs, and examples? What is that code with tests was slightly worse? Which project are other developers going to want to interact with and use?
We live in a world were our programs, our source, and our peers live in a distributed ecosystem and as far as I can tell our tools and operating systems are starting to get in the way.
Have you seen how awfully messy web development becomes when you try to bootstrap from a filesystem? Things like JSFiddle are MUCH more elegant, but are, how shall I put it... missing some key tools for a new ecosystem of distributed computing. ;)
Also, if you're using characters or glyphs to write code. It's always ASCII (or your character set of choice). It doesn't matter if it's in the browser or in a terminal. HTML presenting the code that your writing is just cruft.
And I've got this other thing called my web browser. It also has a bunch of tabs, and each one of those tabs is a little "runtime" as well. This one just happens to support embedding images, video, audio, non mono-spaced fonts...
My terminal runtime communicates through the filesystem. (it's UNIX, files all the way down...)
My web browser "runtime" communicates through HTTP.
That's all I'm sayin'.
---
Also, I KNOW why UNIX is all files and I get the whole concept of piping ASCII around... yeah, it's fucking awesome! And it's why UNIX is STILL around. It'll be around forever, and man, I DO like it, but should we use it for everything? Why?
Piping ASCII around only gets you so far. :)
Why am I getting so much HN downvote love for talking about some of the downsides of the UNIX-way?
BTW, are you familiar with Literate Programming by Donald Knuth?
And the reason I'm mentioning the web is because, well, it's a nearly universal runtime and the best thing we've got that might get a lot of really important and forgotten about concepts from Smalltalk back in to the mainstream of computing!
Also, are you familiar with Don Knuth's Literate Programming? Thoughts on that?
(And yes, I realize this thread is going absolutely everywhere, but I've got a lot of questions!)
No more than than the web browser vis-à-vis the kind of editors you're talking about. They're built on top of the graphical APIs, much like web apps are built on top of HTML/CSS/JS.
(Note that I'm referring to graphical editors like Eclipse or Sublime, not ncurses editors in a graphical terminal emulator)
And the reason I'm mentioning the web is because, well, it's a nearly universal runtime and the best thing we've got that might get a lot of really important and forgotten about concepts from Smalltalk back in to the mainstream of computing!
Maybe, but without a concrete example / vision, I find it hard to believe that I'd be willing to lose the comfort of my development environment for the hack-y, keyboard-hostile world of web applications.
Also, are you familiar with Don Knuth's Literate Programming? Thoughts on that?
In a very vague way; it didn't really appeal to me, sorry.
+1 The more prose can be kept out of code the better.
Or are you strictly in the camp that if it is machine-readable and works properly that you've done your job?
HTTP is just piping around ASCII.
I don't think you're getting down voted for talking about the downsides of UNIX. You haven't actually mentioned a downside of UNIX, you've just suggested that we should switch to some other model.
I'm saying that instead, we just ship all the tools along with the code... and you can do that in browserland, and that's NOT the UNIX-way at all!
...it has nothing to do with HTTP, it has to do with the web browser runtime as compared to the runtime built on top of a filesystem!
UNIX land doesn't not play well when running any arbitrary stuff that comes it's way... sure, it might not have root, but, uhm, yeah if some code wipes out my entire user account, I'll be pretty bummed out... that's not gonna happen in the browser with it's sandboxed environment that has been battle-tested by trillions of page requests!
Find me another runtime that is as many places and is readily available to run third-party, untrusted code, and I'll happily jump ship! (aint gonna happen!)
* poor marketing * expensive, closed license * not enough effort put in to tooling
But almost everyone agrees that there is a LOT that was lost when Smalltalk didn't take over the marketplace... the point is, it wasn't because they didn't go with the concept of a filesystem...