My thoughts on WAB

4370
13
06-05-2019 11:41 PM
simoxu
by MVP Regular Contributor
MVP Regular Contributor
9 13 4,370

As a developer I used WAB Developer Edition on two occasions in the last 3 years. Here are some of my thoughts.

1. Some important functions are missing in the out-of-box widgets. just think what you will do on the digital map: I will select features (by attribute or by interacting with the map), add / remove the new selection to / from my existing selection. But the Select Widget does none of this. and the Select widget only works for visible feature layers, no tricks can be done on the map service to make it seemingly selectable.

2. Actually the Query widget is more like a selection widget if a confusing and useless (most of time) temporary layer not being created for every query. Can't we just create a temporary memory layer which is managed by the application rather than by the user?? Most of user don't even know a layer is created for this operation. If I need my users to select on the map service (better performance in some cases, advanced cartography), I have to let them do a query first before they can select, what?? 

3. There are no Select By Attribute function. Instead, they provide two filter widgets , Filter and  Group Filter. But sometimes I need simply select and highlight features rather than aggressively filter out other features. don't we do this all the time in the desktop GIS?

4. If I am not happy with the existing features / lack of features, I can always customize existing widgets, since I can write code and I have a WAB Developer Edition. right? I have to say I did get some good stuff done, but I don't like the experience. The main problem is the documentation for the JIMU architecture and its detailed API reference. It was so poor and out-dated  that I had to read thousands of line of code to figure out how to add tens of lines of code of my own! I've been a developer on ESRI platform for quite long time, I feel the quality of the help document is not on par with other ESRI product for developers --- It lacks details. Developers need details, because their work are like under microscope. 

5. I noticed there are many new widgets released since I first used it 3 years ago, but most of these are not useful for my projects. Let's go back to the basic widgets that everyone uses and bring back the consistent user experience that ESRI has established in their desktop products. how about starting with comprehensive selection function and doing stats/reports on arbitrary selections? and giving the developers stronger support by providing good documentation and examples if we are going to continue the Developer Edition.

I can't help thinking the Flex Viewer days, the application architecture was elegant and well-documented, so did the APIs, the spirit of the developer community were high... OK, have to get over it now 

I am not all negative about WAB, quite opposite actually, I like WAB in portal and ArcGIS Online, which provides great flexibility when sharing your maps. Just my expectation for the Developer Edition is much higher than that for the WAB online version.

13 Comments
Arne_Gelfert
Occasional Contributor III

Thanks for sharing your thoughts and providing some helpful feedback. I couldn't agree more with you on the shortcomings one is faced with once headed down the WAB highway.

Now, I wouldn't call myself a developer. I do too many other things in GIS and suffer too many distractions to focus on straight up developing. But I've spent a good amount of time working with and learning the JavaScript API. Coming from a Python background, I was surprised to actually enjoy coding with JavaScript. But the chasm between the WAB world and the world of using the API strikes me as ridiculous. Yeah, yeah, it's all JavaScript. But why come up with one neat n' clean API and then muck it up to make it work with WAB!?

I get it: WAB gets you a quick "deliverable" and it allow folks who can't or don't want to write a line of code to make a web map. But I need a lot of custom widgets, and the process of marrying some custom functionality I create with the API to some widget like UI element has been confusing. I gave up when I found myself reading about jimu and not getting it. Instead, I went back to creating some HTML buttons and calling my JS functionality from a click there, and have been playing with Calcite Maps. You can still share your app through Portal. You just can't let folks plug and play with widgets.

I've posted here and there about this general dilemma and never get any feedback, so I have to wonder what most people do. Those I've spoken with at the Dev Summit or other ESRI events have all urged me to not go down the WAB path if I'm expecting to want to do custom stuff. Regardless, I've gone so far as learning some Typescript to follow the How-To for custom widget development. But I just couldn't help thinking there should be a better way.

So if you or anyone else is willing to share their secret sauce, I'm all ears. Maybe I should do a survey?

RobertScheitlin__GISP
MVP Emeritus

So the issue really is people like you who are inbetweeners. WAB is exactly as you stated a great platform for people to stand up a mobile friendly great app with no development experience required. The JS API is a powerful tools for developing custom web based mapping site but does require development experience. So for you that is somewhere in between you get the short end of the stick. For a developer they can decide if WAB is a good fit for their project as it has the widget framework and all the mobile friendly bit baked in, or do they go completely vanilla and have to do all the grunt work of ensuring mobile friendliness and developing a UI for their app.

