Live data from Hacker News

Angular 2 versus React

medium.com

241–249 of 249 posts

Re: Angular 2 versus React

#241

Earlier quoted context omitted.

> This is the year of framework fatigue. This is the year of the framework fatigue meme. Next year is the year everyone realises why we had frameworks and tries to salvage the mess they made last year, when they wrote an app 'without a framework' and ended up with an under-specified, incomplete, undocumented, informal framework.

Maybe not. Maybe there is something else on the horizon. I actually think frameworks are too monolithic, and we feel the pain of that, but no one has figured out how to do something more granular yet. To a large extent that's a community administration problem, not a technical one, which is why you don't see a lot of computer scientists trying to do it. Though it will require some technical chops too. Node/NPM, and U…

What we really need is a web standard that allows devs to plug-in a custom templating language extension.

It's dumb that the browser renders HTML, a framework bootstraps, parses the template, then re-renders the view.

90% of the front-end frameworks exist to provide templating + some special set of features.

If we standardize a pre-render hook to plugin custom templating engines then frameworks can shift to focus only on their implementation specific strategies (ex data binding).

Re: Angular 2 versus React

#242

Earlier quoted context omitted.

> This is the year of framework fatigue. This is the year of the framework fatigue meme. Next year is the year everyone realises why we had frameworks and tries to salvage the mess they made last year, when they wrote an app 'without a framework' and ended up with an under-specified, incomplete, undocumented, informal framework.

another option: a lot gets pushed back to the backend rendering, where it started.

Ummm, no.

How about, everything shifts to isomorphic rendering. Generate an interactive view stub to display on the client while the app bootstraps.

There's no justifiable reason why we should have to refresh and completely re-render the page every time the view changes.

From a 'business perspective' it's worthwhile to have front-end devs build all of the view logic (incl templating, routing, etc) on the front-end while the back-end team focused solely on building APIs, microservices, and data management infrastructure.

If back-end devs are responsible for everything incl templating, the front-end devs responsibilities are limited to... Photoshop, HTML, and CSS?

Re: Angular 2 versus React

#243

React has a non-open license: https://github.com/facebook/react/blob/master/PATENTS , which basically says that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This is an automatic no-way for React for any major company

Yes... I'm really surprised that people aren't talking about this more seriously. They have removed the worst of it, but it still looks like it gives Facebook an advantage in any patent conflicts with any company that uses React, Immutable, Hack, HHVM, GraphQL, etc. anywhere in the dependencies. It appears that the PATENTS file claims that if Facebook infringes on your patents, you can't defend your patents without a…

Here is another large project (Drupal) that decided against React because of the PATENTS file: http://buytaert.net/selecting-a-client-side-framework-for-dr...

"The Virtual DOM, among React's most compelling features, has also seen its core ideas filter into other framework projects. But more importantly, React is licensed with what I believe to be a potentially unacceptable patent clause, which states that an organization can no longer use React once it sues Facebook for any (unrelated) patent infringement. This has already generated some concerted pushback from both WordPress's Calypso and React contributors."

Re: Angular 2 versus React

#244

Earlier quoted context omitted.

I've actually been considering trying Mithril. But it's not strictly parenthesis that bother me. You're right in that )]}) is actually far more annoying. I try not to nest that deep in JS if I can help it. Arrow functions reduce the pain. Not passing array literals in function calls helps as well. Angular seems like the big culprit that injects [] into the middle of an argument list, for me anyway, and using that syn…

Well, mithril requires a LOT of array literals and object literals in your function calls. http://mithril.js.org/getting-started.html shows todomvc in mithril. That template would be much more compact, uniform, and readable with a lispy syntax.

I see. You're right, that is somewhat ugly.

I've actually considered the idea of hacking a JSX compiler to spit out Mithril output.

If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.

Re: Angular 2 versus React

#245
post #239

Earlier quoted context omitted.

Hence: "cherry picked". You don't have to pick ALL the parts if you don't want. You can still compare a full framework and the 2-3 items you cherry picked though as methods of getting web apps done.

But then you're comparing "React + 2-3 items" vs. framework, not React vs. framework

So? Is that forbidden?

Who said those who use Angular will just use Angular only as it comes upstream and won't pick and/or substitute a few libs for third party ones either?

Re: Angular 2 versus React

#246

Earlier quoted context omitted.

Well, mithril requires a LOT of array literals and object literals in your function calls. http://mithril.js.org/getting-started.html shows todomvc in mithril. That template would be much more compact, uniform, and readable with a lispy syntax.

I see. You're right, that is somewhat ugly. I've actually considered the idea of hacking a JSX compiler to spit out Mithril output. If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.

That actually already exists: https://github.com/insin/msx

Re: Angular 2 versus React

#247

Earlier quoted context omitted.

Well, mithril requires a LOT of array literals and object literals in your function calls. http://mithril.js.org/getting-started.html shows todomvc in mithril. That template would be much more compact, uniform, and readable with a lispy syntax.

I see. You're right, that is somewhat ugly. I've actually considered the idea of hacking a JSX compiler to spit out Mithril output. If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.

Lisp syntax and idioms make mixing markup with code really elegant and simple. That's why I want to write mithril with lisp syntax.

Re: Angular 2 versus React

#248
post #246

Earlier quoted context omitted.

I see. You're right, that is somewhat ugly. I've actually considered the idea of hacking a JSX compiler to spit out Mithril output. If you're going to mix mark-up in your JavaScript, may as well do it with "real" mark-up instead of some imitation language. I'm still on the fence about whether I like mixing mark-up and code, but I'm leaning more toward at this point.

That actually already exists: https://github.com/insin/msx

Awesome! Thanks for the link.

It did seem like an obvious thing to do. I probably would have searched for and found this before doing any actual work on JSX, but I'm glad to know it exists already. :)

Re: Angular 2 versus React

#249
post #239

Earlier quoted context omitted.

But then you're comparing "React + 2-3 items" vs. framework, not React vs. framework

So? Is that forbidden? Who said those who use Angular will just use Angular only as it comes upstream and won't pick and/or substitute a few libs for third party ones either?

Of course it's not forbidden. It's just confusing to say you're comparing React to a framework, when you implicitly include things other than React in the definition of React.
Post reply on HN