Hacker News Reader

This is quite honestly the best new feature we could be given. It's not an easy task, but such a tool could save millions of man-hours.

Mozilla guys: if you implement this--even partially--I'll switch back to Firefox in a heartbeat.

I'm the author of http://tin.cr, it tries to solve this exact problem for Chrome Devtools. (someone else mentioned this in this thread).

I've spent some time thinking about the problem. In an ideal world a standardized protocol to push changes to a server would be awesome. I think it's unrealistic though to expect widespread adoption especially for existing frameworks to add code just for doing this. For example, have you ever heard of WebDAV? It was thought up along the same lines and it's virtually dead now.

A better solution for now would be for source maps to tell you the full local path to the original source file. Yes, in a world where we all develop from Chromebook-like devices against files in the cloud, this won't work. We are a long way from that world at the moment.

Neat. Out of interest, how does Tincr compare to LiveReload or CodeKit?

At the moment, it has two big drawbacks compared to those two

* The live reloading doesn't support full refreshes. You can only do live updating inside the running page. Chrome has built-in support for this. Works awesome for css. JavaScript support is a little flaky. * It doesn't support re-compiling Sass, LESS, CoffeeScript, etc. on a file change.

I'm actively working on fixing both problems.

This was the original intent of the PUT method in HTTP.

When I try to install the extension I get the following error: "This application is not supported on this computer. Installation has been disabled." I have a Thinkpad T420s running windows 8 with Chrome Version 25.0.1364.152 m, any idea what's not compatible?

If a browser supported PUTting the modified resource back up to the server, we'd be off to a good start. Server-side frameworks could then add functionality to split the modified resource back into the files that created it.

Love this idea, it would make source modification a piece of cake for every browser-maker to implement. To allow for compatibility, this feature could be activated only when a X-Source-Modification-Enabled (or something) header is present on the original page. The header's value could even be the (relative) endpoint to call!

The simplest middleware that would pop up would be a diff generator. But with source maps, web frameworks could track what exact source files were used.

My crazy idea is to just use git + some sort of source map style overlay on both ends to track changes and pass them back and forth.

What about pre-processors (SASS, Less) or templating engines (ERB, Haml, Slim)? That would seem to be a huge task to "un-pre-process" an asset. Going backwards is immensely difficult. These are not easily reversible processes.

Instead, why not make something like IntelliJ/RubyMine/WebStorm/etc.'s Live Edit plugin a native part of the browser. Allow the asset pipeline to tell the browser it has changes available, rather than try to have it regurgitate all the processed assets. That would be relatively easy to add and very straightforward to implement.

Your Live Edit idea is a good one, but I think the assumption about "un-pre-processing" would be part of the pre-processing development tools understanding what was being pushed to them, therefore, the need for an open standard as has been alluded to above.

I'd be happy even if this was limited to the local file system! I've already got build and deployment set up, and modifying the web servers seems like a hassle.

It seems to me, that with source maps in the browser, the browser should be able to PUT the original source file, with the correct file hierarchy. So, downloading assets.min.js, editing models/Foo.coffee, PUTting models/Foo.coffee.

That would be really something.

A lot of these ideas could be supported via a proxy system. Something like charles http://www.charlesproxy.com/ on steroids. If you wanted to edit yahoo.com , you would checkout your local repo, have charles point to the local repo, and then your on the fly css/js fixes would go to your local repo. Yahoo's server wouldn't have to support it.

A lot of people are asking for that. I guess sourcemap is (part of) what you're describing. We're working with Google on this, and we'll soon have builtin support at least for JavaScript (not HTML/CSS yet).

Something like this, but for all (standard) source files, not just JS.

http://remysharp.com/2012/12/21/my-workflow-never-having-to-...

