[FoRK] AngularJS — Superheroic JavaScript MVW Framework

Stephen D. Williams sdw at lig.net
Thu Oct 10 10:22:48 PDT 2013


Definitely need something like Express for Node, CodeIgniter for PHP, etc.  Hopefully past the main handling of URL->module mapping, 
session handling, and other basics, the system is clean and modular enough to make easy use of memcached and similar caching, 
various database systems, and in some cases templating.  Hopefully there are libraries for access to Facebook's login and graph API, 
etc.  However, I'm wary of all encompassing frameworks that make assumptions that you're building a typical business or social 
networking app.  I'm not going to invest time in a stack that doesn't allow maximum flexibility to swap out subsystems and standards 
as needed.

Just like embedding SQL in application code is usually a terrible practice, I'm past living with machinery that only understands 
relational databases or standard data types.  Application-specific DAOs may or may not be a clean alternative.  Even the form of 
persisted state and variables can be highly restricting.  Do I want to squash all state to strings in a flat map?  Not in my most 
interesting cases.  If I want to communicate between modules / tiers and maintain state with Google protocol buffers or JSON or W3C 
EXI or my own efficient RDA-like interchange (ERI), with deltas, and use graph and document databases along with relational, which 
framework is best?

Its fine to have a nice baseline for common cases, but is it separable and replaceable with modest effort while maintaining 
performance, scalability, maintainability, *ility?

The overall stack is extremely important and best practices keep evolving.  I'm reluctant to use a stack that tightly binds all 
components if it is difficult to replace or use multiple solutions for key aspects without heroic effort.  Working with Rails didn't 
excite me.  Some Java stacks look nice, but the endless layering and intertwining of many libraries also makes me uncomfortable.

Having no strong reason to default to any stack at the moment, I have too many apparent options with the shallow impression that 
none of them directly support what I think I want.  So, which one has the shortest distance and most flexibility to easily become 
what I think that I want?

Some systems can be eliminated early because of scalability and efficiency issues.  Node and Nginx, perhaps with certain Java 
solutions, win here while Rails and other Java solutions seem to fail.  PHP is now OK for performance due to HHVM but is challenged 
in language/development sophistication.  Javascript (via v8 or similar JIT), Java (+Scala et al), Go, and C++11 (and maybe C++11/Qt) 
are interesting on the web side, although practically no one is using C++ there.  It is important to have libraries to access all 
interesting services and standards.  Last I looked, Go had a long way to go.  Java excels in libraries, documentation, and service 
support, Javascript probably is reasonably good.  For C++, probably have to write your own modules or delegate to a paired Java 
server (not a terrible option, depending on application) or use JNI for a C++/Java combo.  Perl is no longer interesting.  Python, a 
reasonably good language, seems waning for web dev, and the frameworks seem too tightly bound and maybe are falling behind.

sdw

On 10/10/13 9:10 AM, Lucas Gonze wrote:
> 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:
>>
>>> Vaadin.
>>>
>> I will look into it!  GWT was always a cool idea, but too limited UI wise
>> in practice.  I'm still unclear with these Java->Javascript methods whether
>> 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
>> maybe:
>> https://vaadin.com/blog/-/**blogs/offline-mode-in-vaadin-**
>> apps-absurd-joke-or-a-real-**solution<https://vaadin.com/blog/-/blogs/offline-mode-in-vaadin-apps-absurd-joke-or-a-real-solution>
>>
>> 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
>> separate web app that provides a low/no Javascript front end for those
>> 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
>> excited about it.  Language isn't more interesting than Javascript and
>> 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.
>>>> http://venturebeat.com/2012/**07/25/meteor-funding/<http://venturebeat.com/2012/07/25/meteor-funding/>
>>>>
>>>> My team has been doing this for about 9 months, and I'm very happy with
>>>> the
>>>> choice so far.
>>>>
>>>>
>> sdw
>>



More information about the FoRK mailing list