Hacker News new | ask | show | jobs
Bowery – The Next Generation of Web Development (bowery.io)
40 points by sjkaliski 4665 days ago
17 comments

I am impressed by how much time I've spent on the site (and still don't understand exactly what it does or why it's worth $40/user/mo.) I am also impressed by how the future of web development is a node.js package.

To the creators: you are clearly capable of creating slick marketing (the site looks great!), I'd advise spending some time working on your value proposition. The "Just code / Just branch / Just works" trifecta is pithy, but it doesn't exactly explain what Bowery offers. (Also, having your learn more CTA redirect to the docs -- which start out with how to install Bowery -- is not ideal.)

(Also, as an FYI: the link to 'Philosophy' in the docs is broken.)

I came here to say something similar. If the best pitch of your value proposition is "The Next Generation of Web Development", you're not going to get far with developers. Developers want to know specifically how you're going to help them. I'd argue that the byline is a better core pitch: "Build products, not infrastructure". From that, I can at least get an idea of where I'm headed. Leading with "next generation" really puts me off.
I have a short attention span for sites and after clicking around for approximately 30 seconds I have no clue what is going on. It seems to be an expanded team environment PaaS?

If I didn't click on this from hacker news, I would have bounced immediately.

The other thing is if I can't understand their marketing website, I have little faith that I would understand the product if using it.

I wish everyone creating products for developers would listen to this advice. There are so many developer products these days (including some successful ones) that leave me absolutely baffled even after a few minutes on their website. I am left with a vague sense of impressive-sounding features that probably apply to someone, but have no concrete idea what they are for or if they apply to me.
I think the cool part is that that you could do all of this stuff and not have to worry about any of the infrastructure.

The node package only works inside of the hosting environment. You're paying that much money for everything to be hosted. It says in the docs that there's no local development environment.

You will always have to worry about the infrastructure. This might be a view of hosted development's future, but every abstraction will leak. When the day the your app gets more sign ups in an hour than you have in your userbase, you'd better understand your env as deeply as possible.
Unlike most development environments, Bowery requires an internet connection.

And I'm out.

So, this seems like a sort of Google App Engine, but running on Node? BoweryDB and the Cache sound just like what App Engine provides - except that the App Engine also runs on my local dev box.

The problem with this (and the App Engine) is that it's totally locked in. Your database is proprietary, your middleware is proprietary... at least App Engine is backed by Google. What happens when you guys go bust? There's no way I can use a platform like this without knowing I have an open fallback out there somewhere.

AppEngine's lockin is significantly overstated. AppScale exists and works well.
Do you know of any sites/services that are using AppScale in production and what their volume is? (I googled for "powered by" and found nothing)
Last I heard Udacity is powered by App Engine. There was an interview about it with the CEO at the end of the Web Development course, and he seemed pretty pleased with it.
My take: Bowery is basically Google App Engine for Node.js.

Of course, they put their own spin on things. The whole 'bowery connect' thing is unusual - they say that your "dev environment is online" but I'm not sure what they mean. It appears that what 'bowery connect' does is initialize a git repository and starts sync'ing filesystem changes to a remote host. In other words, rather than GAE's more traditional "deploy" command, bowery is constantly deploying.

The benefit of doing deploy in this way is clear: it's much easier on the user (nothing to install apart from an editor), and it's much easier on the bowery people because they don't have to provide a local analogue to the hosted environment. The dev environment is the hosted environment. This is possible because, presumably, the hosted environment serves branch URLs extremely cheaply.

No doubt the kernel of this project has it's origin in a late night conversation that started, "What if HTTP endpoints were as cheap as git branches? What if you had an active endpoint for every branch?"

"What if HTTP endpoints were as cheap as git branches? What if you had an active endpoint for every branch?"

I really like that

Another group in my office has been doing this for a long time, except with hg. They have it set up so that whenever you push a branch to dev, there is a [branchname].dev.[propertyname].org. You push to the master branch on the production machine, and then that is what is running the production site.
I mean, I get the idea behind these platforms without building your own platform services. However, if you actually plan on growing as a company it would seem to me these services have very specific walls in terms of functionality. I've never worked to the company reported that didn't wind up leaning on things like complex SQL queries and other abstractions that these people are telling us we don't need.

I can see how this would work for a limited set of apps that only have simple API needs. Given that, it's perplexing that they would make such ridiculous claims and it's hard to take them seriously. When you just want to run a simple report using a SQL closet and have to tables and uses a fancy GROUP BY, you will be left out in the cold and have to run a gigantic batch job in whatever programming language you use to figure this out. I am not impressed.

> Our Philosophy: Web development is terrible.

Go fuck yourself, Bowery.

But web development is terrible. There are so many approaches, languages, frameworks, and philosophies - its incredibly hard for newbies to enter the field.

Educational systems have evolved a solution for this kind of thing: you isolate newbies from conflict. You essentially lie to them, you simplify the situation, and tell them "do this". They do it, and now they know something. Now they have a bit of skin in the game, they have a data point to participate in future academic conflict.

But with modern web dev, the conflict is up-front-and-center, and newbies are not isolated from it.

