Live data from Hacker News

Things every React.js beginner should know

camjackson.net

81–90 of 247 posts

Re: Things every React.js beginner should know

#81

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

For what it's worth, I think the maxim "different kinds of code should be on different places" is deeply wrong and perhaps the biggest current impediment to code quality in the web world.

The alternative view is "things that are tightly coupled should live together" which I think is generally a better maxim.

In theory views can be loosely coupled, but in practice they seem to be almost always coupled 1:1 with whatever layer is above them, controllers or view models or whatever.

Re: Things every React.js beginner should know

#82

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

Concepts should be separated. Layers should be separated. That's true for any application.

Separate HTML and JS? That's a small implementation detail. You can have your view layer as JSX files, separated from business logic, data access, etc. That's actually recommended.

Even when you are using purest HTML template engine, completely separated from JS logic, you still can make a mess, moving lots of logic into HTML or moving all your layers into a single JS file. File boundary is very artificial separation. It doesn't always help. And often it makes things worse, because you have to work around limitations.

Re: Things every React.js beginner should know

#83
post #78

What really bothers me about React (and other frameworks) that without JS you do not see anything. No fallback. No progressive enhancement. Is this really the way to go? Did JS replace HTML/CSS as the backbone of websites/applications ?

There are ways to render the output on the server, which helps search engines, first-page load times and Richard Stallman

Re: Things every React.js beginner should know

#84

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

Yes, it's one of things in ReactJS I don't like (inheritance is the second), but people like it. People tend to like what is easier to do, until they know bad consequences.

Re: Things every React.js beginner should know

#85

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

It's a squick factor issue. When you're trying to break down templates as small as possible, everything tends to become a bit icky in templating systems anyway. Consider -

    [% BLOCK foo %]
        [% payload %]
    [% END %]
    ...
    [% INCLUDE foo payload=something %]
in TT (perl's Template Toolkit, which I'm about 98% sure pkrumins is familiar with already), and then

    function foo ({ payload }) {
        { payload }
    }
    ...
    
Once you've got a bunch of them in the same file, I don't honestly find the JSX much different. The trick for me is to have the HTML in .js files that contain only pure functional rendering components - so when I'm editing those, I can think in HTML and just treat the JS as a slightly weird template syntax - at which point the squick factor mostly recedes.

Re: Things every React.js beginner should know

#86
post #12

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

I'm a fan of practicing "stateless development", where years of "thats what we've always done" has no bearing on what I'm doing now. Writing HTML in JS is much more pleasing than cramming JS into HTML via Angular.

This.

After working quite a bit with AngularJS, trying to read HTML with a ton of AngularJs is nearly impossible at times.

React is way easier to read and makes a lot more sense to my modular thinking about code. It also works naturally better for SEO compared to AngularJS.

Re: Things every React.js beginner should know

#87

Earlier quoted context omitted.

You're absolutely right - the power and benefits of libraries like Redux are so obvious once you've grokked React but as a beginner it really is just going to slow you down or just get in the way of learning. This is partly because of the overhead of having to learn another library, and partly because you have to learn by making mistakes, experiencing the pain, and then badly hand-implementing parts of Redux yourself…

Same goes for '8. Use JSX, ES6, Babel, Webpack, and NPM' - JSX aside, setting up this tool stack is totally unnecessary for a beginner getting started hacking on a Hello World app. While I agree with you in theory, in practice learning how to use Babel/JSX and probably es6 are pretty essential to react. All the tutorials are written using JSX which necessitates a transpiler. And a ton of the supporting libraries are…

Agreed - I did say JSX aside :-) JSX is coupled so tightly with React, and such a large part of React's offering, that learning React without JSX is probably actually going to slow down learning for the opposite reasons.

In general, ES6 is a prerequisite for developing anything in JS for any developer/project with a forward-looking mentality in 2016 - but I do have to disagree that knowing ES6 is essential for learning React. They're actually completely orthogonal at this point - it allows for cleaner code but doesn't buy you anything at all in terms of learning the React concepts.

As for getting started on the Babel toolchain - again it's orthogonal to learning React. The in-browser JSX transpiler is available. You can start learning react in a single page of html with script tags, just pulling all the libraries off cdns. There's just no need to have a tool chain at all, it is not essential.

I think it comes down to the definition of beginner. If you're taking a very experienced JS developer and starting them on a real world React project, by all means go in at the deep end - they'll likely know most of the toolchain anyway and they'll need it. If you're talking about just giving someone an intro to React and its concepts, you have to separate the core from the ecosystem.

My point was that we should recognise the difference, this is a common problem where experienced users tell beginners to 'just use' things that take months to become accustomed to in a few throwaway sentences, because to them it is just that easy. To a real beginner it represents a massive ramp, and that's not what you want when just trying to get an intro to a specific library.

Re: Things every React.js beginner should know

#88

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

When I first began delving into reactive client interface frameworks. This was one of my biggest gripes. It looks, and reads like a giant confusing mess. I finally came across http://vuejs.org/ and I haven't looked back. Simple binding syntax to html elements, and powerful enough for most projects without being heavyweight. I mean it doesn't get any more straightforward than this. {{ message }} new Vue({ el: '#app',…

Here we use https://www.jsviews.com/ in a similar way by having the templates in .jshtml files and calling them from the .js ... I wouldn't want to put the html directly in my .js files either!

Re: Things every React.js beginner should know

#89
post #78

What really bothers me about React (and other frameworks) that without JS you do not see anything. No fallback. No progressive enhancement. Is this really the way to go? Did JS replace HTML/CSS as the backbone of websites/applications ?

This isn't strictly true. Though the workflow isn't ideal yet, it's perfectly possible to build a React project which is initially rendered on the server and then progressively enhanced. I've done it before, as have others. In fact, my single biggest criteria for any tech I add to my stack is that it doesn't get in the way of server-side rendering (the second biggest criteria is that it doesn't add significant weight…

Sounds great. Do you know any good resources for building a react application by progressive enhancement?

Re: Things every React.js beginner should know

#90
post #69

I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?

I thought the same. Then I tried it. It does result in a tight coupling of template and code, but I'm yet to see a downside to that. Separating template and logic has been the dream forever but is never realised in any non-simple project. Embracing that coupling has been great for me.

I see "components" as a slightly different way of thinking, where you're building a cohesive unit. There'll be coupling between template and code, because they are by definition a single "thing." And they should be small in scope -- render a single bit of data, or have some other well-defined, small duty to perform.

Even in Angular, where we try to separate the template from its directive/controller, I don't think I've yet run into a case where I can just reuse a template with a different directive. And in fact, if I was about to do that, I should rethink my strategy (and probably just use the existing directive).

Post reply on HN