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

231–240 of 247 posts

Re: Things every React.js beginner should know

#231

Post by lmm »

munro wrote: post #229
lmm wrote: post #217

Earlier quoted context omitted.

> Again, changing view to mean "template" is a strawman. Call it what you like. The point is that clear separation between logic and markup can be done and is valuable. > Separating state isn't the same as no state. Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go? > Also imperatively updating the UI on state changes is stateful. There's nothing imperative about it.…

> Call it what you like. The point is that clear separation between logic and markup can be done and is valuable. You concede the original point. To your new point, saying something is valuable doesn't make it valuable. Why? It decreases cohesion, which is not good. > Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go? If this is a serious question, it's too far off a…

> You concede the original point.

No. Your original claim was that you need to mix logic and layout. You don't.

> If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions.

It's not me who needs to learn what those words mean. Either you're just trolling, you don't understand the terms, or you don't understand wicket.

Re: Things every React.js beginner should know

#232

Post by EvanPlaice »

Guillaume86 wrote: post #68
EvanPlaice wrote: post #36

Earlier quoted context omitted.

JSX is a HTML-like template language that gets preprocessed to actual HTML.

No it's not getting preprocessed to actual HTML in React. Depending on the transform function, it can be turned to an object tree or a function calls tree (like in React) or actually HTML like you said but it's not a common use case AFAIK. It's not a text templating language like classic PHP, it's an object/function calls hierarchy DSL (more like vb.net XML literals). I think most people critisizing react for putting…

Right. I was aiming for the 'simple' answer but should have said DOM instead of HTML.

I'm also thinking in more of an Angular2 context as that's what I'm most familiar with.

Re: Things every React.js beginner should know

#233

Post by overcast »

grumblestumble wrote: post #198
overcast wrote: post #54

Earlier quoted context omitted.

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',…

if there's a meaningful semantic difference between what you just posted and Angular's 1.5 component syntax, I'm missing it.

http://vuejs.org/guide/comparison.html

Re: Things every React.js beginner should know

#234

Post by draw_down »

marknutter wrote: post #175

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or…

If you're a "just get shit done" person, fine, go use a framework. I've just been burned too many times.

It's not about complexity per se, it's about use cases the framework designers did not envision beforehand. Soon as you're in one of those, your goose is cooked. If the framework just does what you want and gets out of the way then great. But in my experience the pain is not worth whatever benefit a framework provides.

Re: Things every React.js beginner should know

#235

Post by munro »

lmm wrote: post #231
munro wrote: post #229

Earlier quoted context omitted.

> Call it what you like. The point is that clear separation between logic and markup can be done and is valuable. You concede the original point. To your new point, saying something is valuable doesn't make it valuable. Why? It decreases cohesion, which is not good. > Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go? If this is a serious question, it's too far off a…

> You concede the original point. No. Your original claim was that you need to mix logic and layout. You don't. > If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions. It's not me who needs to learn what those words mean. Either you'…

If you disagree with something I said, please disagree with it directly with reasoning, without name calling, ad hominem, or strawmans, at the exact thread. If I use terms incorrectly, correct me, and better yet, give an ironman of what I was trying to say.

Re: Things every React.js beginner should know

#236

Post by lmm »

munro wrote: post #235
lmm wrote: post #231

Earlier quoted context omitted.

> You concede the original point. No. Your original claim was that you need to mix logic and layout. You don't. > If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions. It's not me who needs to learn what those words mean. Either you'…

If you disagree with something I said, please disagree with it directly with reasoning, without name calling, ad hominem, or strawmans, at the exact thread. If I use terms incorrectly, correct me, and better yet, give an ironman of what I was trying to say.

To the extent that react is "stateless" (which I don't consider an accurate or useful term, because UI is inherently stateful - the meaningful distinction is whether state is managed or pervasive) so too is Wicket. That is to say, you declare what your UI looks like as a function of the model values. There is no "imperatively updating" and no increased complexity.

Re: Things every React.js beginner should know

#237

Post by jjnoakes »

adamors wrote: post #150
jjnoakes wrote: post #124

Earlier quoted context omitted.

This is simply not true. Ignoring the fact that "real application on the web" has no definition... very useful web pages can be created without JavaScript, and they can (quite easily) interact with the user by taking input and updating what they display. Why is something like that useful? Accessibility, security, backward compatibility, ...

Yes that's why they specifically said web applications not pages. You cannot create web application without JS.

Sure you can. As I explained above.

Re: Things every React.js beginner should know

#238

Post by droidist2 »

seivan wrote: post #220
marknutter wrote: post #175

So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or…

Exactly the reason I love Rails, even though I'm not a fan of Ruby. Choice paralysis or https://en.wikipedia.org/wiki/Analysis_paralysis It's really severe, but articles from DHH and Rails itself really really help with that. I can't really put enough emphasis how greatly that has helped me.

Sounds like you'd like Ember then.

Re: Things every React.js beginner should know

#239

Post by droidist2 »

vdnkh wrote: post #12
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'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.

I agree. It's humorous how technology people can be so dogmatic and closed-minded to change.

Re: Things every React.js beginner should know

#240

Post by meric »

marknutter wrote: post #183
Retozi wrote: post #179

Earlier quoted context omitted.

I agree with your argument. I have seen people say on HN that 1 hour of setup to start a project is too much. If this is the case, React + stuff is really not the right thing for you. However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React. Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does…

> Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux. Quite easy for whom, exactly?

I see it as a set of web framework construction tools. You can roll your own isomorphic web framework in two weeks, whereas ember.js and angular.js took years to build.

We build the framework that's suitable for our company. Once we got a thing going we use it for multiple projects.

Post reply on HN