• Post Reply Bookmark Topic Watch Topic
  • New Topic

React: Up & Running Why is acceptable to include html inside js?

 
Enrique M. Talavera
Greenhorn
Posts: 23
Suse
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I was looking for some examples, BTW  I'm not a front-end developer, but I can see a lot of HTML inside js, why this is not an anti-pattern?
Best Regards
 
Stoyan Stefanov
author
Ranch Hand
Posts: 85
5
PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
it's not really HTML, it's called JSX, more like XML. It's a separate technology from React and is optional. In fact the first three chapters of the book don't even use JSX. You can define the interface in pure JavaScript. It's just much more convenient to use JSX. Plus designers are usually familiar with HTML and they can quickly become comfortable working on the UI using JSX.

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
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65524
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll admit that my uninformed initial reaction is also to boo and hiss. The thought of building up UI in strings in code is anathema to me. Perhaps too may years seeing badly written servlets creating HTML markup (badly) in code.



I'll keep an open mind though.
 
Enrique M. Talavera
Greenhorn
Posts: 23
Suse
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Best Regards
 
Stoyan Stefanov
author
Ranch Hand
Posts: 85
5
PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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..





 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65524
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting. So it's a DSL that transforms into native JS. Do you find this imposes an undue burden on run-time debugging?
 
Stoyan Stefanov
author
Ranch Hand
Posts: 85
5
PHP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
Best Regards


Yes, React takes over the trouble of you fiddling with the DOM. Which is nice because DOM creation/update is:
  • verbose
  • slow


  • 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
     
    Stoyan Stefanov
    author
    Ranch Hand
    Posts: 85
    5
    PHP
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Bear Bibeault wrote:Do you find this imposes an undue burden on run-time debugging?


    Not really, JSX transform preserves line #s, there are also source maps. Plus if you make a typo you figure out this immediately because the transform fails
     
    Bear Bibeault
    Author and ninkuma
    Marshal
    Posts: 65524
    105
    IntelliJ IDE Java jQuery Mac Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ah yes. Better a translation explosion than an obscure run-time (or even worse, silent) error.
     
    Stoyan Stefanov
    author
    Ranch Hand
    Posts: 85
    5
    PHP
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    exactly, fail soon, fail often, fail spectacularly
     
    Bear Bibeault
    Author and ninkuma
    Marshal
    Posts: 65524
    105
    IntelliJ IDE Java jQuery Mac Mac OS X
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
     
    Matt Keller
    Ranch Hand
    Posts: 32
    1
    Eclipse IDE Java jQuery
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    All of the new JSMVC type frameworks do this.  For example, in Angular you take your HTML and mark it up with js "tags" that look a lot like the way you marked up jsp html with tags.  Later when you deliver this code to the browser, the HTML is in fact wrapped up in the javascript.  At run time, the Angular engine matches these "js tags" to json models and then shows them in the page.  It sounds like a very heavy duty parser.  This pattern is very popular these days, but for me has some inherent issues. 

    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.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!