Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things every React.js beginner should know

camjackson.net

Post reply on HN
Print view View original

71–80 of 247 posts

Re: Things every React.js beginner should know

#71

Post by Aleman360 »

douche wrote: post #44
Aleman360 wrote: post #37

Earlier quoted context omitted.

> After all in every native UI framework you have instructions to draw the widget IN your code -- not as some external additional technology. A widget's C/C++/Obj-C/Swift/Java/C# etc code encapsulates everything about creating it and showing it. With the notable exception of Windows. XAML strictly enforces code and markup separation. It makes the View layer more toolable and easier to edit by designers who usually do…

That is just inside of WPF-land, though. WinForms (which is still pretty excellent for quick-and-dirty GUIs) and other GUI frameworks are more on the classical model.

And UWP, which is the primary UI framework now.

Re: Things every React.js beginner should know

#72

Post by Guillaume86 »

pkrumins wrote: post #10

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?

Think of it like a little DSL that helps with declaring deep hierachies of objects or function calls nothing more.

Re: Things every React.js beginner should know

#73

Post by mcv »

untog wrote: post #69
pkrumins wrote: post #10

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.

In Angular separating logic and html works fine. The only type of component that should be dealing with html in the first place, are directives. Directives point to a piece of html to include, which can be either a string or a url. In the case of the url, the code is separate.

But more important is the separation between the directive and the rest of the code. The directive is specifically about the logic that's directly related to the view. That's not something you want to put too far away from the view.

And of course Angular's html is enriched html: by including directive, you can put databinding, and limited logic (generally about when you show that bit of html) directly into the html. Separating those would be frustrating and a bad idea. If your view is dynamic, that logic should be considered part of the view.

Re: Things every React.js beginner should know

#74

Post by idibidiart »

pkrumins wrote: post #10

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 all "View Code" so separating HTML/JSX from "view" JS (as opposed to separating HTML/JSX from "logic JS" in handlers/reducers/etc which is a legitimate abstraction) is very superficial abstraction and gets in the way of comprehension. But if your brain refuses to parse HTML in JS then you can always specify the DOM fragments as JSON in your render() function.

The thing that I don't agree with about the blog post is the inclusion of State in the main App props in the form of maxSomething (forgot already the prop name) App configuration should be gathered in one place as a set of constants, IMO. App state should only contain the data, not the meta.

Re: Things every React.js beginner should know

#75

Post by untog »

mcv wrote: post #73
untog wrote: post #69

Earlier quoted context omitted.

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.

In Angular separating logic and html works fine. The only type of component that should be dealing with html in the first place, are directives. Directives point to a piece of html to include, which can be either a string or a url. In the case of the url, the code is separate. But more important is the separation between the directive and the rest of the code. The directive is specifically about the logic that's dire…

In Angular separating logic and html works fine

And of course Angular's html is enriched html: by including directive, you can put databinding, and limited logic

Either it's logicless or it isn't, surely. To me, databinding is absolutely the kind of logic that shouldn't belong in a template in the world of strict code/template separation. Another reason why it doesn't really work.

Re: Things every React.js beginner should know

#76

Post by ojr »

pkrumins wrote: post #10

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?

Is it really HTML or directive/component definition syntax

This is not traditional HTML from the early days and because it is not it has a higher chance of reuse outside of just an internet webpage, and makes it easier to transfer across other view layers, canvas, native desktop/mobile views, etc

Re: Things every React.js beginner should know

#77

Post by dsego »

pkrumins wrote: post #10

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?

That's why I really like Riot.js, looks much nicer and simpler.

Re: Things every React.js beginner should know

#79

Post by matt4077 »

pkrumins wrote: post #10

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?

This is a debate that has been going on since I started in the late 90ies.

You need some sort of logic in your views, no matter what system you use, i. e. loops or formatting dates.

Because people are raised on the "don't mix logic & layout" maxim, they feel dirty when they write sich logic in their usual language.

.. so they invent template languages...

... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning.

So you end up with a new language to learn, which is usually clunky and ugly just for the bragging rights of "not mixing logic & views". Which is completely stupid. Views can (and almost always need) to contain some logic and the best language for that is the one you're using everywhere else.

Re: Things every React.js beginner should know

#80

Post by andrewingram »

lukesan wrote: 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 to the client-side JavaScript payload).

Post reply on HN