This looks pretty awesome, I was about to suggest you put it on kickstarter but then realized it's already backed by adobe which is pretty cool. Could you tell us how involved Adobe is in this project and what their goals are? Do you plan to make it usable directly from the browser using the file system API? Do you plan to support other languages such as ruby and python? Also you kind of sound like Abed from Community :)
The only browser to implement the File System API right now is Chrome, and it obfuscates the actual files it saves on your hard drive. I don't know that we yet have a browser-based API that lets you arbitrarily access the user's disk.
In principle, you should be able to trivially turn this into a WinRT app. This way you could write to temp file storage for your app and render out of that. You could keep the codebase isolated for the cross-platform browser bits and have WinRT integration code as a separate project.
Well, if there is a proper permission system to go with it I don't think that's a bad thing. We want web apps to become as powerful as desktop apps, don't we?
When it comes down to end users permission systems never work. Let's take Android as example. It allows you to view fine-grained permission list for each application which you are going to install -- that's good, right? For end users -- not so much. They click "OK" just to remove all this useless information and install their application right away.
Permissions on Android suck because they aren't fine-grained enough. Maybe today I want an app to have this privilege but not tomorrow. Maybe I want this feature that requires this permission, but not that feature that requires that permission. Rather than a blanket EULA-style shrink wrap grant of permissions up front.
I think it's true that the Android permission system is not very good; an application with zero permissions can read everything on the SD card. However, I'd like to think this is just a weakness in Android, rather than proof that permissioning system for end-users don't work.
Are there any other recent examples of poor permissioning?
Maybe the fact that programmers are typically more considerate about this, but it has no "real" benefit to end users, leads to the whole design/workflow not getting much attention.
Yeah, Chrome only support is a bit limiting. I'd love to be able to do same with Firefox in the near future (1-2years). I do hope they implement that File API soon.
Looks great, game changing in fact. It seems to be quite inline with Brent Victor's vision (http://vimeo.com/36579366). One thing I'd like to see stolen from his demo: Once you have direct visual feedback on what you're doing, it makes a lot of sense to have widgets for your style definitions, e.g. scales with handlebars and color pickers popping up when the cursor is over values with corresponding type. It's a great thing that this project is both funded and open source. Quite unexpected from Adobe tbh.
I just wanted to give this a try, but the "single" part not written in HTML, CSS and Javascript (the native shell it runs from) has not been ported to Linux yet.
There's 2 ways we can get to a Brackets running on Linux. The first option is to add a linux target to the new CEF3 based brackets-shell app. We still need the shell app to get native file system access. We've also experimented with running nodejs on the client side and getting file access over WebSockets. Brackets is then hosted on a nodejs HTTP server and run inside of Chrome instead of CEF3. This solution works, but we haven't pushed this much further than a prototype yet.
Do you have a repo with this prototype? I would really like to see this possibility pan out. I think using node to interface with file system is the most feasible and portable at this point.
Looks useful for static pages, but a lot of the shiny features wouldn't work for any site designed using a template library (which is any dynamic site).
Spot on. Any sufficiently complex website won't benefit from this. How would your code editor know which CSS (or even beter, Sass) files apply to which pages? No way.
I'm hoping sourcemaps come to the rescue. We already have this for JS, but the support isn't deep enough. We need support for sourcemaps for templates and css (and even sprites!).
If you tried to apply the same thinking to everything in the UI, you'd hit sprites soon enough. It'd be interesting to have enough info that given an (x,y) in an image we can say what the source files were. This is the kind of thing where the http header in that sourcemaps v3 proposal would apply.
I had the same initial reaction, but then thought "It's actually quite cool that adobe supports a project that builds something cool and useful based on adopted standards." Adobe has always been a mixed bag, some good and useful ideas (they created the PDF document format) and some rather less good ideas. (Though actually flash was cool at the time it was created. Everybody loved flash). So why not brackets a chance to earn a reputation on it's own.
I thought exactly the same thing.. I was totally on board and excited until I saw, duhnduhnduhnn... "github.com/adobe/brackets"
Then I fled. And a lot of other people probably will, too -- Adobe has a lot of things to make up for with the kind of people who could actually make a meaningful contribution.
I'd say that launching an MIT-licensed project hosted in an environment that trivializes forking should go a long way to allay the fears of the majority of those kinds of people. On top of all of that, this is a line-of-business application for them -- it seems fair to assume that a web IDE is something in which Adobe will plan to maintain its investment.
> Adobe has a lot of things to make up for with the kind of people who could actually make a meaningful contribution.
Like what?
Personally, while I'm not happy with every move or product Adobe's ever made, I think by and large their contributions to the web have been a net positive.
Looks good but this wouldn't fit into the modern-day front-end developer workflow. I'm talking about companies who use pre-processors like SASS, LESS, Stylus, CoffeeScript, Jade, HAML, etc.
As for live code-editing feature, you can already do a lot of these stuff in Chrome's developer tool.
Note: I'm a Vim user. Which I personally think is still the best text/code editor in the world.
I suppose we'll be seeing more Codemirror based editors wrapped in Webkit in the future. Well at least one more I'm sure, because I've been implementing one too. You couldn't believe how fast one can actually churn a cross platform mediocrish editor given all the great quality tooling (QTWebkit, Bootstrap, Codemirror).
The just listen, it's paraphrasing the guy word for word so I stopped reading after a couple of seconds and focussed on the actualy live screencast parts :)
Where have you been all my life? Oh right, it still doesn't fully exist yet, but I'm excited to contribute because being a purely JS dev I could see this saving me loads of time and frustration.
Quote from The Brackets blog post "There are a lot of text editors out there, but not too many care exclusively about web developers" -- This is exactly why I'm building LIVEditor (http://liveditor.com)
If you find the CSS live preview stuff cool, check out http://cssrefresh.frebsite.nl/
It's awesome. Even with complicated, nested templates and CSS stuff.
a js scriptable modern editor is a project I wanted to build myself, if only I already had nuff time and money ;) no someone did it for me - how cool is that!
Now we only need to figure out one thing - way to make it properly support vim bindings ;)
"We can also apply the same ideas to JavaScript development. Smash the Quick Edit key on a function call and Brackets opens an inline editor with the JavaScript function body ready for edit. Instead of managing documents, developers can dive in and out of their code with ease."
What, not a single mention of the real world? You know, where if you hit something with a hammer, it's hit with a hammer, and it applies the hammer hit to the real thing instead of you having to close the browser window to hit the real thing again after simulating the hammer hit?
"Because it’s built in JavaScript, HTML and CSS, if you use Brackets, you have the skills necessary to customize, extend and contribute to it. Easy to fork and with a flexible and open license, it truly is your editor. In fact, when you first open Brackets you’ll be looking right at the Brackets source code. On the team, we use Brackets to develop Brackets in this weird inception-style-yin-and-yang type of thing."
My thing is like that too, especially the inception thing, but its better for a lot of reasons because its more than just an editor and is designed to be easily extended with plugins/components.
Anyway so good try Adobe, but if Adobe really wants to do the right thing, support the open web, and build a really useful tool, they should scrap Brackets, fork my project, and start promoting that. LOL sorry dickish thing for me to say but true.
Judging by the git repo, brackets has been in development significantly longer than your project. It also seems much more complete already.
And your project doesn't seem to be designed as an IDE, but rather a blogging engine with a strange focus on code editing. How exactly are the projects similar?
Thanks for looking at the video. One thing I should mention is that I have spent a day or so on the UI since then so it looks a lot more modern at the moment.
Anyway, I don't see how my project is related to OPML Editor really.. then again its not really easy to see the details of what that does from the web site.
But anyway my thing is about GUI controls that include the front and back end code and plugins to install them. GUI controls/widgets are an old and obvious and proven concept. The separation between front and back end coding, CSS and some other things that have happened with web development were practical approaches for awhile, but now with the web as platform, they are obviously a bit of a regression. There is just a very strong tradition now, a whole generation of CSSers and RESTers that just can't think any other way and unfortunately sometimes don't even talk to each other.
Widgets and plugins are a no-brainer.
So basically what we have confirmed is that I have more useful software development knowledge than the entire web team at Adobe.
Brackets probably has been in development longer and is more complete in a way. But the point is that although it goes a little bit in the right direction, it doesn't go far enough.
The code editor is a component that adds a button to the left hand side, which then opens up a window with CodeMirrors built in for editing the HTML/CSS/Browser side CoffeeScript/ Node.js on server side/external css/js files/package.json for the selected component. Then when you hit save it sends all of those files to the server, compiles CoffeeScript, runs npm if necessary. If there are errors it pops them up in a message box. If there are no errors it restarts the server and reloads the page. So it is an IDE.
Another similarity is the idea of keeping together different aspects of a component such as the HTML and CSS. I take it farther by including the other parts I mentioned above.
Blogging is just the most common type of application so I need to make sure it works for that for starters.
