Hi,
I just did a quick review of what Ember.js is, and what its
strengths and weaknesses are, compared to Dojo. This assessment is
definitely not coming from experience with Ember, but with a lot
of Dojo experience, so I'm sure it's biased. But here's what I
noticed:
Ember strengths:
- Routes, more opinionated management of controllers within the
page
- Single DOM event listeners for entire application
- Views automatically delay re-rendering, possibly more
streamlined DOM updates with less iterations
Ember weaknesses:
- Ember.data stores seem to be far less developed than dojo's
stores and data objects, and still marked with an unstable warning
- Not seeing any declarative way of adding widgets to existing
code -- means there's a lot more effort involved to get results
As I look at this, I still wonder why Dojo is shunned in so many
circles. It is really a pioneer in this area, providing a huge
amount of the functionality that's in Ember, and it provided it 6,
7 years ago, ages before this new generation of JS frameworks. And
it still leads in areas like data management, defining APIs for
paging, sorting, and searching that I don't see mentioned anywhere
in Ember.data, things that will be especially useful for showing
the transactions in an account (if I go to a chart of accounts
report now on certain accounts and don't put in a filter for date,
I need to wait for close to a minute for it to return a few
thousand transactions!). And I really like the new encapsulated
AMD (Asynchronous Module Definition) pattern, find it really
effective for preventing conflicts with other libraries, keeping
the memory footprint lightweight, and swapping out event libraries
to target touch events and mouse events differently for different
devices.
In particular, Dojo to me seems like a no-brainer because we can
enrich the user experience with much nicer widgets, with some very
small changes to the UI templates -- the declarative style of
markup that Dojo provides makes this much simpler to get a whole
bunch of easy wins.
And most of the things I see noted in the Understanding Ember
pages
(
http://emberjs.com/guides/understanding-ember/the-view-layer/)
have been in Dojo for years:
* Templates merged in the browser
* Automatic updates of content in templates, browser side (you do
need to build a widget for this, but it's a very well-defined
process)
* Event listeners (if anything, this sounds more complete in dojo
-- with dojo/aspect, you can observe any function call, not just
DOM events. Personally I use dojo/topic a lot, to create channels
for pub/sub)
* Class definitions, widget lifecycles
So it strikes me that these are the arguments for going with Dojo:
* Can enhance the existing UI today, without needing to start from
the ground up and rebuild the entire UI
* Can greatly improve a page/module at a time, without needing to
build a single-page app
* Can still build towards a single-page app, perhaps with a bit
more planning necessary around DOM event delegation and
re-rendering triggers
* Widgets and systems already written and easy to deploy today,
for handling thousands of rows of data, doing effective
browser-side searches, sorts, and filtering with co-operation with
the server side code
* Decent charting library that can leverage the same data models
we use for raw data display
Cheers,
John Locke
http://www.freelock.com
On 07/30/2013 08:47 AM, Mikkel Høgh wrote:
Hi there,
I've not been very involved with LedgerSMB development so
far, since I'm not really a Perl guy, but I have in fact been
considering starting a project to build a modern _javascript_ app
as a replacement for the current LSMB interface.
I think the two best framework choices for this at the moment
are Angular or Ember.js. I'm really impressed about what the
Discourse guys have managed to accomplish with Ember.js (the
forum at
http://try.discourse.org/ is
in fact a single page app, but it does certainly not feel like
it).
I have built a few apps with Ember, so that would be my
choice, but no matter what _javascript_ framework is picked, I am
willing to help out build it.
On 30/07/2013, at 15.13, Brian Wolf <
..hidden..>
wrote:
John makes some good points.
>>it's pretty trivial to switch between a menu bar and a tree widget.
I've developed with Dojo and can validate John's
statement. It also us the ability to provide multiple
themes or layouts, letting each installation choose the
one they want to use.
Sounds like we're in agreement that substantial
progress can be made in upgrading the user
experience, and that a _javascript_ library like Dojo
is a good place to start. One-page applications
have the advantage of a more
desktop-application-like experience, with less page
refreshes (a visual encumbrance). However, my
experience is that one-page apps can easily become
heavy and are far more difficult to test (case
set-up alone is tedious). One gigantic page may not
be the answer, but several medium-size pages (one
for each area of the app) may be a reasonable
compromise. It facilitates testing and also
independent development by various community
members.
Thanks.
Brian
<activus_logo_small.png>
Brian Wolf
Phone: 410.367.2958
Try out Activus
Secure Payments™, our recurring
payments application.
On 07/30/2013 05:34 AM, herman vierendeels wrote:
I would like to have dojo added to current trunk.
so we can 'probably try out a few different paradigms'
By the time we ever reach production-stage , history-api might be
fully implemented in all browsers
http://www.w3.org/TR/html5/browsers.html#dom-history-replacestate
2013/7/29 John Locke <..hidden..>:
On 07/29/2013 07:36 AM, Brian Wolf wrote:
Perhaps the "common denominator" of an area of the application. For
example, in AR lots of functionality surrounds the customer; in AP,
the vendor. There's probably much overlap in selecting an entity,
viewing (perhaps a dashboard) basic information about it, and
performing operations on that entity (eg, receiving a payment). It
might be effective to have a one-page for a specific area of the
application.
On 07/29/2013 09:49 AM, Chris Travers wrote:
One thing I would ask is that if we go with a multi-page design, what
are the aspects of one-page design that we should be looking into
incorporating?
I think the natural place to start is with overview lists -> detail
views. In many cases, being able to see multiple transactions at once is
very helpful. Having some panes for viewing/editing data, possibly some
modal dialogs for data entry, and similar can be really helpful.
I've got a pretty sizeable single-page app we use for much of our
business, but it keeps the page paradigm -- pages get loaded into tabs
which may be opened or closed. We've pretty much ignored the challenges
Brian pointed out with state across refreshes -- as an internal app, we
just take you back to a launch tab on refresh, you have to open up
whatever you need. I did have a browser history manager partially
implemented that would re-open tabs you had closed when you hit the back
button -- but it wasn't high enough value for us to get fully working.
In any case, converting the multiple pages into more usable standalone
pages is clearly the next step. I think it's eventually worth
experimenting with single-page apps, but not necessarily immediately,
and make sure whatever UI we come up with ends up with a consensus
before making it official -- probably try out a few different paradigms
and see what we all like. Whatever we do, I think the app should be able
to fall back to multiple pages, e.g. with js off, or with a lighter UI
version for mobile, or whatever.
Brian mentioned earlier a drop-down menu instead of a tree -- I was
planning to just replace the current tree with a Dojo tree, which does
use a cookie to remember previous state of expand/collapse. This seems
like a really good place to start our experiments -- once we have the
menu in a store, it's pretty trivial to switch between a menu bar and a
tree widget.
So is there any further objection to adding Dojo to the current trunk?
The version I've put in my git repo does currently weigh in at 62M --
though currently it's adding around 140K to the page loads I've set up
so far...
Happy to see a few other developers on the list with Dojo experience!
Cheers,
John Locke
http://www.freelock.com
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but
databases havent
caught up. So what steps can you take to put your SQL
databases under
version control? Why should you start doing it? Read more to
find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
!DSPAM:51f7e074296851605311589!
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
!DSPAM:51f7e074296851605311589!
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
!DSPAM:51f7e074296851605311589!