11 ms·

I wrote something similar, called Slinky [0], which also transparently compiles various compiled web langauges (SASS, HAML, CoffeeScript, TypeScript, etc.). Th

by necubi 11y ago

I wrote something similar, called Slinky [0], which also transparently compiles various compiled web langauges (SASS, HAML, CoffeeScript, TypeScript, etc.). The issue with these systems is that they lie in between something like Python's SimpleHTTPServer and a complete frontend development tool like Grunt or Gulp. They're great for small projects, but have trouble scaling up. [0] https://github.com/mwylde/slinky https://github.com/mwylde/slinky

cortesi 11y ago
Slinky looks very neat! I do feel it inhabits a very different niche from devd, though. I have no ambitions for devd to compete with tools like Grunt, Gulp or Slinky. Devd has a simple job: it just serves files and triggers livereload when files change, and is completely agnostic about the build process. That means it works very well as a complement to Gulp - in fact, this is one of my primary use cases for devd. My gulp setups are simpler now: I've ditched Connect and node livereload libraries, and instead gulp JUST renders files to disk. It's early days, but having two sharp tools each doing what they do best seems to work well. I should add that I definitely don't think there's one "right way" to do this stuff. I love the fact that we're free to explore variations to see what works and what doesn't. The more things we try the merrier!
- gknoy 11y ago
  This reply, and your perspectives on sharp tools, really make me smile. I'm definitely going to go use your tool, now. :)
- alessioalex 11y ago
  It looks nice. I did a similar thing with a project of mine: https://github.com/alessioalex/reloadify https://github.com/alessioalex/reloadify It serves files and does livereload as well. Can be used programatically or as a CLI: `reloadify -f static -p 8080`.
- mcrider 11y ago
  Do you have an example gulpfile that uses devd? I've had a lot of trouble getting connect + nodemon to work well together and would love a better solution.
  - cortesi 11y ago
    Devd doesn't appear in my gulpfiles at all, actually. Gulp literally just renders to disk. I then start devd separately with the appropriate livereload flags to handle the service end of things. For instance, here's a devd command-line from the docs (https://github.com/cortesi/devd https://github.com/cortesi/devd) that handles proxying local services, with a static directory overlaid. Gulp would be rendering assets into that static directory, the change would be noticed by devd, and liverload would be triggered. devd -l \ -w ./src/ \ /=http://localhost:8888 \ /api/=http://localhost:8889 \ /static/=./assets
- amelius 11y ago
  While livereload is a very cool feature, I doubt that it brings a lot to the table in terms of functionality and user-friendliness. After all, web-users are accustomed to reloading a page when they want fresh results. What scenario do you have in mind where the use of livereload warrants the complications in the protocol?
  - timblair 11y ago
    I think you're confusing the who the "user" is in this case. It's not Joe Bloggs out on the internet who wants to see fresh content on your site; it's you, the web developer, working on your local machine, building a web site or application. The live-reload functionality is there as a development workflow tool, to automatically reload the page to see the results of the latest code change, rather than manually switching to the browser and hitting ⌘R/F5.
reitoei 11y ago
> They're great for small projects, but have trouble scaling up. I'm pretty sure it's intended for quickly spinning up small projects, not fully-fleshed front end systems with package management, build tools etc. I use node-static myself for quickly bootstrapping experimental front end projects With devd, I like how you can quickly map a proxy and get live reloading out of the box. Tidy.

by necubi 11y ago

cortesi 11y ago

Slinky looks very neat! I do feel it inhabits a very different niche from devd, though. I have no ambitions for devd to compete with tools like Grunt, Gulp or Slinky. Devd has a simple job: it just serves files and triggers livereload when files change, and is completely agnostic about the build process. That means it works very well as a complement to Gulp - in fact, this is one of my primary use cases for devd. My gulp setups are simpler now: I've ditched Connect and node livereload libraries, and instead gulp JUST renders files to disk. It's early days, but having two sharp tools each doing what they do best seems to work well. I should add that I definitely don't think there's one "right way" to do this stuff. I love the fact that we're free to explore variations to see what works and what doesn't. The more things we try the merrier!

gknoy 11y ago
This reply, and your perspectives on sharp tools, really make me smile. I'm definitely going to go use your tool, now. :)
alessioalex 11y ago
It looks nice. I did a similar thing with a project of mine: https://github.com/alessioalex/reloadify https://github.com/alessioalex/reloadify It serves files and does livereload as well. Can be used programatically or as a CLI: `reloadify -f static -p 8080`.
mcrider 11y ago
Do you have an example gulpfile that uses devd? I've had a lot of trouble getting connect + nodemon to work well together and would love a better solution.
- cortesi 11y ago
  Devd doesn't appear in my gulpfiles at all, actually. Gulp literally just renders to disk. I then start devd separately with the appropriate livereload flags to handle the service end of things. For instance, here's a devd command-line from the docs (https://github.com/cortesi/devd https://github.com/cortesi/devd) that handles proxying local services, with a static directory overlaid. Gulp would be rendering assets into that static directory, the change would be noticed by devd, and liverload would be triggered. devd -l \ -w ./src/ \ /=http://localhost:8888 \ /api/=http://localhost:8889 \ /static/=./assets
amelius 11y ago
While livereload is a very cool feature, I doubt that it brings a lot to the table in terms of functionality and user-friendliness. After all, web-users are accustomed to reloading a page when they want fresh results. What scenario do you have in mind where the use of livereload warrants the complications in the protocol?
- timblair 11y ago
  I think you're confusing the who the "user" is in this case. It's not Joe Bloggs out on the internet who wants to see fresh content on your site; it's you, the web developer, working on your local machine, building a web site or application. The live-reload functionality is there as a development workflow tool, to automatically reload the page to see the results of the latest code change, rather than manually switching to the browser and hitting ⌘R/F5.

reitoei 11y ago

> They're great for small projects, but have trouble scaling up. I'm pretty sure it's intended for quickly spinning up small projects, not fully-fleshed front end systems with package management, build tools etc. I use node-static myself for quickly bootstrapping experimental front end projects With devd, I like how you can quickly map a proxy and get live reloading out of the box. Tidy.