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

201–210 of 247 posts

Re: Things every React.js beginner should know

#201

Post by overgard »

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…

I don't know, I think you're over-characterizing this as a psychological decision. I tend to prefer libraries over frameworks for the simple reason that they're usually much quicker to learn and use (because they have a single purpose), and they don't box me into patterns I don't want or need. I wouldn't categorize that as like making me a control freak or untrusting of others design decisions, its a pretty pragmatic decision.

Re: Things every React.js beginner should know

#202

Post by paulddraper »

overgard wrote: post #201
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…

I don't know, I think you're over-characterizing this as a psychological decision. I tend to prefer libraries over frameworks for the simple reason that they're usually much quicker to learn and use (because they have a single purpose), and they don't box me into patterns I don't want or need. I wouldn't categorize that as like making me a control freak or untrusting of others design decisions, its a pretty pragmatic…

I think your reasoning falls squarely into the GP's description.

Re: Things every React.js beginner should know

#203

Post by unclebucknasty »

matt4077 wrote: post #79
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…

Good points. So, some people say, "hey, let's use a declarative language like XML." Problem is that you still need to decide what, when and how to display your model. So, we end up with tags or otherwise that are merely attempts to hide logic. . Yeah, right.

You can go the other way...just put the logic in the controller to format data and otherwise build the model in a way that is cognizant of the view. But, then you've just "polluted" the controller with the view.

One approach at solving this is frameworks like Wicket, which (in spite of shortcomings) encourages the use of view components in a way that allows them to render a more organic model. Yes, you may write some Java to render specialized components, but you're at least using the same language and being specific about writing rendering code that is also reusable.

Re: Things every React.js beginner should know

#204

Post by paulddraper »

aikah wrote: post #91
matt4077 wrote: post #79

Earlier quoted context omitted.

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…

> ... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning. then they wrote template languages on top of the template language to separate layout and logic again ( PHP vs Twig/Smarty ) so maybe we need to step back a little and figure out how to write a language that wouldn't need a different syntax for logic and layout. This family of languages exists…

Scala has inline XML support.

Not a good thing, IMO, since it makes the syntax way more complicated, but there you have it.

Re: Things every React.js beginner should know

#205

Post by munro »

escherize wrote: post #197
munro wrote: post #159

Earlier quoted context omitted.

I love Clojure, but I'm tired of embedded DSLs, they're a dime a dozen. You can argue the benefits of Hiccup's syntax & s-expr all day, but it's still a different, and unpopular syntax for describing HTML. The ability to copy snippets of HTML from web, or old code when refactoring, or from Clojure/Hiccup to another language & framework, or changes from developer tool, or familiarity for new engineers, or not having t…

So you _actually_ use function names as strings? That seems like a problem, and that it would need its own special editor tooling. Yikes.

    (defui my-component [x]
      Hello)
It's possible to macro the above to the code below, without any language extensions. IntelliJ has powerful nested DSL introspection, it would be neat if Cursive allowed to hook into this through defui's metadata for highlighting. I was a hater of JSX until I used it. Now I hate eDSLs. :D

    (defn my-component [x]
      [:h2 {:class (when (selected? x) ["selected"])} "Hello"])

Re: Things every React.js beginner should know

#206

Post by marknutter »

xiaoma wrote: post #199
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…

> next shiny new view-model library to ride the hype train. If widespread use in production by Facebook isn't real world enough for you, then perhaps it's best to find a slower-moving part of the stack.

It amazes me how much the software industry is like the fashion industry. Do you honestly base your technology decisions on what brand names are attached to them?

Re: Things every React.js beginner should know

#207

Post by matt4077 »

pekk wrote: post #119
aikah wrote: post #91

Earlier quoted context omitted.

> ... that then expand to be turing-complete and basically offer everything their primary language offered in the beginning. then they wrote template languages on top of the template language to separate layout and logic again ( PHP vs Twig/Smarty ) so maybe we need to step back a little and figure out how to write a language that wouldn't need a different syntax for logic and layout. This family of languages exists…

If you are trying to make a language that doesn't need a different syntax for logic and layout, do you not end up with a templating language similar to PHP? Is this the right goal?

Yes – look for example at the .erb templates that rails uses. It's still possible to do evil stuff in those, but I actually haven't seen it in practice. The whole framework is organized in such a way that people get where their logic belongs.

The worst I've seen is a bit of confusion between models and controllers. But views are usually as clean as the Gods of MVC commanded.

Re: Things every React.js beginner should know

#208

Post by marknutter »

daveidol wrote: post #196
marknutter wrote: post #182

Earlier quoted context omitted.

> You describe ES6 as some kind of exotic dependency. To the non Silicon Valley / Hacker News crowd, it certainly is. And using ES6 means you need to make a choice about which transpiler to use, which build tool to use, etc. > Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default. Well known to who, exactly? Because…

You're not wrong: things do change quickly in the JavaScript world. But have you actually been following this stuff very closely? "Flux" was never a "well-known default," because there was no single "Flux" library - only Facebook's little written guide and an implementation of the dispatcher (a small part of the overall Flux architecture). So, there were about 500 different implementations of "Flux" - none of which I…

> But have you actually been following this stuff very closely?

I have, but I'm trying to spin my comments from the perspective of the average developer. People who are passively keeping tabs on what this whole "React" thing is about are probably feeling a little uneasy about all the churn. I agree that Redux has emerged as the clear solution for data management, and I'm a huge fan. But I don't use it with React. I'm keeping my distance from that ecosystem while the dust settles and waiting to see what kind of splash Angular 2 makes.

> Relay/Falcor are really part of an entirely different thing than React; they are about replacing the traditional REST API with an entirely new paradigm.

But what app doesn't use a traditional REST API? Why wouldn't people want to use the latest hotness to come out of Facebook™ or Netflix™? It's this kind of uncertainty that keeps people off balance.

Re: Things every React.js beginner should know

#209

Post by xiaoma »

marknutter wrote: post #206
xiaoma wrote: post #199

Earlier quoted context omitted.

> next shiny new view-model library to ride the hype train. If widespread use in production by Facebook isn't real world enough for you, then perhaps it's best to find a slower-moving part of the stack.

It amazes me how much the software industry is like the fashion industry. Do you honestly base your technology decisions on what brand names are attached to them?

It's not about brand name. It's about being proven in production use.

This is why Google's brand doesn't mean much in Angular's case (since most of their own products do not use Angular).

Re: Things every React.js beginner should know

#210

Post by overgard »

paulddraper wrote: post #202
overgard wrote: post #201

Earlier quoted context omitted.

I don't know, I think you're over-characterizing this as a psychological decision. I tend to prefer libraries over frameworks for the simple reason that they're usually much quicker to learn and use (because they have a single purpose), and they don't box me into patterns I don't want or need. I wouldn't categorize that as like making me a control freak or untrusting of others design decisions, its a pretty pragmatic…

I think your reasoning falls squarely into the GP's description.

I don't think that's really true. Not to put words in his mouth, but the GPs assertion seems to be that library vs framework tends to not matter much other than in what it says about the individual, whereas my assertion would be that choosing small focused libraries has nothing to do with ego or imposter syndrome or whatever, I just don't want to learn a massive chunk of code if I can learn a small chunk of code and get equal value.
Post reply on HN