Hacker News Reader

Comment by jawns | Hacker News Reader

I recently worked on my first React project, after working with Angular code for a while. I'm willing to accept that as an app gets more complex, React/Flux really pays off. But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React. When you want to get a 10,000-foot-view of how it all comes together, you can (generally) do that in the code in Angular, but you're better off doing it in the browser with React. Which may not be bad, but it's a difference worth mentioning.

View on HN

To each their own, I guess. I think that any template that's more than 4-5 lines (not including closing tags) is generally a mess and can benefit from being split into more components. AKA the single responsibility principle.

Structuring a program with a large number of small components is very awkward when templates and code are in separate files.

As far as that 1000 foot view, a nice tree view of React components is vastly superior to a wall of text cluttered up by meaningless implementation details like "div".

> Structuring a program with a large number of small components is very awkward when templates and code are in separate files.

I agree. We've developed a fairly complex Ember application, and the component hierarchy feels cluttered with everything separated by component and template. E.g. I have /my-component/component and /my-component/template instead of just my-component.js. Its funny coming full circle in MVC apps, but I find myself frustrated writing 1-5 line templates -- that I have to import. Why can't I just put it in the same file as the component, and have one file? Subjective to be sure, but I'd much prefer React style components in our project.

Check out this addon: https://github.com/pangratz/ember-cli-htmlbars-inline-precom...

We've started using it for inline templates in tests, but it should work just great with inline templates for components.

The pods convention you described definitely helps though.

You should look at ember pods - it's already built into ember-cli. It basically organizes your project's folder structures live you've described. All 'posts' related items go into a posts folder - its routes, components, templates, controllers, etc.

Because you're still tied to thinking in terms of master templates and interpolating strings - maybe because of how designs are handed off to you?

The smallest unit in UI design is a component, and React maps well to that, allowing you to treat components as functions (you can compose, specialize). You'll realize the power of that once you work with real UI designers who understand designing from inside-out as opposed to dumping a PSD mock of the entire page.

> But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React

I'm not sure what you mean. There's nothing in React that would prevent you from making your pages just one huge component. You can split the code any way you like.

That's true. But React is generally associated with the Flux architecture pattern, which emphasizes small, modular, mostly stateless components.

There is a reason for that and it is because it makes for simpler code. Simpler code is easier to test and simple tested code should have less bugs. Also you get the advantage of reusability from all of the small components you build. If you don't want to follow the recommended programming practices, you don't have to but I would like to encurrage you to adopt them because they really are helpful.

I want to +1 the "makes for simpler code." I'm working on a side project in my free time on nights and weekends. I find the simplicity of React makes it very easy to jump back in after not working on it for a week, or when coding while I'm tired. Working with simple components allows me to constantly move forward, even if it's only for 30 minutes or an hour a night

Agreed - I also found React a bit clunky with the explicit getters/setters compared to Angular.

JSX is a bit of a weakness IMO - I absolutely rather have templates in separate files to reduce complexity/concerns located in a file. It also adds build tool complexity, which there is too much of in frontend currently.

Otherwise, working in React is generally clean, but one can get that benefit by utilizing ES6 modules in general. React brings a lot of good things to the table, which is probably best exemplified by Angular 2 pulling a lot of ideas from it.

Who's stopping you from putting your jsx in a seperate file?

Build tool complexity is what I dislike - it's certainly possible, but the trend I dislike is build tooling increasing complexity of the build system of the frontend, decreasing accessibility for onboarding developers. JSX is an unnecessary offender in this department, bringing us farther away from plain HTML.

Have you seen Webpack (https://webpack.github.io/)? It's a very powerful tool, but it's quite simple to start with. I can recommend this tutorial: https://webpack.github.io/

Ha, I just realized I posted the same link twice. This is the link to the tutorial: https://github.com/petehunt/webpack-howto

Why use JSX at all, then?

    var d = React.DOM;
    d.div(null, 'Hello', d.strong(null, 'World'))

> But there's something to be said for having a single template file for a single page in Angular, versus having JSX scattered among 20+ components for that same single page in React.

Good point; How does one view the resulting react-page anyway? CTRL+U shows <body><script.../></body> no matter what state the SPA is in..

In Chrome, there's a cool React dev tools extension that shows you the React components.

https://chrome.google.com/webstore/detail/react-developer-to...

That's actually better than looking at the HTML output, unless you're debugging something really weird. With React you should treat HTML as an implementation detail and work in terms of component trees.

There's a React Dev Tools plugin for Chrome that will show a tree of components instead of the DOM.

You want to look at the DOM structure of the page as it exists in the loaded page and have I got a treat for you! Figure out how to open the web inspector for your browser; the keyboard shortcuts are ctrl-shift-I or cmd-shift-I or cmd-opt-I on a few (platform, browser) pairs.

(This will show you the actual DOM, not the React components... but since you were talking about 'view-source', this might help you too.)

Thanks, that's what I've been looking for!

You're welcome!

Using the web inspector has been such a massive and continuous boost to my learning/work with webpages and I'm extremely glad to share it with someone it might help.

Or hit F12, works in every browser and platform as long as the key is present.

Between Firefox, Chrome, and Safari on OSX, it only does anything in Firefox (toggles Firebug).

The new Glimmer engine in Ember.js gives you React-like DOM diffing without the use of JSX, and baked into a very organized and easy to grasp framework to boot.

Ember might be well organized and a great framework but I'm not sure I agree with "easy to grasp". There is so much automagic that when something tries to deviate from the common Ember patterns I worry that you are going to have a bad time. I say that having hardly used Ember outside of the intro tutorials so please someone correct me if I am wrong.

While I like the tooling around Ember, I don't know how much I actually like Ember itself. I mean, there are routers, controllers, templates, views, and components. How many different concepts do you need?

Getting the 10k feet view in React is a problem I've head as well. I usually use the the react google chrome extension to help me out with that.

If you use react-router (port of ember's router), you get a view of the components on the page for each route. Then you can drill down into your component of interest.

Reply on news.ycombinator.com