[geomoose-psc] Timely article about rewriting a JavaScript application

[James Klassen]

Another item as we are thinking about how we want to architect GeoMoose 3:

Compiling, Debugging and (unit) tests of the JavaScript.

The current Dojo build process makes it nearly impossible to tell what line
of code caused an error.  Some errors only show in the compiled code and
not the _dev version and require a 30 second rebuild lengthy browser reload
to test even the smallest changes.  Reloading the _dev version skips the
rebuild, but takes even longer.

Also nice would be something that starts a mini-web server that will watch
for file changes and auto-rebuild, and a make-like build system that only
rebuilds what changed rather than always rebuilding the whole project.

I know some of this comes for free with newer versions of the libraries,
some with enabling sourcemaps, etc.  But it would be very helpful for me as
a developer and probably for others approaching the project if these
aspects of the development cycle were a lot smoother.




On Tue, Apr 5, 2016 at 1:06 PM, Eli Adam <eadam at co.lincoln.or.us> wrote:

> On Tue, Apr 5, 2016 at 10:45 AM, Eli Adam <eadam at co.lincoln.or.us> wrote:
> > Great article, thanks for pointing it out Jim.  It provides lots of
> > concepts and options for thought.
> >
> > Abstracting the mapping library (and accommodating both OL and
> > Leaflet) is an interesting way to avoid tight coupling and already
> > build for the next version of those libraries or some future library.
> >
> > Separating state and components is a GeoMoose challenge as well.
> >
> > Most of the demos tend to be single function demos.  The geology app
> > screenshot looks more like a every-function-combined-to-work-together
> > app.
>
> Something that I failed to mention during the PSC meeting was that on
> moving geo-functionality to JS, there are starting to be good JS
> geoprocessing libraries and some people do cool complex things with
> them, but so far, those are usually *one* complex thing per
> application and it is often with *points* not lines or polygons.
> Whereas, GeoMoose has always done *many* complex things on complicated
> *polygons*.  MapStore 2 is one example of more functionalities and
> more complex data, another proof of concept is
> https://github.com/cugos/dropchop
>
> Eli
>
> >
> > Thanks, Eli
> >
> >
> > On Tue, Apr 5, 2016 at 8:59 AM, Basques, Bob (CI-StPaul)
> > <bob.basques at ci.stpaul.mn.us> wrote:
> >> I would second the need to at least do a quick review of the article.
> Lots of pertinent stuff in there. (I think).
> >>
> >> bobb
> >>
> >>
> >>> On Apr 5, 2016, at 10:14 AM, Jim Klassen <klassen.js at gmail.com> wrote:
> >>>
> >>> I found an article on Planet OSGeo that talks about lessons learned
> when
> >>> doing a "modern" rewrite of a complex javascript application.
> >>>
> >>> http://www.geo-solutions.it/blog/mapstore-2-modern-webmapping/
> >>> _______________________________________________
> >>> geomoose-psc mailing list
> >>> geomoose-psc at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
> >>
> >> _______________________________________________
> >> geomoose-psc mailing list
> >> geomoose-psc at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-psc/attachments/20160407/fa33e18d/attachment.html>