Anti-pattern? I dunno. This is one of the things that make React different: you define the whole UI in JS. JSX is just convenience. In fact when React was first released into the world at JSConf most everyone boo'ed because of this same concern you have. Since then people have come to appreciate it
I'll keep an open mind though.
Bear Bibeault wrote:... building up UI in strings in code is anathema to me...
Sure. Any string concatenation is a red flag
However JSX is not it. You cannot do
You can only go
(Which is not valid JS so you need a transform.)
But, as I said, this is optional. You can also not use any JSX and just use function calls to declare the components
Then compose and customize:
Using JSX makes this a little more readable..
Enrique M. Talavera wrote:Thanks for your reply, so with this tool it should be considered old-fashioned the old naked HTML? It looks like the creation of the DOM it's preferable to be used within the JSX code.
Yes, React takes over the trouble of you fiddling with the DOM. Which is nice because DOM creation/update is:
React fights the slowness by creating an internal representation of what you want the DOM to be (also known as "virtual DOM" and implemented as a simple JS object) than translating the virtual DOM to real DOM nodes using as little createElement/appendChild/etc as possible. Then when the data in the app changes, React figures out the diff between what you want the DOM to be, compared to what it was before, and then updates the DOM in the most efficient way possible.
You never really need to touch the DOM yourself, but you can, there's an "escape latch" that gives you the underlying DOM nodes if you need them.
The biggest benefit I see is that in the old-style DOM manipulation you end up hunting for DOM nodes to update all the time. Often most of your "onclick" handler is looking for nodes. jQuery helps reduce the verbosity of the hunt, but the hunt is still there. With React, the hunt is over. You just update the data (state, which is also just a JS object) and the UI is magically rebuilt
BTW, the idea of the virtual DOM is now well regarded, adopted in Angular 2, and many think should be part of the browsers' API
1) The first issue is from a development perspective. As a developer I don't like to do things in more than one place. It takes more time to duplicate effort plus it makes it more likely I will make a mistake. In JSP's I only had to render the data to one spot in the layout, one time server side. For example, if I wanted a first name to show up between some html tags I used a jstl tag to output it there in my html. However, with JSMVC patterns I have to do everything twice. For example, I first render my first name into a json object server side. This is the same amount of work as rendering it into the jsp was. Next, I have to put in my js tag in my html to unpack the value from the json client side. Not only do I have to match the field name, but I have to make sure it comes from the right model object etc. There is a lot more coordination that has to happen, and to beat I dead horse I had to code in two places.
2) My next issue is how fat the js stack has gotten on the client. These js engines are big collections of js, and we all know that js is harder to debug than a compiled language like java. Furthermore, as a developer, my whole controller is now sitting in js on the browser. Do I really want to maintain that much js code?
3) Another issue is security. Since my whole controller is on the browser, can't a hacker now see everywhere my application could potentially let him go, regardless of his user role? A hacker might not have access to a service call but he now knows its there whereas on a jsp based application he would not.
4) Internationalization is also a problem with JSMVC. In JSP the page was being rendered server side where a random access resource bundle was available. Even if for each language supported you had 4000 phrases (I've seen this first hand) when your bundle is sitting there in memory you have no performance problems picking phrases from it and rendering them into your layout. Imagine how this would work in a JSMVC application now. Are you going to download 4000 phrases every time the user logs in? Instead will you just download the subset of phrases for each page, yuck.
5) Controller remoteness is also a problem. Imagine the browser sends a post to the server and the browser is expecting a certain page back. However, logic in the controller based on state in the database decides that the browser should actually get a different page back then the one it was expecting. In a server based JSP pattern the controller simply does some db queries runs some logic and sends the browser a different page than it expected. Instead, what happens in Json JSMVC pattern? Instead of returning the json the browser expected does it send back a redirect command? Now the controller on the browser has to go to another page, so two trips to the server are involved instead of one and not simple ones. All of this complication happens because the controller is remote from the database. The controller is no longer central and this is a paradox in any command system. The controller on the browser does not have access to all of the information it needs to make decisions, whereas a controller on the server does! The controller on the browser only has access to data that has been previously delivered to it, which is a big limitation.