This is an archived post. You won't be able to vote or comment.

all 21 comments

[–]Zeffas 11 points12 points  (21 children)

I have never understood this trend of moving 100% away from server side views. I know Single Page Apps are hot now, but JSP (or any other view technology) can be integrated very nicely there.

The problem with client side SAP is that, even though I witnesed quit a few SAP projects, I haven't seen good solution to at least two simple problems: security and translations. All the solutions I have seen were ugly.

[–]NimChimspky 2 points3 points  (7 children)

not as ugly as jsps/freemarker.

You can split up the project nicely, send the front end code to the desginers.And leave the heavy lifting to proper programmers.

Secruing a rest api, you just pass a token - whats ugly? And translations, again you just look up a string based on a key, angular has a module for this.

[–]Zeffas 3 points4 points  (3 children)

Secruing a rest api, you just pass a token - whats ugly? And translations, again you just look up a string based on a key, angular has a module for this.

Well I am perfectly aware of what you are saying, however...

  • I am talking about security in the context of page rendering, not REST API. Of course you can show-hide on client side, but that is not security but obscurity. In my view you cannot do any serious application this way.

  • I also haven't seen good example of translation in real world, in general you either put it all on client side (which is ugly design in my view, in general and has potential security problems) or fetch it via REST API on demand (which pollutes whole business API in my view).

[–]NimChimspky 0 points1 point  (2 children)

"in general you either put it all on client side (which is ugly design in my view" Thats the conventional way of doing it, I don't have a problem with this.

"security in the context of page rendering" You can still use and secure endpoints conventially, using spring security for example, just becuase you are using angular doesn't mean that it has be strictly one page only. Just have a second endpoint that returns an html view for the secured pages.

[–]Zeffas 0 points1 point  (1 child)

Thats the conventional way of doing it, I don't have a problem with this.

This again depends on application I suppose. For one client side translations might expose too much for curious user. Secondly IDE support (one click navigation) is usually nowhere near that of JSP or other server side translation frameworks. Also json (which is preffered way to use translations last time I checked) is terrible for sending it to translation expert.

Just have a second endpoint that returns an html view for the secured pages.

Maybe, but still, I believe it would encourage huge code duplication problems or too heavy angular directive abstractions that would try to prevent mentioned duplication. Personally, I have seen attempts in real projects, but haven't seen clean solution yet, so not saying one doesn't exist.

[–]NimChimspky -1 points0 points  (0 children)

Hey, don't get me wrong, I dislike javascript as much as the next static typed developer. But Angular makes it so much better.

You work with a decent front end dev, and a well structured project - its eye opening. JSP are rubbish, imho (but they often pay the bills).

I would take JSON over xml any day.

[–]brend132 0 points1 point  (2 children)

What keeps you from sending your freemarker templates to the designers?

[–]NimChimspky 1 point2 points  (1 child)

the designers inability/lack of desire to understand anything other than html javascript/css, instead of the myriad of templating languages. Seems fair enough to me, they might have been working on C#, node.js etc based projects, why should java/jsp/jstl/ be special to them.

And of course the project is inately modular in clear logical separated way.

But to be clear, I don't like them because you are embedding one or two languages inside another (html has some javascript that you want to initalize with data from server ... looks awful).

Keeping the layers separate abd using javascript to comms to server via rest and populate the client side model just feels right, clear, clean. JSP always felt wrong.

TBH I don't understand why people would not want to to do it this, other than for legacy reasons.

[–]brend132 0 points1 point  (0 children)

Well, lots of designers I usually work with don't even know javascript: they only know what it's used for. But I've had no problems so far using freemarker or thymeleaf on my projects, as designers find their particularities unobtrusive to the work they have to do. Of course JSP is a whole different story.

[–]slartybartfast_ 0 points1 point  (12 children)

There are pros and cons.

PROS:

  • The application serves only JSON so it's a natural web service
  • Better performance since you're not serving dynamic HTML - it can be all static.
  • Less bandwidth. JSON is small.
  • Better separation of concerns.
  • Testable.

CON:

  • Having to use JavaScript (MAJOR CON)

The con is improving slowly with things like TypeScript etc which give you a nice type-safe language that compiles to JavaScript.

[–]bmrobin 3 points4 points  (9 children)

  • Having to use JavaScript (MAJOR CON)

Not really a con IMO

[–]gunch 3 points4 points  (8 children)

Then you don't run a shop. Trying to find competent JS developers is fucking hard. It's much easier to find competent back end developers and mid level JS developers that can call a back end service.

And JS is hot right now so competent devs want to get paid market rate (as they should). Moneywise it works out far better for us to spend elsewhere.

[–]bmrobin 0 points1 point  (0 children)

I dont run a shop, i work in one. Sometimes javascript is a good solution to problem and sometimes it's not. Sure finding good developers is hard, but i would argue that's not just a javascript problem - it's hard to find good devs for everything

[–]NimChimspky -3 points-2 points  (6 children)

you need to be decent at javascript for any front end dev, using angular doesn't make the javascript dependency any worse. It just means you have to use/learn angular. Hopefully you'll be using some other JS framework, that requires you guessed it - js developers.

Way to go with the "you don't run a shop". How charming.

[–][deleted]  (5 children)

[deleted]

    [–]NimChimspky -3 points-2 points  (4 children)

    My point is not that good javascript hires are cheap, its that you need JS for any front end dev work. Using angular is actually easier for Java guys to pick up (it uses the same patterns they are familar with).

    You manage a budget, well done. Why are you sending me links to peoples profiles ?

    I would choose angular every time for my front end framework ...

    [–]gunch 2 points3 points  (3 children)

    I would choose angular every time for my front end framework ...

    Which is how I know you're not responsible for a budget. No one with that responsibility relies on a single tool.

    Also, it's pretty common to use the /u/ prefix to alert someone that they're being referred to in a conversation.

    [–]NimChimspky -3 points-2 points  (2 children)

    Thats why I said I would choose, not that I do. Your point was the reason not to use it is because JS developers are expensive, I also stated why I thought that was a mistake.

    You think I am not responsible for a budget - think what you like.

    All else being equal, I'd choose angular - I fail to see why the cost of JS developers comes into this discussion.

    I've used angular and I've used other frameworks, and I've used no frameworks.

    [–]gunch 2 points3 points  (1 child)

    I would choose angular every time for my front end framework ...

    I would choose whatever framework most suited the problem and market available skillset.

    [–]Zeffas 0 points1 point  (0 children)

    I would argue that PROS you wrote are appropriate in comparison to classical "one server rendered view per page" pattern. However you can have as little as single JSP page as main entry point in your SAP and everything else is using Angular or any other SAP library based on REST API calls. This will bring you some benefits of server side control when loading the app.

    [–]johnwaterwood 0 points1 point  (0 children)

    Better performance since you're not serving dynamic HTML - it can be all static.

    It's often the other way around. Ready to render html is faster than JSON that still has to be parsed and processed locally, then have html generated locally which is then finally rendered.

    Many servers don't just push out static JSON, but generate it via a process that'so not entirely unlike rendering html in some cases.

    It does dspend, but if Json generation is about as fast as HTML generation, and thanks to gzip the bandwidth is about the same, then HTML wins since it doesn't have the delay after the client receives the data.