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?
Take a look at the talk where the concepts behind React are introduced: https://www.youtube.com/watch?v=x7cQ3mrcKaY It turns out there is no good reason to separate code and templates, because they are intrisically linked; one cannot work without the other. The separation should rather happen on units that are really independent, such as 2 separate pages of your application.
Things every React.js beginner should know
51–60 of 247 posts
Re: Things every React.js beginner should know
#52I'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?
These days everyone seems to think they need an application style site, and whilst some sites really do benefit from this approach, others don't.
The trinity of web standards (html/js/css) are still valid for informational, mostly static web pages, but are impractical for developing applications.
The discussion of what is a web application is a tricky one to put a finger on, with a lot of grey area. I think of a classic web page being the about us page of a website, while an application is something like photoshop. In between you have things like twitter, or gmail, amazon, facebook etc.
Re: Things every React.js beginner should know
#53I'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?
Re: Things every React.js beginner should know
#54I'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 mean it doesn't get any more straightforward than this.
{{ message }}
new Vue({ el: '#app', data: { message: 'Hello Vue.js!' } })
Re: Things every React.js beginner should know
#55Earlier quoted context omitted.
This is one of the main reasons why I've become so skeptical about best practice advice, especially if it doesn't come with a plain logical explanation for the reasoning behind it. Its similar to the problems with outdated laws - if we don't keep track of the reasons why a law came into use in the first place, we might miss the moment where it might not apply anymore (we wont even know, really) While I'm not entirely…
Actually, the issue with spaghetti PHP is not (only) string concatenation; it's mostly that view logic, domain/business logic and database boilerplate code are intermixed in a single file. React components only ever contain view logic, which already solves a part of the problem. Furthermore, you typically split that logic into multiple components, many of which are stateless, independent and small.
Re: Things every React.js beginner should know
#56I'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?
Isn't that because it's really JSX? https://facebook.github.io/react/docs/jsx-in-depth.html [NB Not that I know, just checking my own understanding].
JSX is a JavaScript syntax extension that looks similar to XML.
Don't we all hate XML? How can you possibly even go on reading about this technology further if it's introduced like that.Re: Things every React.js beginner should know
#57I'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?
A lot of recent trends feel like going backwards to grumpy-me as well. Microservices being preached basically the same way SOA was (and falling on every single pitfall again), languages where copypasta and mutable state are "the idiomatic way", HTML inside js code. Granted, not all recent developments are bad, of course - eg compiled & typed languages being back in "fashion" is a good development imho. It just feels…
Re: Things every React.js beginner should know
#58Earlier quoted context omitted.
Actually, the issue with spaghetti PHP is not (only) string concatenation; it's mostly that view logic, domain/business logic and database boilerplate code are intermixed in a single file. React components only ever contain view logic, which already solves a part of the problem. Furthermore, you typically split that logic into multiple components, many of which are stateless, independent and small.
In all fairness this is ancient history on the PHP world.
Apart from here it is again...
Re: Things every React.js beginner should know
#59#3 Write functional components I'd say "Write functional components where it makes sense". For simple components that is a reasonable advise, however in cases when you need such methods as `componentDidUpdate` or generally any lifecycle methods - that won't do and you have to use classes.
Re: Things every React.js beginner should know
#60Earlier quoted context omitted.
This is one of the main reasons why I've become so skeptical about best practice advice, especially if it doesn't come with a plain logical explanation for the reasoning behind it. Its similar to the problems with outdated laws - if we don't keep track of the reasons why a law came into use in the first place, we might miss the moment where it might not apply anymore (we wont even know, really) While I'm not entirely…
The big reason I remember from my PHP days (late 90s early 2000s) is that you want to separate design from development. Graphic designers were expected to know HTML/CSS while developers focus on PHP.