Comment by skrebbel | Hacker News Reader

Comment by skrebbel | Hacker News Reader

Parent Full thread

(Marginally related rant)

I love React, but so far I've been a bit underwhelmed by the ecosystem of components that has sprung up. I hope that this site will help.

A lot of the components are stuff that aren't really UI elements, but rather add magic to other UI elements or even do something completely unrelated to the UI.

I mean, I've seen routers written as React components![1] Wtf? Why is it an advantage to express a route as XML-like JSX? Why put it in a virtual DOM? That's just waiting for unexpected side-effects to happen. I can imagine that a lean, to-the-point router is a good combination with React but components are for UI widgets, not for configuration.

I feel like this is the same mistake as the everything-in-XML hype of the early 21st century (Spring, anyone?), or the everything-as-a-DSL hype in early Scala (with clear, descriptive operators such as ~~=, $%% and of course &^), or the current hype in C#-o-world to package web assets into NuGet packages (jquery.dll - seriously?). Just because you can put it in a component, doesn't mean that you should.

Behavioral features for components (e.g. infinite-scrolling or tooltip triggers) are well distributed as a mixin. Stuff not directly related to UI widgets should just be vanilla JavaScript. Asset libraries should be asset libraries.

What I expect from open source components is UI elements. Color pickers, fancy dropdown selects, login widgets, form elements with pluggable validation maybe (but the validation logic shouldn't be components). Notably, I'd love an ecosystem of UI frameworks ala Bootstrap or Foundation to spring up around React, and it appears that this is happening.

(Sidenote, if there's one development we do need, then it's a clear React-authors-condoned way to couple (parameterized) CSS with React components, so that we can really distribute self-contained components including style. A development like that would also help focus the React component ecosystem on what it should be about: UI widgets.)

[1] Random example: https://github.com/rackt/react-router#whats-it-look-like - seriously, what were they thinking?

Maybe take a look at the source code for the router component you're so offended by.

https://github.com/rackt/react-router/blob/master/modules/co...

It doesn't generate any markup itself, but instead renders the component bound to the route. This is a perfectly valid way to communicate how routes are related to components.

I'm assuming the React core team liked the approach as well, considering they featured it in one of their community round-up blog posts:

http://facebook.github.io/react/blog/2014/08/03/community-ro...

We can agree to disagree right? I think using JSX and React components for configuration is a bad match, and plain JS is a much better and more flexible fit. I also suspect that it is a result of eagerness to use the newly-learned hammer for every nail out there, which is a rather common phenomenon when new technologies quickly rise in popularity.

You, on the other hand, think it's neat. That's fine.

I don't see how the router's source code is related to this discussion, though. I implied nowhere that that particular router did something bad with rendering markup or something, I'm not sure where you got that from. I'm talking about the API.

Just want to say I fully agree with you. react-router seems like a useful library, but I see utterly no reason why you should write your routes in JSX instead of as a simple JS object. Using JSX for anything other than DOM insertion or modification creates an impedance mismatch. The public API makes no real sense to me.

The point of JSX is to more easily build dynamic HTML (and perhaps other markup).

If you read the overview you may understand our opinion that "application state" is precisely which views to render.

https://github.com/rackt/react-router/blob/master/docs/guide...

We're almost done with serializing the application data as well. Both pieces are important.

Then use them as JavaScript functions, because that's what they are :)

The point of JSX is to express attributes and hierarchy, which matches with our route configs perfectly.

> We can agree to disagree right?

It's not really agreeing to disagree when you're openly mocking the idea across multiple paragraphs.

Your idea of "mocking" strikes me as rather sensitive. I criticized it. I feel like you're telling me that we're not allowed to criticize technical developments on HN and that bothers me.

It might just be a cultural divide though. I keep underestimating at how much flower dressing and icing on the cake Americans need in order to be able to deal with criticism. Conversely, you (I'm blatantly assuming you're American) probably think I'm unnecessarily rude.

The rationale for using JSX over plain JS is given here - http://facebook.github.io/jsx/

It's not a case of "new hammer", it's being used there for the exact reason JSX was invented - "defining tree structures with attributes" in a standard way since "A generic but well defined syntax enables a community of independent parsers and syntax highlighters to conform to a single specification."

> The rationale for using JSX over plain JS is given here

Are you pulling my leg or did you simply not read any of the two comments I wrote?

My first comment even contained last decade's hype to do "everything in XML" as an example of a similar (bad) movement. Your response is to link to an article that describes JSX as an "XML-like syntax extension to JavaScript".

I say "don't do everything in JSX just because you can", and your response is "but it's like XML!". I can only deduct that you also like programming in XML. Good for you, I recommend you begin with porting XSLT to JSX.

That sounds like a delicious practical joke.

No. You didn't say those words that you quoted. You're ranting and raving like a lunatic, so maybe you should just take a minute to think about that.

XML is not being used "because they can". First of all - they couldn't use XML inline, which is the reason they invented JSX. Then they could. So, they actually went out of their way to use XML.

I didn't link to the article so that you could get a description of JSX, you rude jerk. I linked so you could get the reasoning. Unfortunately, you're being a complete asshole so just like, never-mind I guess. Have a nice day! :)

