4 ms·

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

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.

palish 15y ago
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.)
- dolinsky 15y ago
  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.
  - dsmithn 15y ago
    "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.
dsmithn 15y ago
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.
- dolinsky 15y ago
  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?
  - tghw 15y ago
    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.
  - dsmithn 15y ago
    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.
patio11 15y ago
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.
- AndrewHampton 15y ago
  I'm curious if you used this already since you've been working w/ Fog Creek or if this is the first you're seeing it too.
  - patio11 15y ago
    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.
    - AndrewHampton 15y ago
      OK, thanks
- dolinsky 15y ago
  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.
- iamwil 15y ago
tghw 15y ago
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.
- dolinsky 15y ago
  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.
  - tghw 15y ago
    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.
custominstall 15y ago
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.
- tghw 15y ago
  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.
  - custominstall 15y ago
    Thanks great to hear from a company representative directly. Looking forward to giving this a try.

palish 15y ago

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.)

dolinsky 15y ago
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.
- dsmithn 15y ago
  "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.

dsmithn 15y ago

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.

dolinsky 15y ago
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?
- tghw 15y ago
  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.
- dsmithn 15y ago
  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.

patio11 15y ago

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.

AndrewHampton 15y ago
I'm curious if you used this already since you've been working w/ Fog Creek or if this is the first you're seeing it too.
- patio11 15y ago
  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.
  - AndrewHampton 15y ago
    OK, thanks
dolinsky 15y ago
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.
iamwil 15y ago

tghw 15y ago

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.

dolinsky 15y ago
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.
- tghw 15y ago
  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.

custominstall 15y ago

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.

tghw 15y ago
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.
- custominstall 15y ago
  Thanks great to hear from a company representative directly. Looking forward to giving this a try.