Hacker News new | ask | show | jobs
by EugeneOZ 4055 days ago
There is a lot of good and even awesome things in ReactJS universe, except JSX. Thousands of developers took their lessons in PHP/Perl/Python about mixing logic and representation, and now in nightmares they will generate HTML from logic, especially by parts and in worst case - using conditional cases. Everybody who tried to change design of website, written using something like "if ($birthday) $html .= getBirthdayButton()", will understand me.

Maybe JS developers should go through it, through this circle of hell, to avoid it in future, so JSX is necessary evil.

//despite of that, I sincerely thankful for people behind React, for their new ideas and how they changed fields of JS frameworks and mobile apps. Big respect!

4 comments

You might be confusing programming languages with concepts.

Don't think of React as "a container for logic and a system for doing views". Think of it solely as view logic.

It's not mixing views with program logic. It's only view. There's nothing to mix. It just happens --- wonderfully --- to use a real programming language to represent those views.

The notions of logic, controllers, models, storage, and all that jazz are why there's also Flux (or Backbone or whatever else it is you want to use; we use Flummox, it's fine).

You might be confusing "logic" and "business logic" terms, I talk about "logic" exactly. Any logic and conditional cases makes design very difficult to change, because you can't anymore just move one piece of HTML (tags) to another place, or replace all classes with ctrl+f - it becomes very complicated with logic used to build it.
In practice, it is extraordinarily easy to move a React component from one place in the UI to another, most especially if you're using Flux, so that components are decoupled.

That's been one of my favorite things about working with React: it actually works to design bottom-up, factoring low-level components out and then moving them around like cutouts.

I could not do things like that in Knockout, or, god forbid, Mustache and server-side templates; not without changing the application logic to account for the move.

Components are made for code reuse - of course it should be easy to move them :) They are encapsulated.
I get the feeling that you're just arguing for the sake of arguing. You can't in one comment say that it's hard to move things around and then in the other comment say that of course it's not hard to move things around.
Maybe if you will read my comments more closely you will see the difference between moving parts of HTML inside component and moving components. "Moving things around" is too broad term.
This is the first thing every dev says when he/she first discovers React.

Logic and representation are not two unrelated pieces to keep them separate.

If you don't know yet reasons to keep them separate, please google about it before arguing without arguments. For example, read about Separation of Concerns: http://en.wikipedia.org/wiki/Separation_of_concerns

//You can use "they" to replace "he/she".

Separation of concerns and separation of technologies are a different thing. It would appear you haven't done your research. See Pete Hunt's famous talk:

https://www.youtube.com/watch?v=x7cQ3mrcKaY

Hm.. I didn't say a word about separation of technologies. If you have one non-broken piece of HTML and related piece of JS to make it "live" - it's one thing. If you use JS/php/python/ruby/lua/whatever to generate HTML, composing it by small pieces into one (inside one component) - it's another thing and it's exactly what I'm talking about.
You are just throwing unrelated links around. Parent's point was that in this case, logic and representation are one and the same concern. What you're doing is similar to using SoC to defend having to split up class definitions into .h and .cpp files.
Don't put your words into my mouth with "allegories", I hate it. I don't talk about cpp and headers at all, I talk about view templates and view logic.
You are using your gut feeling, but that's not how React works at all.

JSX is not HTML, mixing logic/presentation is not a concern because you're not dividing your rendering between backend/frontend, and finally you don't even have to care about the final HTML representation of your component, it's just an implementation detail.

Finally, it's all declarative since you're never modifying a DOM tree - and declarative is a pre-requisite for good UI frameworks.

I use my years of experience, I don't need gut feeling for it. I really don't talk about backend, absolutely. While we have "createElement", we will use it with conditional cases and as result we will have mess of NOT-BUSINESS-logic and HTML code.
If you're using createElement you're doing it wrong.
I am playing around with React and if you want to keep it JSscripty (being the only dev who actually likes JS) or you want to use coffee script then createElement isn't actually horrible to use.

Especially not if you make an alias to ce or something like that.

if you want the best of both worlds, i use cjsx (https://github.com/jsdf/coffee-react) for my react components e.g. https://github.com/Azerothian/reacta-test/blob/master/react/...
Exactly! It's shortest version of what I think about JSX.
I thought JSX was just a cosmetic overlay to regular JavaScript functions. I'm not a react expert but I'm pretty sure `return <div>whatever</div>` just returns an object with a property of div and value of whatever. Exactly the same as writing `return React.DOM.div(null, whatever)` or whatever the vanilla version is.