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

211–220 of 247 posts

Re: Things every React.js beginner should know

#211

Post by marknutter »

xiaoma wrote: post #209
marknutter wrote: post #206

Earlier quoted context omitted.

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).

Your comment strikes me as incredibly naive. Angular was written to tackle the task of re-writing the front-end of Double-Click, by far their most profitable application. Google is putting a ton of resources into Polymer, which is powering more and more of their mission critical properties, so Angular hasn't had the benefit of being blessed by the wider organization as the one, true way of doing things. I think that's a good thing, frankly. The group-think coming out of Facebook is unnerving to say the least.

You should step outside the Hacker News bubble and do a little research into just how widespread Angular usage is. You will find that it's staggering. Google's name means a lot, even if they haven't gone all in on using Angular for everything. Don't get me wrong, I think React is a fresh new take on web development, but when I see people say "because Facebook™" it makes me cringe, hard.

Re: Things every React.js beginner should know

#212

Post by EvanPlaice »

tlrobinson wrote: post #149
EvanPlaice wrote: post #35

Earlier quoted context omitted.

Why would you assume Typescript solves any speed issues? Typescript's type checking adds overhead just the same. So it's also a good idea to disable checks during runtime.

TypeScript doesn't do any runtime checks, AFAIK. In fact, that's one of their stated goals: "Impose no runtime overhead on emitted programs." https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

To-may-to, to-mah-to. That doesn't answer what I was asking.

Fact: type checking is disabled during runtime.

Why would one assume that Typescript somehow solves speed issues? It has no measurable impact on runtime performance.

Re: Things every React.js beginner should know

#213

Post by paulddraper »

overgard wrote: post #210
paulddraper wrote: post #202

Earlier quoted context omitted.

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…

"I tend to prefer libraries over frameworks...they don't box me into patterns I don't want or need"

You're confident that you're able to identify what you want and need, and how to get there.

You don't need help or strong direction.

In contrast, I worry about making the naive choice, and I trust that others have thought about this a lot more than me. So I tend towards things that have built-in best practices/assumptions/guidelines, i.e. "box me in".

Re: Things every React.js beginner should know

#214

Post by paulddraper »

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?

Software is (mostly) about function. Fashion isn't.

When something functions on massive scale, it's commendable, and worth looking at.

Re: Things every React.js beginner should know

#215

Post by tlrobinson »

EvanPlaice wrote: post #212
tlrobinson wrote: post #149

Earlier quoted context omitted.

TypeScript doesn't do any runtime checks, AFAIK. In fact, that's one of their stated goals: "Impose no runtime overhead on emitted programs." https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

To-may-to, to-mah-to. That doesn't answer what I was asking. Fact: type checking is disabled during runtime. Why would one assume that Typescript somehow solves speed issues? It has no measurable impact on runtime performance.

I was addressing the second part of your comment. TypeScript is a static type checker. It operates at compile time. There is nothing to "disable" at runtime.

But yes, regarding your original question, you are correct, aggressive optimization is a non-goal of TypeScript. It won't improve performance.

Re: Things every React.js beginner should know

#216

Post by robmcm »

jjnoakes wrote: post #121
robmcm wrote: post #64

Earlier quoted context omitted.

It is quite possible to develop semantic, content focused HTML and then at a later point style and re-style with CSS. It is only through laziness and lack of understanding that people couple them together.

Except this isn't about style. It's about logic. Logic isn't as optional as style, and if you separate the logic into one JS file and the DOM into another HTML file, they are still tied together by the JS binding some action to some named DOM element (by selector, etc). The separation that scales is the one that pairs a small piece of DOM (like a piece of text on the page that updates with the current stock price) to…

So this is where you enter a slippery slope from web page to application.

Developing a webpage and adding progressive enhancements to HTML elements is a strongly advised best practice with numerous advantages.

Developing an dynamic application at the complexity of say Photoshop it would be absurd to have a static HTML file with behavior decorated by JavaScript, or try and offer a fallback. Whilst you could in theory perform you photo editing with form submissions and round trips to the server I am not sure it would be worthwhile (I did actually create one circa 2004).

Re: Things every React.js beginner should know

#217

Post by lmm »

munro wrote: post #194
lmm wrote: post #184

Earlier quoted context omitted.

> With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user. There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template. > it sounds like one must imper…

> There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template. Again, changing view to mean "template" is a strawman. > Wicket clearly separates its state into models > You do have to declare which changes update which UI (for performance reasons), Separating state isn't the same as no…

> 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. Have you looked seriously at Wicket or are you just throwing buzzwords around?

Re: Things every React.js beginner should know

#218

Post by robmcm »

wanda wrote: post #139
robmcm wrote: post #52

Earlier quoted context omitted.

The early web days were spend developing basic web pages without any complex tools. 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 applic…

I think what qualifies a web application is the introduction of state and enabling the manipulation of data. Static sites, or dynamic websites without the state problem to the end user, are naturally better off without a client-side app approach (though ajax is still beneficial and structuring your approach to ajax can make client app frameworks/libraries tempting) However, when you start giving the user powers to ma…

> Hence why social networks and email clients are created as apps now

I think a large part of the definition of "application" is subjective, personally I think social networks, such as a forum or twitter suffer from being an "application". You want to benefit from SEO, fast loading, responsive design, accessibility etc. However a chat app, that's personal and contains ephemeral content is a much better candidate for an application. I expect to see a different setup from other users, I don't want it to be searched, I expect different experiences on different devices etc.

Another good example is tweetdeck vs twitter. One is very personal and customizable, the other is essentially a generic and universal between users.

I think we are entering a phase of "everything is a single page app" because it's interesting and exciting. Similarly to the early days of mobile of flash development. Hopefully in a few years there will be a renaissance of the simple webpage, and application frameworks will be reserved for the use cases they really make sense for.

Re: Things every React.js beginner should know

#219

Post by mcv »

untog wrote: post #75
mcv wrote: post #73

Earlier quoted context omitted.

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.

Not all logic is the same. There's logic of the type: "this is what we want to show, and we only want to show it if X is true", and there's logic of the type: "here's how we calculate it and that's all the complex stuff that X depends on".

If you refuse to put the former in your view, you're making your code a lot more complex for little gain. But if you put the latter in your view, you're making your view unreasonably complex and hard to read.

Neither extreme is good. You need separation of concerns, but some logic really does concern the view directly.

Re: Things every React.js beginner should know

#220

Post by seivan »

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.

Post reply on HN