OK, I guess I'll be the wet blanket that goes thud here, but I really don't see this being very useful. In fact, I see it encouraging bad practices. Maybe it's because I'm approaching this from the standpoint of a company that has more than a few users coming to the site, probably (hopefully?) has an existing release process in place and has multiple stages of their environment to go through (sandbox/dev/qa/staging/live). If this is how you slap lipstick on your pigsite, then you're probably building a site that very few people go to and you don't even have a local version of your site to test against first (because if you had a sandbox environment this tool is pretty much moot), in which case I can see the usefulness of this tool.
Not sure how I feel about the inclusion of the link/script tags in order to make this work but it all seems geared to someone who maybe has their own blog or very low-trafficked site and this would be their alternative to editing the files on the live server.
From my understanding, the point of the project is to allow developers to edit css and see the results realtime, without having to save, switch windows from their CSS editor to their web browser and refresh the window. Or without having to edit the css in realtime by using Firebug, then edit those changes back into your actual file.
They also give you the option of hosting your CSS file on their servers, which is why you'd need the link to that CSS file.
It's all explained on their website which you might not have read/understood, or maybe I am missing something.
As a web developer working on quite a few projects, this tool seems great, although I can't have them hosting CSS for internal projects.
I did read through the site, and though I did not download the tool and try it out yet, the site seems to be catering to an individual who is used to SSHing in to / FTPing up to a site and hitting refresh (I did this when I was first learning about the web way back when as well, and I can appreciate the productivity gain here).
The hosting of your CSS files on their servers is also not suited for a development environment that has more than 1 environment, as I would not want to be editing files that are on a live server on a regular basis without first making those changes locally (and possibly checking them into an SCM of some sort first) because my css would quickly become out of sync across environments.
May I ask, the projects that you work on, do you have more than 1 environment that you use and do you collaborate with any other developers on these projects?
They specifically say there are two annoying issues this solves:
1. having to"CTRL-S–ALT-TAB–CTRL-SHIFT-R–JOY!", and
2. editing in Firebug "then trying to extract those tweaks back out of Firebug and into your website’s CSS files".
As far as working on teams, they're "thinking about how to expose your CSS in a versioned way so that you can keep it in Mercurial (with Kiln!), or Git, or whatever other version control software you might be using". Perhaps you're right, it's better to wait until that is implemented if you have that kind of setup.
EDIT: I've started testing it, and you can add other admins and editor users for sites, very nice.
If you try it out, you'll see that there are two modes, Preview and Published. Your changes don't go to anyone else until you are done with them, so we won't serve up half-baked CSS while you're still working on it. Once you're done, you hit Publish and only then is it live.
Seems like a Web Putty browser plugin would help preserve the "local transparent editing a la Firebug" use case. Transparent meaning, no edits to your existing HTML required to demo different CSS stylings. Or am I misunderstanding this?
So, these days this style of thing is not uncommon. For example, much of the Rails community uses Sass, a language which compiles to CSS. In development mode, it gets compiled anew on every page load. This doesn't happen in production: there are a few ways to make it happen, but basically, in production it looks like auto generated CSS sitting on the hard drive waiting to be served up quickly.
Doing the same thing with WebPutty would take maybe a dozen lines of code. I'm assuming anyone with multiple environments can make it happen in their language/framework of choice.
I can definitely appreciate the usefulness of realtime here, 'n having led teams in the past I'm all for using tools like Sass/less/blueprint/etc that expedite development time and empower the team. I guess it's the 'Publish' part of this tool that is really irking me, as any environment I've either designed or been a part of has always had a process for sending files to live, and it never included editing and saving files already in a live environment without some intermediary testing platform first.
The problem is you can't use webputty locally, it needs to access the page in order to use it. so anything you're working on needs to be live on the internet
I haven't used it. I will never answer questions about what knowledge I have/had regarding clients' upcoming product releases. You don't have to be Steve Jobs to get touchy about that one, and it's specifically enumerated in most NDAs I sign.
Yeah, we're still working on a way to make this work better for the sort of ongoing web development that most HN readers probably spend a good amount of time doing, but we do think it is very useful for smaller sites that don't need parallel deployment of markup and style changes.
We're also releasing this very early, for a Fog Creek project, to see what people think. It might be that this becomes a desktop tool using something like Titanium, or we might try to integrated version control into it as an alternative to publishing. As such, we're open to suggestions and feedback.
First, congrats on the product as I don't want to come off as being a bowl of sour grapes when that's not the case. I totally dig the concept of immediate results for changes made. Like I said in my OP, I'm approaching this from the viewpoint of a team of more than 1 where there are multiple environments to account for so that's my starting point. For a very small team / personal site built using Rails that has no development environment I can definitely see the usefulness of this product.
Thanks! Your point was one we expected to hear, especially here on HN.
We actually did look into getting Mercurial (which is what we use internally and what we provide via Kiln) up and running in AppEngine, which has been done before, but was just beyond the scope of the first phase of the project.
And I agree, I don't think we'd ever host FogBugz's or Kiln's CSS with it on AppEngine, but I do really want to be able to use the editor and SCSS with those projects, so we'll be keeping an eye towards making that more natural.
I partly agree. For example: I don't see any code revisions been maintained for the changes which for any big development firm will be annoying.
I think there is a lot of changes that can be done to make this a better solution. But as it stands if being used by a small company I can see some merits.
However, I would be cautious about putting something in a beta stage on any site with enough value.
We actually do maintain a history of all of the published versions and the current preview version, but we haven't exposed them yet, since it makes the interface more complex, but it is something on our radar.
You should edit your post to include reasons why WebPutty is "a bad thing". (I have no idea; I'm a gamedev guy, but I find webdev very interesting. It's hard to know what to avoid and what to embrace when you're new.)
I'd be happy to include an edw519-style bulleted list of why webputty is 'a bad thing', but I guess it depends upon who their target audience is for this product. If they're targeting someone who is used to ssh'ing into their account on their shared hosting company and editing their css 'live', then yes, I think this product provides a benefit to that user.
Any site I've ever worked on I've always had atleast 2 environments, a local environment and a live environment. Any company I've ever been a part of has had at least 3 environments (sandbox/qa/live) and it's very common to have a dev and staging environment on top of those as well. The reason you have a minimum of 2 environments is so that you can do all of your testing without breaking the live environment, which is what this tool seems to ignore.
"Of course, we also let you play with a preview version of your website’s CSS without inflicting any half-baked designs upon your website’s visitors. That’s the version you edit in the WebPutty editor."
"You can always export a pretty-printed version of your website’s CSS at any time (both the preview and published versions)."
See my other post, I believe you have not understood their product very well.
This looks nifty and all, and I agree that their two "options" (edit -> browser -> reload vs. Firebug cut-n-paste) are indeed two options that many people consider, but they seem to have left out two other options that solve this problem quite elegantly, at least for Mac users:
1) Coda has real-time CSS editing built-in, and you can relatively easily fire up multiple windows to edit in a "real" editor (if you consider Coda a real editor) and view changes in real-time as you type
2) CSSEdit does one better -- you can edit using their editor and see changes in key-by-key realtime in their preview window. OR, and this is how I've settled on working, you can edit files using the editor of your choice (MacVIM, for example) and still see changes instantly upon save in their preview. So it reduced the need to reload the browser (saving half the steps). Now it's just a matter of make changes, Cmd-S (or however you save in your editor of choice) and it's all updated in real-time.
Yeah, we know there are tools out there that do similar things (Backfire, live.js, etc.) but we do think the hosting will appeal to some people (with gzip and etags set up properly) and SCSS/Compass, which make working on CSS much nicer, is a huge selling point, personally.
Fun stuff. I'd be tempted to either a) run a deployment step to freeze CSS locally or b) do some nginx reverse proxy magic to grab the latest CSS and cache it for a long time (I.e. only grabbing it from GAE once per revision).
That's a fairly consequential thingee to have on a server with availability independent of one's own.
If folks want I'll OSS code for this, although at a dozen lines in Rails it is barely worth typing git clone...
How would I make sure my off-domain images, that are referenced in css, are linked with http when the connection is non-ssl, and https, when the connection is ssl? Currently I make the server link to two separately cached css files (depending on secure or not), which are themselves dynamically generated with an ssl flag.
Instead of specifying http://example.com/foo.png or https://example.com/foo.png, you can just use //example.com/foo.png. AFAIK the only downside to that is older versions of IE (6 & 7 I think) will download the image twice for some reason.
The "scientific progress goes boink?" line is from the duplicator story (which I can't find). The duplicator is the cardboard box on its side, which is obviously completely different from the transmogrifier. And if you turn the opening to the top, it's a spaceship!
Minor quibble: the box with the opening on top is a time machine. I don't remember any space-shipping happening with the use of props, it seemed to be all internally imagined.
I personally prefer a different approach. I open both the browser and my favourite editor on the same desktop. I edit my HTML/CSS stuff and as soon as I hit "save", it is shown immediately in the browser. All you need to do is:
1. Add a <meta> refresh tag to refresh the page once per second. Alternatively, with one line of JavaScript you can refresh even more frequently, e.g. immediately after "on load".
2. Bonus: Use a tiling window manager such as WMII, which automatically adjust the size of your editor window if you resize your browser window, and vice versa. That way, you get some kind of "split mode" and don't have to struggle with resizing multiple overlapping windows.
In summary, using auto-refresh + tiling window manager resulted a big increase in comfort for me. Not only during CSS development.
A bit off-topic, but related: If your target runs in the command line, the Unix command "watch" is a perfect auto-reloader:
watch --interval=0 your-app
For instance, debugging some PHP code by auto-rerunning the test suite might look like this:
watch --interval=0 php run-tests.php
This gives you immediate feedback after hitting "Save" in your editor, without even having to struggle with your browser.
This is EXACTLY what I needed and wanted. I was literally about to code my own version of this today but decided to procrastinate and check hacker news, and I'm sure glad I did!
Not to rain on WebPutty's parade (I think it's a great app, and it looks sweet), but I think the problem has been solved much more elegantly a long time ago by CSSEdit: [1]
I don't know. The SASS stuff seems awesome. Though, Firebug can handle a lot of stuff that it's making out it can't.
For example, the article says that you have to do a lot of tweakage with the element inspector. This isn't 100% the case and I think that paints Firebug in a less than positive light. The element inspector is a really useful tool but you're just not restricted to that.
There's a CSS tab next to the HTML tab. This presents the full stylesheets to you pretty printed, editable like you would an inspected element. I can often author a lot of CSS in this window in:
a) A much shorter space of time.
b) Less amounts than I usually would.
Why point a? When you can see the CSS changing in real-time, you don't have to constantly refresh. Yes, there are ways to reload CSS and I use them often but it's not quite live like Firebug is. The second point is pretty much for the same reason: since you're making the changes in real time you can see exactly what changes what. This makes it less likely to over-step, in which you could be writing redundant CSS.
Firebug has it's downsides, such as it's clunky way of editing with pretty printing. There's also how it assumes the formatting of your CSS. You can use it in a similar way to an editor too but this removes pretty printing. Another big thing is the ability to lose work on refresh if you're not careful.
I can indeed live with the above. I don't think there are many instances where I would like to add in extra assets. I am quite a forgetful person.
Either way, the issues with Firebug can be patched over and I'm certain can be fixed. I don't think linking additional JS and CSS can easily be rectified with this.
What could be missed is the publish feature but not exactly ideal in a fair few number of situations.
This is from somebody who has to work on a lot of static websites and restrictions insist on pure CSS and HTML.
Don't get us wrong, we love Firebug, but it is kind of a pain to then take the changes you made, copy them out, paste them somewhere else, and then deploy it. Backfire makes that easier, which is good, but you still don't have SASS and Compass, which I find makes working with CSS much nicer.
In a static environment, you can just compile the SASS to CSS before you deploy, or you can use WebPutty and have us host it for you.
WebPutty is really cool, by the way. I'm currently having a play with it and it's funny but I have some suggestions:
A firebug inspired element inspector may be a good thing. I think jumping straight to the line of CSS rather than the separate, filtered window would be a great idea. I'd really love that.
Another thing, but less important, would be auto-complete. Either that or ways to expand ZenCSS abbreviations. This would push my productivity to the moon.
Another thing I was thinking of hacking on to Firebug (when I find out how) is selector hinting. The way this would work is, when you type a selector, the available ones are given to you, much like method hints in IDEs. This would be very useful to me at least. There have been many times when I've needed to know a particular hierarchy/id name/class name and found myself having to reference elsewhere.
To host CSS would be a social/pointy-haired-boss issue but I could make necessary recommendations. In any sense, I love the work that has been done.
Thanks for the shootout. I'm actually the author of LiveReload, and I was just frightened to death upon seeing this news. But gosh, I guess I shouldn't worry too much upon closer inspection.
I'm surprised at how many people don't know about a feature they probably already have, found in the Web Developer plugin for Firefox. The Edit CSS lets you see your changes live as you type. I use it all the time.
If you push in the "Stick" button, changes are not lost if you refresh. It does also have a save button, but yes, you still need to upload the change. (Even though I tend to copy/paste instead of using this.)
But, this is---for me---a one time thing, after I've made all the changes I want and things look great. It makes the CTRL-S, Alt-Tab, Reload procedure that was originally described only need to happen once, instead of lots of times in rapid succession.
This is actually the only thing I keep the webdev tools addon around for now, everything else I used to use it for is either in firebug or I've found other implementations for (eg W3C checks I use unicorn first which I have a saved search "key" for).
It seems like the market for html/css tools is so vast, it doesn't seem hard to build yet another tool that can end up being profitable. I've been working on a grid-based rapid html prototyping tool
http://pageblox.com
and I was looking to incorporate live css editing similar to this into it. Of course Fog Creek put a twist on it I never would have considered (editing/modifying css of an already live site). I'm very curious to see how (and learn from) how this will evolve as I assume this is their feedback/iteration phase.
Wow I honestly thought I was the only one stuck in the save -> alt tab -> upload -> refresh loop. I didn't know this was how some people were doing it. Great tool, trying it out right now
I've a framebreaker on my blog which means I can't use this without disabling that first. Not saying this is a huge problem just something that might not have been thought of. I guess the user would spot it pretty quickly.
Slightly off-topic, why is there a 350k image file that's dynamically resized (smaller) and only there for decoration. Slowed page load considerably for me (I'm having problems with my connection mind you). Pretty but way off optimal IMO.
I tested it and it works fairly well. Although, it is not exactly real time for me, there is a 5-second delay (could be my DSL connection) before the page updates.
It would be even more useful to use it with localhost, however, since I develop on my local computer and then upload the finished code to the server.
It's far simpler in that it just reloads your CSS continually. We use it all the time at Ooyala to put our favorite text editor and a web browser side-by-side and hack away.
Couldn't the same effect be achieved through a bookmarklet that reloads the CSS for the page every 1/5/30 seconds? That would let you continue to use your preferred editor and browser, and the cost of reloading local CSS is slim to none.
Yes and no. Live.js will do that sort of reloading for you, but it won't host it for you. You'd also have to set up on the fly SCSS=>CSS compilation. Neither of those are hard, but the idea is that you don't have to do any of that sort of annoying work.
To be fair, nor is this. We use CodeMirror (http://codemirror.net), which at least gives you line numbers, syntax highlighting, braces matching, and (coming soon) autocomplete. Sure, it's no [vim|emacs|Visual Studio|Eclipse|nano], but it is better than just "a text field on a web page".
SCSS and Compass support is important to me. I avoid plain CSS whenever possible, and CSSEdit is pretty useless (certainly not worth paying for) without SCSS support.
Doesn't seem to work as advertised in Chrome (dev channel).
Not bad, but I was never able to really get into CSSEdit, which is sort of what I imagine it to be similar to. A lot of missing editor features - or maybe it just not being vim.
My biggest gripe here is that I have to trust someone else to host my CSS. I just can't do that.
I guess I was hoping for a better CssEdit and it wasn't.
I may just be slow, but I didn't see a way to actually start editing without embedding their link tag on my site. I imagine that'd be hard to do what they want without a bit of hackery to get around cross domain issues, but for casual poking around, it was more than I wanted to do.
If you want to host it yourself, you can use WebPutty to edit it, and then use the export link (page with a green arrow coming out of it) to get out the compiled CSS.
Yeah, at this point we're not doing HTML because that would mean we would be hosting your whole site. Fortunately, with CSS3, there are fewer extra elements you have to add for stylistic reasons, so it's getting to be less of a problem.
Not sure how I feel about the inclusion of the link/script tags in order to make this work but it all seems geared to someone who maybe has their own blog or very low-trafficked site and this would be their alternative to editing the files on the live server.