Isn't that the wrong way around? Instead of pushing to the web server and let it figure out where to put the changes, change the local file (or file on the server, via NFS or such) and push the changes to the browser as well using tools such as swankjs [1] or, once it's ready, Kite [2] (that's my pet project).

For higher-level languages like Coffeescript or SASS, run a local compiler on the file or function so you can push the compiled code to the browser.

A nice side effect of this approach is that you can use a real code editor instead of the Notepad-style editor embedded in the browser.

In that regard, my #1 feature request for the Firefox devs is to finish and implement the remote debugging protocol [3] and, preferably, work with the WebKit devs towards unifying the two protocols.

[1] https://github.com/swank-js/swank-js

[2] https://github.com/jscheid/kite

[3] https://wiki.mozilla.org/Remote_Debugging_Protocol

(Disclaimer: I'm working on http://www.webflow.com to try to solve this exact problem.)

I've been thinking about this issue a lot over the last year, and it's really as hard as you state (and then some). We ended up having to create our own supersets of the DOM/CSSOM in order to keep track of individual elements/selectors as they are created/removed/changed. I would be very surprised (and pleased) if Mozilla was able to implement this in a way that works without lots of additional/manual inputs. If you think JS source maps are a hard problem to solve, I'd say this one is at least an order of magnitude harder.

I'm not sure I would say that JS source maps are a hard problem to solve.

Fair point. However, it has taken years to get to where we are today (CoffeeScript just shipping support, limited browser support), so it doesn't seem to be an easy problem either.

The delay in CoffeeScript support had to do with the design of the compiler more than anything. CoffeeScriptRedux [1] has had this in for quite some time.

[1] https://github.com/michaelficarra/CoffeeScriptRedux/

Indeed the ecosystem and support around source maps isn't super easy in total, but I wouldn't call any particular point in isolation particularly difficult. It's just that there is quite a few of them.

I tried to enter my email address to get notification of your launch. Nothing happened when I clicked the button (using IE 8)

Woah, oops - thanks for letting me know. Trying to stand up a VM right now so I can see what's going on.

Edit: Should be fixed now.

I'm having similar problem on firefox 19 on ubuntu 12.10 x86-64. After some seconds it says "Hmm, that email address doesn't look right...".

My thought is that this is really most useful for CSS and the transformations that SASS/LESS are capable of are relatively mundane in comparison to CS -> JS. In addition I only see this as a tool for development, not something that I would want running in production so you don't have the concerns over increased file size or still supporting minification that you do with source maps, assuming you want source maps in production for error reporting.

I can envision simply using structured CSS comments to pass the needed information to the browser. The browser only needs a structured pushing protocol, baseline comment format, probably handling of comments that indicate file boundaries (used for pushing to the correct resource) and a 'plugin api' to allow plugins to parse other comments in a meaningful way, SASS/LESS could provide a 'Dev tools' plugin to parse the comments and support whatever editing features they wanted. They would also have to support generation of the comments in the preprocessor.

The important bit is a standardized pushing protocol, a standardized way to provide additional mapping information and a standardized 'plugin' style system to allow things like SASS to add to dev tools additional editing support.

Just one theoretical approach, still a ton of work, but I really think there is a lot of developer time spent dealing with this issue so it may well be worth it.

+1. I can't even add an element directly in the Chrome dev tools - you can only edit an existing elements HTML and append something after it.

My kingdom for a '+' button.

You can, sort of.

Right click on an element and choose "edit as HTML" and you can add whatever you want, granted it offers no reasonable formatting, its just a wall of text, not even tabs / line breaks.

It is also broken in that when you do this Chrome rebuilds all the sub elements of what your editing so if there were event hooks or anything like that on the elements they will be gone.

Not to mention dragging over text to select it usually results in the entire HTML fragment getting destroyed when Chrome decides that you're actually attempting to drag the text to move it somewhere else.

My workaround is to click an element, then type into console

    $0.appendChild(document.createElement('tagName'))

but yeah, a [+] button would be nice…

It really seems like you didn't read my post before you replied to it.

> It is also broken in that when you do this Chrome rebuilds all the sub elements of what your editing so if there were event hooks or anything like that on the elements they will be gone.

This may not be completely true. In Edit As HTML mode every effort is made to retain the original elements. If you move some tags to another location, the real element (and handlers) should actually be retained.

If you're using Chrome, try out: http://tin.cr/ It seems to be at least very similar to what you're looking for!

Not perfect but what I did last time I played with backbone:

* As I used sass, coffeescript and haml, I used guard (https://github.com/guard/guard) to watch the source files and automatically compile them

* Used serve (https://npmjs.org/package/serve) to serve the directory over http, could use python -m SimpleHTTPServer too

* Used live.js to pull for changes (http://livejs.com/)

As I said it's not perfect though, while CSS changes get applied transparently, changes in javascript will reload the page (you can also watch only for CSS changes). Still for working on CSS, especially together with LESS or SASS it's quite pleasant. Also it spams your Firebug console pretty bad.

I wrote a post about a year ago, to open up a discussion about what browser vendors can do to encourage rapid prototyping designing in the browser, by giving them tools for visual design that they would opt to use over software like Photoshop/Fireworks.

I'd love to see more tools that enable rapid prototyping, including the ability to craft CSS in a more visual manner.

Here's the post, for any who are interested:

http://blog.colin-gourlay.com/blog/2012/03/how-can-browser-b...

Yeah, I think it would really set Firefox above everyone else is if it had its own web IDE (live WYSIWYG and code editing) built right in. It'd have to be a good one and you shouldn't try to force people to use it who don't want to. But I agree with other folks here: We all would kind of like the option to use something like that right in the browser.

aaaaaaand then we'd be back to SeaMonkey.

Not that there's anything wrong with that.

It's not always possible to push changes back to LESS or SASS due to ambiguity at which level changes should be applied - if you're editing CSS values. The browser would have to display SASS or LESS in the inspector for what you're suggesting to work.

Chrome Canary (perhaps, the Dev channel, too) supports navigation to CSS selectors, property names and values (Ctrl-click them) in the corresponding Sass resources (the Sources panel). You can edit Sass and save it to disk (right-click the editor, "Save as...").

Now, if you have the "Support for Sass" experiment enabled, you'll see the "Auto-reload CSS upon Sass save" timeout setting to reload re-generated CSS files after "sass --watch in:out --sourcemap" (or equivalent) has updated them on the local disk.

+1. I know it's not the main line of discussion here but I wonder how can this feature be leveraged for CSS preprocessors like Less/SASS where CSS reaching the browser is never edited directly.

Edit: Gramer and language improvement.

Just being able to hold down a modifier key to move an element up down left and right would be great. You can do this in one dimension at a time at present but to be able to exactly place something would be a tremendous time saver.

>You can do this in one dimension at a time at present //

In FF dev tools?

If you could somehow get sourcemaps for haml/sass/whatever it would make debugging css/html in the browser so much easier when working with serverside templates.