Quantcast

Timely article about rewriting a JavaScript application

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Timely article about rewriting a JavaScript application

James Klassen-2
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Timely article about rewriting a JavaScript application

blammo
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 <[hidden email]> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc

_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Timely article about rewriting a JavaScript application

Eli Adam
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.

Thanks, Eli


On Tue, Apr 5, 2016 at 8:59 AM, Basques, Bob (CI-StPaul)
<[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>
> _______________________________________________
> geomoose-psc mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Timely article about rewriting a JavaScript application

Eli Adam
On Tue, Apr 5, 2016 at 10:45 AM, Eli Adam <[hidden email]> 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)
> <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>>
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Timely article about rewriting a JavaScript application

James Klassen-2
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 <[hidden email]> wrote:
On Tue, Apr 5, 2016 at 10:45 AM, Eli Adam <[hidden email]> 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)
> <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc
>>
>> _______________________________________________
>> geomoose-psc mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geomoose-psc


_______________________________________________
geomoose-psc mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geomoose-psc
Loading...