An error occurred in the application and your page could not be served. Please try again in a few moments.
If you are the application owner, check your logs for details.
We originally went down the awesomebox path, but as soon as we started dealing with server side code it caused issues. We run on your production/staging environment meaning you get your app running in the wild.
It's different from a widget in that Awesomebox gives you infinite staging environments - if you push 10 different ideas, and then invite a few people, they can easily switch between different versions without you having to manage multiple servers. In our experience, this is really important when working through new ideas or designs with clients or managers.
Does that help answer your question? Happy to explain more if not.
Really, really appreciate the feedback!
What more could you do if you didn't need to deploy your entire stack with each little change you make? If you could only deploy your frontend (in different versions simultaneously) pointing to a backend that's always up, it enables much faster iteration: testing, bugfixing, demoing things that otherwise you might not deploy different versions for because it's too painful.
For example, you could A/B test meaningful portions of frontend code in a more scalable way than, say, Optimizely. Or you might point a user that's having problems to a specific build (which you can deploy instantly) and see if it fixes their problem _on their live account_. Or you can hack together a new feature that works _on a live account_ for a presentation, and push it without worrying about mucking up or interrupting production traffic. Or turn off minification instantly and deploy that.
Plus, you don't have to worry about refining internal frontend build scripts, it's plug and play.
My inspiration for the feature was that feeling I always got that I needed to walk over to someone's desk and show them what I'm working on on my Macbook or paper and talk through it. Sometimes you can't do that if the team is remote or a client needs to check something out, so you need an approximation of that experience. Making a product around the feature is a great idea.
I'm curious - what's the name of the product you're building?
Also Windows/FF gets an invalid font character for the "v" arrow on the grey tab. Works ok in Chrome/IE
More once inside the app: http://i.imgur.com/WFaLbjw.jpg
As far as pricing, we're not sure yet, but we want to make it as free and accessible to developers and designers as we can, and charge companies, not people - kind of like how Github is free for open-source projects.
at module.exports (C:\[snip]\npm\node_modules\awesomebox\node_modules\awesomebox-core\__trojan__\horse.js:15:10)
Could not possibly uninstall fast enough. Running antivirus ASAP
Check out trojan here: https://github.com/mattinsler/trojan
This helps with managing download times for all the transpiling code that we use for things like coffeescript and less and ejs.
At the time I wrote this module I thought it'd be funny to name one of the files horse to continue the joke. Definitely time to change that filename. =-)
I'd be happy to walk you through how all the code works if you're interested.
1. Your "trojan horse" name for that packager - has two connotations for me, neither of them good. Why not just call it what it is.
2. Your product name. I really couldn't recommend your product to anyone doing serious work for my company or my clients. The whole "awesome" and "ninja" vocabulary thing is grating, is done to death, I am sick of hearing it. My advice is to pick a better name if you want to attract anything more than tyre kickers.
Pretty sure you put a lot of time an effort into this, don't blow it with stuff like this.
The CLI client is here: https://github.com/awesomebox/awesomebox
The rendering core is here: https://github.com/awesomebox/awesomebox-core
Also, lots of the modules used in both the CLI and backend of the product are available here: https://github.com/mattinsler?tab=repositories