So the other main issue for you will be do you spend time leaning dojo dijit/widget development for WAB or do you focus on JS API 4.x which the new Experience builder is using. My recommendation is the latter. Experience builder is the future so you should spend your time learning how to program against the 4.x API. That being said what do you do in the short term as Experience Builder is just in beta... For a developer learning the WAB jimu library is not real difficult you just have to open the files and follow the code logic in existing OTB widgets and then being able to take the WAB developers widgets samples folder and grab the customWidgetTemplate and use that as a starting point for your own custom widget is not a huge hurdle. Only advice that is really pertinent here is to look at the code in existing widgets use that as a roadmap for learning about creating your own (that's how all of us widget developers started).

Arne_Gelfert
Occasional Contributor III

Thanks, Robert. Yes, I will gladly own up to being a professional in-betweener. Although I'd argue with me being "the issue". Haha. Sounds like you're saying I just haven't waded deep enough into the widget waters? I did work through the tutorial on creating custom widgets once a few months back and looked at the samples in the WAB folder:

… \arcgis-web-appbuilder-2.12\client\stemapp\widgets\samplewidgets\CustomWidgetTemplate

It just wasn't nearly as much fun as working with the API. I guess in my mind I just kept thinking: there's gotta be a better way! But in the absence of one, I will see what I can learn about this approach. Appreciate your pep talk and will see if additional effort with jimu pays dividends. Thanks for all you do on this forum!!

simoxu
by MVP Regular Contributor
MVP Regular Contributor

I absolutely agree with Robert about WAB as a platform with responsive design baked in. and it is useful for many in many cases. 

I mainly suffered from using the WAB Developer Edition (WAB DE)to develop custom widgets. The reason I use WAB DE is because I am not confident I can architect a sound application framework by myself(maybe also not worth it only for my project), and WAB DE can provide me a framework to start with.  but unfortunately this framework is not documented, only very basic document for how to build a widget ---- but, but the interface provided for the custom widget to communicate with the framework and other widgets (out-of-box widgets and custom widgets ) are ridiculously simple and useless in most of my cases. 

If I am provided sufficient interface to use, I won't be tempted to go to the backstage (jimu library) to see how it is implemented. I can read jimu and I did read some modules, but without any documentation I won't say it was as easy and pleasant as reading a romantic novel, if I can read it as easy and pleasant, I may be better off to create my own application framework and claim I am a software architect, lol. Anyway, ESRI does not seem to encourage us to understand the application framework otherwise they will provide some documentation. 

Just to show you what I mean, let's take a look at the widget.js of the Measurement widget (I randomly choose this):

Without documentation, how can I dream up loading those jimu modules if I want to create widget like Measurement widget??

The so-called WAB API Reference (CSS framework—Web AppBuilder for ArcGIS (Developer Edition) | ArcGIS for Developers )  is so simple and inadequate, that I have to wonder what API, where is it?

I was forced to read the jimu source code to learn the application framework, I am sure you will agree this is not the easiest way to learn--- I've learnt other frameworks before. In my view, a framework/API without document is only half baked.

I would like to urge ESRI to slow down the new widgets development, and instead change course to support developers with the greater knowledge about framework and APIs, by doing that more useful custom widgets will be created and shared by developers in the ESRI WAB Community. Overall, developers know better what widgets their clients need than ESRI staff working in their office, ESRI staff know their own framework and API much better than anyone else!

 

JoelHickok
New Contributor II

Web App Builder gets the job done in some cases, and very much falls short in others.  When off-the-shelf widgets and configuration works, then great - lucky you.  When it doesn't work, you will be making compromises or customizing.

Typically, I develop lean custom JavaScript apps and use the esri-loader tool to abandon Dojo and the JS API's dependency on Dojo, and use Vue.js or Svelte to develop with the JS API or Esri Leaflet.  But my team sometimes needs a custom WAB widget, so I have been unlocking a better workflow to use with the Web App Builder Developer Edition.

For those developers who have moved forward and embraced modern development tools, working with the WAB Developer Edition is a big step back.  If you typically use a bundler in your workflow, like Webpack, Rollup, or some other tool like Gulp, and if you are used to things like hot reload, then you will want to be working to create some kind of more pleasurable and efficient workflow for WAB Dev Edition.  I have cut my development times down by hours, or days, depending on the project, simply by building my Widgets in another framework and then linking this back to my WAB Dev app.  I use LiveReload to reload my WAB app when my widget files are updated... you can set a delay to avoid excessive reloads, or just have it reload on save is usually good enough.   

Even though Dojo is a great, stable, and solid framework, I hate working with it.  So I worked out how to build widgets with something like Vue.js or React, and load them into the Widget framework seamlessly.  Even better, if you use Svelte.js, the code is compiled ahead of time and you don't even have to use any framework.  This gives you a lightweight and fast-loading widget that seems far superior to Vue, React, and especially Dojo, and you don't have to add to the Web App Builder bloat by loading yet another framework, you just use Webpack or Rollup to output a Widget Class that has all the extra JS and CSS bloat eliminated.  It's really quite easy for those who haven't used these tools, or feel like this sounds intimidating.

This has resulted in a much more pleasurable experience for me as a developer, but more importantly, enabled me to produce lighter-weight widgets much faster than before.  I plan to try and get around to writing an article or post about this somewhere, as I believe Svelte.js is currently the best solution for building a widget that can still use the functionality of all the built-in WAB tools and map components, like other widgets, Feature Layers, and so on.... but without adding additional load time or code bloat to your apps.  My most recent Svelte widget for WAB interacts with the map, responds to map and feature layer events, and utilizes ArcGIS JS API modules - but was built using Svelte.js and the Spectre.css framework and is post-processed on the fly with Uglify.js to remove all unused code and css before it even gets attached to the page and integrated into the Dojo/Jimu framework.

JoelHickok
New Contributor II

Arne - You are very much not the issue.  Esri creates many of the issues, but then we as developers are just trying to constantly learn slightly different development environments.  I work confidently with the JS API 3.x and 4.x, but had to wander through some spotty documentation to "put together" a lot of missing pieces with WAB Dev Edition.  Finally, I learned enough to just get out of the WAB platform and build my widgets elsewhere and then easily re-integrate them.  I will be looking at the Experience Builder and working the 4.x library so I can continue to support my Team in using custom widgets when they need to.  And as far as wading "deep into the waters," as Robert has... well, those are not fun waters to swim in once you really know how pleasurable other Front End Web Developer experiences can be.  For me, it's a necessary evil working with Dojo and WAB Builder Dev Env, and even the JS API 4.x got better than 3.x and is very powerful, but it is still a PITA to work with sometimes.

Arne_Gelfert
Occasional Contributor III

Thanks for the feedback, Joel. Will have to read that a couple of times to extract goodies. Would love to pick your brain some time on some of these matters. Really appreciate your lengthy contribution here!!

BradWilson1
New Contributor II

That is an article I would very much like to read!

LanceKirby2
Occasional Contributor II

Joel, did you ever end up writing that article?

BrianWilson
Occasional Contributor II

@JoelHickok -- if you don't have time to write anything up formally, can you just share some code in github? Thanks, Brian

BrianWilson
Occasional Contributor II

I'd love to ditch WAB entirely but all our webmaps are built on it, and I am the only one here capable of dealing directly with JavaScript. That means WAB widgets will fill a niche for us if I can learn how to build them. 

I've looked at Experience  Builder and it had about 1/10 the widgets that we currently use. I am not up for writing the 10 or so widgets we need at this time. That leaves me treading water trying to figure out how to jam Svelte code into WABDE.

 

BrianWilson
Occasional Contributor II

I'm dog paddling along with Svelte now. Sometimes hearing someone say "this is the best platform available today" is enough to make me dive in.  I built a small Svelte demo app that puts up two maps, one in OpenLayers and one in ArcGIS API 4.

You can find my code here in Github https://github.com/Wildsong/svelte-maps .

The Svelte template app comes set up with Rollup and LiveReload and it all works great. 

I was able to deploy the little app to a server, just by copying the files.

Now I will try to use Svelte to build the A Hello Widget for WABDE.

BrianWilson
Occasional Contributor II

Okay, I built a docker for WABDE 2.19 and a basic template for a widget. 

The docker image is in Docker Hub as wildsong/wabde and the details include a rough outline of a development workflow are in the Github project Wildsong/docker-ArcGISWebAppBuilder for now

The template for the widget is in Github at Wildsong/arcgis-wab-widget-template.

Now I am going to go back to that Svelte widget and get that working in this workflow.

 

 

About the Author
GIS developer and analyst