• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Migration of Spring Mvc with jsp to spring boot and javascript frameworks(Angular /Reactjs/Vuejs)

 
Ranch Hand
Posts: 333
Scala Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers,

I have a small question regarding the above topic.

How is the migration of spring mvc with jsp (JSTL) to spring boot Javascript frameworks(Angular /Reactjs/Vuejs) helpful?

What are the advantages of doing so?

Regards,
-Pankaj.
 
Greenhorn
Posts: 22
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It depends on your application.  If your application has lots of screens then I generally stick with the classic MVC pattern.  However, I definitely prefer the SPA design pattern with classic MVC over full page refresh because FPR forces you to constantly persist user input to the server user session between data collection pages until you finally persist to the database.  This can create a real spiders web of controller mappings, which doesn't proliferate near as much with a SPA.  An Angular pattern works best with a simple application containing few screens but lots of chatty back and forth of a few items.  The json data binding model of Angular becomes a real headache when you have lots of screens with lots of variety.  It's a pain to maintain for developers and I've seen it get really sphagetti-ish.

You may hear that Angular is better overall because of its use of stateless service REST calls to pull down data.  However, a web server hosting classic MVC can easily be made to be a pipeline node leading to all the different service calls anyway.  Even when used with Angular, I prefer the architecture of this pipeline model because its impractical to authenticate  a browser against multiple servers and doing so creates a single origin violation anyways.  So, most developers trying to talk to services through Angular hit a proxy server that servers as a pipeline to the services.

So, in the end, a classic MVC vs Angular discussion isn't actually a debate about the ability to support services and micro services.  Both architectures can leverage services just as effectively.  It is actually a debate about where you think its easier to maintain your layout, on the browser or on a web server.  It's not about performance either.  Anyone that tells you an Angular app significantly outperforms a JSP app because the layout is not as heavy as the json is living in the early 2000s.  The improvements in CSS have made it possible to make the HTML very thin (example, no reason to round corners with images anymore), and network speeds are such that a 2k json object and a 10k html page with data in it are so close in performance that your users won't feel the difference.  Furthermore, Angular's heavy js framework can perform poorly on the browser side for large pages when grinding through large json arrays especially when building tables.

I see everyone dropping Angular where I work.  It seems that React is the golden child these days.  I honestly do not have enough experience with React yet to accurately compare it.  However, I think a well written SPA is still a great way to write an application, and jsp is so darn intuitive it is hard to beat for felixibility, development efficiency and control.

I'm sure there are some devoted Angular specialists that are eager to chime in here.
 
Pankaj Shet
Ranch Hand
Posts: 333
Scala Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Mathew for this Answer. But do you mean Migration will not help much?

I feel that javascript frameworks will be much lighter compared to JSPs.
JSP is a server side rendering. JSPs will be converted into servlets, and then they will be rendered.
Hence, render perfomance is slow in case of JSPs.
Javascript frameworks will be Client Side rendering, hence performance will be much faster.

Apart from the above, How are JSP's advantageous over Javascript frameworks?

Regards,
-Pankaj.


 
Matthew Keller
Greenhorn
Posts: 22
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your welcome Pankaj.  Both json and jsp have to be rendered server side.  For example:

json

{"person": {"firstName": "John"}}

html/jsp

<div class="inputRows">
   <div class="inputLabel">First Name :</div><input type="text" name="firstName" value="John"/>
</div>

The first name in both these cases has to be pulled out of a java value object and rendered into the json or into the input, on the server.  Json's are lighter rendering but they are still rendered on the server.

Now with an angular implementation the html has been previously sent to the browser and cached before the json arrives.  So, the incoming json data is unpacked from the json object and dynamically written using javascript to the "html" which is now in the form of a DOM object in the page.

So, to make a long story short, the Angular paradigm caches all the HTML layout in the browser, without any data and the data is sent later.  Whereas in the jsp paradigm the layout it sent with the data.

Will this mean that less information is sent on average with the use of json.  Yes, it will.  Will the difference be so big that it noticibly affects your user's experience or your application's ability to scale.  My experience is that no it won't, especially if you write your JSP application as a SPA.  A SPA only delivers changes on the screen, unlike full page refresh, so its way more efficient than old school full page refresh JSP.  Above you can see a realistic example of the message size using the two paradigms and its not much.

So, you might ask yourself.  Why would I want to give up any of that performance improvement given to me by using the json model?

1) Speed of development.  As you can see above you still need to render json on the server and you as a developer will need to write that code.  You could use a library to unmashal your java objects but then you will end up sending huge jsons and only use a couple fields from them.  It is preferable to unpack your VO into jsons yourself.  This is the same amount of work as rendering your data straight into markup.  However, when you do jsp you are more or less done at this point.  Not so with json.  You now need to write code that "binds/unpacks" the json on the client side.  In the Angular world it looks almost exactly like jsp.  So, now you are rendering json on the server and also writing "jsp's" to run on the client.  Twice the work.

2) Complication.  Keeping your jsons and your html lined up is complicated and error prone.  It is also abstract.  Angular is more complex than good ol jsp and therefore far less intuitive.

3) Layout control.  In order to avoid writing a whole lot of complex packing unpacking javascript on your own you will most certainly leverage angular widgets to do a lot of this heavy lifting for you.  Since these widgets are sewing together your jsons and your layout, you now have much less control over you html, css, and everything else.  This might be all fine and good if you are happy with an average to crappy looking UI.  However, I have worked with Web Designer wizards and those guys want to control every div, every class, and every aspect of the layout.  They hate it when a framework is doing what it feels on the client side and making their lives difficult.  On the other hand when you deliver straight up HTML you give them full control of everything, then you as a web developer only concern yourself with tags that throw dynamic content into the layout and leave the rest of the layout to an expert.

4) Jquery libraries.  Great things have been done with jquery but these libraries do not work well unless the DOM is stable.  For example, jquery drag drop is super powerful but it won't work well if angular is pulling the rug out from under its feet while its trying to do its own thing.  Go google "using jquery drag drop with angular" if you want some examples.  So, there has been a drag drop written for Angular now, but is that what you really want?  You want to have everything you write have to be angular aware now and to work side by side with angular to make sure that the javascript code does not fight for control of the DOM?  What happens when there is an Angular upgrade and they redefine some kind of notification queue or the way an event is attached.  I'd rather have a stable DOM in a known state that I can then layer stand alone js utilities on.

I think that covers it.
 
Matthew Keller
Greenhorn
Posts: 22
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By the way.  Going to Spring Boot or containers, or the cloud in general is a totally different topic.  My answer to that is "yes do it".
 
Pankaj Shet
Ranch Hand
Posts: 333
Scala Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot Mathew for writing all this..
 
The harder you work, the luckier you get. This tiny ad brings luck - just not good luck or bad luck.
Enterprise-grade Excel API for Java
https://products.aspose.com/cells/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!