Bowery, GAE, and meteor address these issues in a very similar way: they make reasonable up-front decisions about how an app should be structured. You can deviate, but the defaults are not bad.

These decisions are a real pain point for a lot of people, and I think that's what they meant with that statement. I would also add: be careful defending complexity. It is very easy for a professional who's built a career navigating complexity to descry reductions to that complexity, as it will directly affect her ability to make money.

Though it didn't need the expletive, I totally agree with the sentiment. This 'Philosophy' is offensive to all of your would-be early adopters. Like I work on building web stuff all day and kind of enjoy it. The people contributing to all of the open source projects on github probably kind of enjoy it. Have a little respect.

If you're going to write a mission statement, don't start it with "X sucks". That's not a mission and it's certainly not a philosophy.

+1 Not a friendly developer message at all. This point of view reeks of arrogance.
> BoweryDB is more of a data management application then a database. It analyzes access paterns to cache frequently-used data, and knows when you make updates in your code to make sure the cache is never stale. All that matters from the developers' point of view is the code they use to interact with it.

This paragraph is funny. They call it something other than a database, then describe what a DBMS does.

I also find strange version control is bolted in the platform, you could have just provided hooks so you can deploy from branch X or tag Y.

The idea is good though, I can see the value proposition.

There's a lot that goes on behind the scenes. Think about DynamoDB vs Riak.
It seems like this would yield a really enjoyable workflow. The pricing model (http://bowery.io/pricing/) makes it difficult for me to transfer into an actual monthly price. Seems like that could be remedied with a few scenarios.

Also, one of the things I love about heroku is the free starting point. It really lets me play with an idea without committing to hardly anything. Is there a similar free starting place with bowery?

Hey thanks for checking it out. We're working on a few ways to make the pricing easier to digest.

We've been discussing a free starting point, but haven't solidified anything just yet.

Right now we're bootstrapped. There's only three of us, so the focus so far has been on getting the product in a useable and workable state.

I think without a free starting point of some kind, this is going to be a tough sell. Perhaps a week free or something like that would enable someone to see if they like it enough to start paying for it.
"$1 per KB read per second. $2 per KB written per second."

I'm out. Completely killed any interest right here. This pricing is just ludicrous.

Sorry, that's a typo. It's supposed to be in cents and not dollars.
Hah! Ok, I'll take a look again.
I had a cursory glance, and this has nothing to do with Twitter's Bower[1], a package manager for web libraries (hell, even the TLD is the same). Bowery is a misleading name, and it gives the impression they are somehow related.

[1] http://bower.io/

Interestingly, 'bowery' is Glaswegian slang for 'come on, then!' or 'bring it!' - indicating aggression [1].

[1] http://www.urbandictionary.com/define.php?term=bowery

Here's some others to pick from, my money would be on something to to with New York [1], rather than Glasgow street slang.

[1]: https://en.wikipedia.org/wiki/Bowery_(disambiguation)

I combed your entire website and I don't have any answers as to what your product does or why it is the future of Web development and I'm not interested in giving you my email address to find out.
If you follow the link on the main page to "Learn more about how Bowery works." it first asks you to install npm

1) Is npm something that comes standard with any operating system these days?

2) Why do I have to install something on my system to "learn" how it works?

This page should probably be what many comments here are trying to say which is that the site doesn't really say what it is. Something like Google App Engine, but using Node?

npm is the Node Package Manager. I think it's assumed that if you've been working with Node.js (or other things in its family, like CoffeeScript), you've already downloaded npm. It's like when a Python framework says "Just use pip install!" or a Ruby project says "Download our gem!"

That said, they really should have more info before dropping you on the install page.

I'm not quite sure what it does, but it looks like a framework which integrates your hosting solution?

Also, Is it me or is the pricing ridiculous?

The names great.

I might have misunderstood a lot, it's very unclear and I'm confused. Also if the UI are part of the package, they look too "bootstrappy", if that's a valid complaint.

UI is not part of the package. Thanks for the feedback!
I find it mildly annoying that it's so similarly named and so completely unrelated to Bower - the extremely popular package manager...
Bowery is a street/neighborhood in New York City.
$1 per KB read per second.

I'm confused, what does it exactly mean? You pay $1 for every KB read from DB, so 10MB will cost you $10.240 or what?

It's a measurement of throughput. So the maximum data transferred/sec at any given time.

Good call, I'll update the pricing to clarify that.

The documentation looks nice, but the pricing page is just confusing (at least for my colleague and me).
that's good feedback. Would a pricing calculator help or is it just that there are too many cost centers?
A calculator would probably help. How about showing some sample setups (and their resulting costs) for different kinds of webapps?
$1 per KB read per second. $2 per KB written per second.

wait. what?

Hey sorry, this was a typo. It's cents :)
After going through the documentation and your home page, I still have no idea what this product is actually about.
Looks to me like a proprietary web framework nicely integrated with a proprietary database and proprietary cache.

If their DB & cache really are as great at automatic optimisation as they say then I might be interested as stand-alone products to run alongside my current stack; not a great fan of vendor lock-in though, so I think I'll be skipping it for now :(

Am I the only one that absolutely hates downloading, exploring, configuring, and managing new software? I don't trust it. I rather use something old with a known track record.