On Sat, 14 Apr 2018, at 4:40 PM, Alexandre Rafalovitch wrote:
> Hello,
> The relevant JIRA is SOLR-12196, but we felt this deserved a greater 
> discussion.
> Basically, our Admin UI is currently using AngularJS (1.x) as its
> Javascript framework. That particular library has reached its
> evolutionary end long time ago and is about to stop being supported
> all together. The later versions of Angular carry the same name, but
> are _very_ _very_ different. So, despite the heroic efforts that got
> us here, we are facing this choice again. Also, as we were just trying
> to migrate the UI and not rethink it, the underlying design/file
> layout/plugin architecture is also quite problematic.
> The question is what is the right thing to do next. There are
> basically four options:
> 1) Migrate to the latest Angular in an incremental fashion (as per
> JIRA's original proposal)
> 2) Jump to a different library (such as React or Vue) which got a much
> stronger momentum and ecosystem these days, but sort of keep current
> architecture (UI feel/approach)
> 3) Go blue-sky with new library and actually put some deep thought
> into modern UI leveraging Solr's current features (Management API,
> JSON, etc). Also, by picking React (for example) we get access to the
> ecosystem of modern tools, extensions and even potentially mobile
> apps.
> 4) Drop our own UI and adopt somebody else's (I don't have any good
> suggestions here though)?
> Normally, option 1 would be the sane one. The challenge is two fold though:
> a) Even option 1 is a lot of work due the Angular team's radical
> change of direction. Enough that it will lock us out from any other
> option for at least another 3-4 years.
> b) We are all server-side developers. So, even the simple Javascript
> things are hard for us, never mind the CSS part. So, this makes the
> cost of starting with any new approach dis-proportionally hard. Once
> going, it is a bit easier, because the advanced concepts are similar
> to other languages.
> All of these, combined with all the open JIRAs on Admin issues - to me
> - make option 3 less crazy than usual.
> What do others think? Is there discontent with the current state of
> Admin UI (apart from the implementation choice)? Are there secret web
> designers here, willing to get us over a bump of migration? Is there a
> company out there, willing to sponsor relevant skills to let us
> leapfrog the incremental upgrade (similar to how we got the Reference
> Guide).

As you know, I'm responsible for the current UI. The aims in building this 
version of the UI were to keep the visuals entirely the same, whilst reducing 
the size and complexity of the underlying JavaScript (we reduced it by about 
50% in terms of LoC). The bulk of the work in its implementation was in terms 
of understanding the intent of the existing code. Reproducing it in new code 
was a smaller task by comparison. I hope this will pay off in any future 

At the time, the JavaScript landscape was changing fast. It was clear that 
anything we produced would only be valid for a number of years. It seems we 
have now reached that limit.

I have recently taught myself basic ReactJS. It is clearly a powerful beast. 
The two major distinguishing factors from the current UI are its componentised 
nature (which means you don't build pages, you build re-usable components) and 
that it uses a transpiled language. 

To rebuild the current UI in React, we would need to decompose the HTML pages 
into components, and migrate behaviour into those components.

Using a transpiled language (and all the tools that support that, e.g. webpack) 
would give us a more compact, and modern, UI.

However, the HTML is growing old. It isn't properly responsive, and it doesn't 
use idioms that people have come to expect from a UI (e.g. no hamburgers).

In theory, I would support a rewrite of the visuals - it would make Solr seem 
more modern. However, I do not underestimate the amount of work involved.


To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to