My first thought as well. It is an interesting project!

So, one thing holding me back from using MongoDB (and thus Meteor) is a lack of understanding how schema can be managed.

Say in MongoDB you are storing documents in a collection such as { property: "" }, and decide you want to change that to { property2: "" }. Does that mean you have to script a change to every document to convert these objects?

in this case "renaming a field" it would be something like

`Collection.rename('property', 'property2')`

my syntax may be slightly off since i mostly use mongo thru a ruby orm but the basic idea is the same.

we handle these things by having a tasks we run each deployment (named after the deployment version) with the necessary db changes.

That's not data management. That's schema management (migration).

And yes, you have to script a change to every document.

Right. And I see. Are these managed by something like migrations?

Meteor doesn't have migrations built in, but there is a package for it. https://atmospherejs.com/percolate/migrations

From my brief experience with Mongo no. But they are very easy to do in code.

As far as I know, this is an issue for every database, no? What are you currently using?

Except that in every other database a migration like that changes a column, that's it.

In MongoDB you have to manually walk all your objects and migrate them.

Well, in relational SQL you would just do an ALTER on the column name.

I find NancyFX really interesting, but I can't really see a reason to stray away from Web API2 besides Mono support. Any specific reasons you prefer Nancy?

I've been wondering this, too. I've been using MVC since version 2 and am very comfortable with it and Web API, but a startup I've been doing side-work for is using Nancy. Nancy does seem lighter weight, and includes TinyIoC for dependency injection out-of-the-box, but I too don't see a real killer use case for Nancy.

It's nice to serve webapi's and serverside pages from the same class. I like the content negotiation in Nancy. Also the built-in testing features are nice, it is easy to test views too.

Mono support is important for us and I prefer the syntax. It's also handy to be able to serve up ancillary pages like documentation alongside the API.

I agree with you, but maybe because it's lightweight? It's pretty damn simple.

Make School takes 25% of your salary for two years. $45,000 is quite a price tag in my mind.

This is where I get confused. How is it compiling to these elements?

One possibility: You have a JS interpreter running your React code. You generate a virtual DOM and hand it off to React. React sends the virtual DOM through a message bus to native code. So far, nothing crazy here, this is how frameworks like cordova work. That native code dynamically translates the virtual DOM into native UI elements.

That's the million dollar question and tomorrow we might get an answer.

I am pretty confused as to what this actually does. How can it be native?

My guess is we're missing an important piece of the puzzle. Unless they have a js to everything interpreter. In which case thats much bigger news than react.

Its more of a shiv to convert react elements/calls into native UI elements, using a native server to receive streams/messages (unsure which) and convert them.

Instead of having React render to the DOM it renders to Native views. Be it iOS, or Android.

I doubt it would happen at runtime in iOS/Android, though? They would need to ship a JS interpreter that gets run on application startup, parse the React files, instantiate the native controls and create a bridge between them back to the JS interpreter?

Well on second thought I guess Appcelerator Titanium does something similar. So it's native UI only, but with the added overhead (JS interpreter + bridge, larger binary size, slower startup, etc.).

>They would need to ship a JS interpreter that gets run on application startup

Um, why? They already have JavaScriptCore (it's an iOS API).

Depends. There could be a build step that compiles all that logic. Or there could indeed by a JS runtime.

The service is ran by CrowdSource, who uses Mechanical Turk to divvy out the task of responding to texts at a very small rate. So, it is a lot cheaper.

I feel bad for Yammer.

My first thought was, "So Facebook released Yammer?"

But after some thought...

It will be interesting to see how this will be differentiated from Yammer. Yammer may actually benefit from this ... companies that are considering workplace social networks may evaluate all options, and then realize that Yammer has been out for quite some time and touts over 200,000 corporate customers.

Many companies have Facebook restrictions in place, and I don't see that trend reversing due to this announcement. Yammer, separate and distinct from Facebook, may see a bump due to more companies "being interested" in work place social networks.

Agreed. I've used Yammer before and it's pretty decent.

If I was a company looking to use a "Social Network for Work" I would prefer a separate product like Yammer instead of Facebook.

I could see FB creating a "whitelistable" domain where you can only access @Work stuff so that enterprises would be happier to use FB@Work. Something like work.facebook.com

If it makes you feel any better for them they sold for 1.2 billion to Microsoft in 2012

Ah, what a relief.

PHP, C#, VB.NET, Python, JavaScript, Microsoft SQL, MySQL, HTML, CSS. Switching between them doesn't slow me down.

Programming in HTML and CSS sounds awesome.

Touche.

This looks cool, but I'm not a fan of this tagline: "Your current blogging platform is complicated, slow and badly designed. It makes blogging a chore."

I came to write the same thing. I use org-mode + Jekyll and it couldn't get any less complicated. It's not slow and not badly designed either, IMO.

A counter-argument: if you already love your blogging platform, you're probably not in OP's target market anyway.

However, if you agree with the headline, you're definitely in the market for what Blot provides.

Really appreciate the feedback. Will come up with some alternatives to this copy to test.

I think you'd be better off to just drop the statement completely. The line below it reads, "Blot is the simplest way to blog." That's short, clear, and tells the visitor why he/she should be interested.