(Oh and - You haven't given one valid reason why you think it's a bad idea. Just rubbish appeals to authority. Your rant contains no logic. What's your reasoning? You asked "Why is it an advantage to express a route as XML-like JSX?" and the answer is in the rationale given on the JSX spec page. There are 1,000 ways to put together a JS object. There is one way to put together XML. It's a better, simpler standard that lends itself to better tooling and simpler parsers that don't need to parse the entire JS language.)

Your response is way ruder then the OP's, way to escalate the situation ...

I don't see how it's hard to understand how using a syntax that was designed for rendering UI components for routing might be a bad idea. It's just screams ugly hack all over the place and I could easily see how it would be confusing and overly verbose.

XML syntax was not invented for rendering UI components.

I'm completely favor of non-UI components but that's not how a client-side router should work. What I mean is tying a particular route to a particular UI component is the wrong way to go. Instead the route should be tied to the application state itself, and application state should be what drives UI.

We've almost tied all the knots we need to meet this requirement of a router.

Every application has UI nesting at the core of its state, though.

The UI is a reflection of the state. UI nesting is not part of the state itself. The route is just a serialized representation of the state.

Yes, this seems like a much better approach. I mean, creating components based on path state is completely trivial, once you have state driven by a router, and lets you be explicit about how state is moving around. react-router seems to be taking a more covention over configuration approach (this.props.activeRouteHandler? Really? Why does the top level routing need to specify the deeply nested components? What if there are multiple components in the interface that depend on the route? etc. etc.).

If it isn't generating markup then why is it a React component at all?

As someone who is using react-router, there are some good reasons for it: it provides a nice way for the current state of the router (eg. the active route and the state that represents) to fit into React's re-rendering on updates. Existing off-the-shelf routers don't tend to cover this case (re-rendering from state without re-executing the route), so I wrote a layer on top of Backbone.Router to integrate the two, but react-router means one less thing to maintain, and it also has handy transition hooks (modelled on Ember.Router).

As for the use of JSX specifically, it's handy because it allows expressing ordered associative data, for which in javascript the other choices are both kind of messy: either an array of objects (verbose) or an object (not guaranteed to be ordered).

> object (not guaranteed to be ordered)

This is true as per the ECMAScript spec, but realistically you can count on it (unless your keys are stringified numbers). On the server side of things, this is explicitly depended on in a number of places - the most visible that I know of is Mongo's REPL and its node.js drivers (specifying complex sorting/indexing depends on the objects being ordered).

The router and some other components are not only plain react ui components, they try to implement a Flux-Architecture with real components. Flux: http://facebook.github.io/react/docs/flux-overview.html

A better approach (IMHO) is Fluxxor http://fluxxor.com/

And the benefit of the react router is, that you don't have to concern about the render / re-render.

With express you have to do everything by your own.

I think we must difference between Browser - Application Routing and Application - Component - Routing.

Have you checked out react-bootstrap? http://react-bootstrap.github.io/ . Here's a little write-up I've suggested to explain the project: https://syllog1sm.github.io/introduction.html

I'm not really a front-end person, but when I first saw React it was the first thing I wanted, so I did a bit of work on the idea. A big group of people have now almost finished it.

Thanks for starting this. It's currently making my life much easier.

Your second link does not work. Would be interesting.

Damn. Thanks.

https://syllog1sm.github.io/react-bootstrap/introduction.htm...

Can't seem to edit my comment...

Thanks!

I'm one of the authors of react router.

How do you feel about <script/> tags, or <link/> or <meta/> or <base/>?

Like something we're forced to use, but in all honesty I don't completely see where you're getting at.

Note, I now regret singling out react-router. I'm still learning that on places like HN, it's best to avoid giving examples when discussing software design in abstract terms, because you're needlessly singling out some good people (in this case, you), plus half the discussion becomes a nitpick about the example instead of a discussion about design principles.

I do actually believe that react-router is a bad fit for JSX, let alone React components, but I also think that others are allowed to disagree. The best I can do is try and encourage careful thought when considering JSX, which is what I wrote my comment for, but if people disagree with me on exactly where to draw the line, then that's not really a problem is it?

I hardly have any open source to show for, so you're already way ahead of me, and in the few things I do have on Github, I bet that you'd disagree with some design decisions I made as well.

Sorry for dragging you into this. Open source is unrewarding work and I surely didn't help.

What about http://react-bootstrap.github.io/ ?

Reply on news.ycombinator.com