lucas.gonze at gmail.com
Thu Oct 10 09:10:21 PDT 2013
The server side options you're looking at are all smallish parts of the
stack. Node, for example, doesn't include Express,much less testing,
database, templating, caching.
The lesson of Rails is that optimizing the bundle as a whole is important
for developer productivity. Otherwise your dev shop will be slower than the
best, and your company won't be technologically competitive.
On Wed, Oct 9, 2013 at 7:09 PM, Stephen Williams <sdw at lig.net> wrote:
> Server side, I'm most interested in Node.js + js/node-java and/or nginx +
> C++. Java server code is OK, and should be an option, but I'll probably
> end up at C++ for anything very serious.
> On 10/9/13 4:44 PM, Gregory Alan Bolcer wrote:
> I will look into it! GWT was always a cool idea, but too limited UI wise
> offline mode etc. can be done. I will probably limit myself to methods
> that can produce a ChromeOS off-line app. Can Vaadin do that? Sort of
> There are a number of other interesting server-side Java frameworks that
> could work with various front-ends.
> Really, there is a lot to be said for keeping servers as RESTy,
> transactional services that know nothing about UI. You can always have a
> services if necessary.
> In my case, I need total flexibility to create radically original UI
> mechanisms. It is not always obvious which will give the most power and
> the most flexibility while also being efficient, clean, and fun.
>> On 10/9/2013 12:00 PM, Lucas Gonze wrote:
>>> I see Angular and peers as basically the current generation of web
>>> architecture. Rails+Backbone was best of breed in the last gen, PHP the
>>> winner in the generation before that.
> PHP was OK. Facebook has apparently solved most of the performance issues
> of it. But it is hard to get excited about PHP for everything.
> Got a close look at a well-built Rails project, but I just can't get
> apparently can't really be efficient or scale like better choices.
>>> My own choice among this group is MeteorJS. It has two advantages over
>>> peers. One, integrated stack between client and server, so that you're
> I have that bookmarked somewhere but had forgotten. Thanks!
> using the same infrastructure. Previous generation required different dev
>>> stack for client and server, typically (Rails or Node)+jQuery+Backbone.
>>> Two, copious funding, which ensures longevity.
>>> My team has been doing this for about 9 months, and I'm very happy with
>>> choice so far.
> FoRK mailing list
More information about the FoRK