Live data from Hacker News

Angular 2 versus React

medium.com

231–240 of 249 posts

Re: Angular 2 versus React

#231
post #37

Earlier quoted context omitted.

Note that mithril is much more lightweight than react, offers a similar vdom model, but has a completely different algorithm for deciding when to redraw. I actually think that mithril's redraw algorithm is less intuitive to use than react, but it is way simpler, which has its own advantages.

I love mitril so much. It would be soooo much better with a lisp syntax, though.

I wrote a parenscript wrapper for it.

[edit] No time tonight to make it pretty and publish it, but here it is[1]. Usage is identical to my parenscriptx[2] (a React tool I wrote that I based this off of).

1: https://gist.github.com/jasom/4ab84354fda405a8f67a

2: https://github.com/jasom/parenscriptx

Re: Angular 2 versus React

#232
post #50

Earlier quoted context omitted.

Is there any substantial apps written in Polymer yet?

The Google cloud developers console is most probably built with polymer

I just looked at the source and it's built with Angular and Angular Material. The UI for the Cloud Console app is incredible work.

Re: Angular 2 versus React

#233
post #175

Earlier quoted context omitted.

That's a good point, I think I should of said "Dynamic" for lack of a better word. Interactive, it needn't be.

I guess I missed the memo. When did it happen that web markup suddenly got a need to be dynamic?

How often do we list static data in lists anymore? Honest question. It feels like most websites you view anymore are displaying data fed from somewhere that isn't known when you write the markup. As you write markup some is meant to repeat data (lists of posts, reports, etc.). Since this seems to be (to me) happening more than not, markup needs at least some kind of update to accommodate the fact that when writing it, we don't typically write out static markup anymore, though the end result obviously is.

Therefore, Angular, to me, acts like that "dynamic markup" when writing it. It feel more natural to me at this point.

Re: Angular 2 versus React

#234
post #41

Earlier quoted context omitted.

>lack of best practices How many 'best practices' do you need? What about 'higher order components'? Use proptypes in development? 'Avoid local state'? >constantly breaking changes I call bullshit, what was the last breaking change? Every large release still supports the old deprecated syntax, but with warnings. >Every tutorial before the last month is already outdated That is a big exaggeration; I wouldn't advice an…

I call bullshit on you calling bullshit on every point of this comment. > How many 'best practices' do you need? Actually, there should only be one way to do something in a framework. While not a framework, think about the Go language. Go is a very strict, almost paternal language that 'enforces' best practices in the language itself by giving you only one way to do something. Angular, on the other hand, provides num…

My comment is about React. I am not defending AngularJS.

Re: Angular 2 versus React

#235

Earlier quoted context omitted.

...Well then, you probably wouldn't like Mithril. Typically, Mithril uses raw JS lists, function calls, and objects to create its vdom, which you have to directly manipulate. Like using react without JSX. With a lisp syntax, you might write the end of an expression as )))))), as opposed to in JS, where you might write )])]}); or something similar.

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.

Re: Angular 2 versus React

#236

Earlier quoted context omitted.

I love mitril so much. It would be soooo much better with a lisp syntax, though.

I wrote a parenscript wrapper for it. [edit] No time tonight to make it pretty and publish it, but here it is[1]. Usage is identical to my parenscriptx[2] (a React tool I wrote that I based this off of). 1: https://gist.github.com/jasom/4ab84354fda405a8f67a 2: https://github.com/jasom/parenscriptx

I was thinking more along the lines of lispyscript[1]. It's not as good as SPOCK[2], or clojurescript[3], but there's less overhead than clojurescript, and SPOCK is known to stretch your javascript implementation in odd ways.

1: http://lispyscript.com/

2: http://wiki.call-cc.org/eggref/4/spock

3: https://github.com/clojure/clojurescript

Re: Angular 2 versus React

#237
post #37

Earlier quoted context omitted.

Note that mithril is much more lightweight than react, offers a similar vdom model, but has a completely different algorithm for deciding when to redraw. I actually think that mithril's redraw algorithm is less intuitive to use than react, but it is way simpler, which has its own advantages.

I love mitril so much. It would be soooo much better with a lisp syntax, though.

eslisp[1] might be up your alley

[1](https://github.com/anko/eslisp)

Re: Angular 2 versus React

#238
post #237

Earlier quoted context omitted.

I love mitril so much. It would be soooo much better with a lisp syntax, though.

eslisp[1] might be up your alley [1]( https://github.com/anko/eslisp )

Thanks for the pointer, Leo.

Also, thank you for the mithril blog. It is amazing.

Everybody else, if you haven't read the mithril blog[1], YOU SHOULD BE READING THE MITHRIL BLOG. Even if you never plan to use mithril, you'll probably learn something interesting.

1: https://lhorie.github.io/mithril-blog/

Re: Angular 2 versus React

#239
post #105

Earlier quoted context omitted.

> Second, when we say React we almost ALWAYS mean React + Router + some Flux lib, etc. -- so all the same things you get with Angular, just cherry picked. This premise is quite silly. Not every programmer is looking to create or adopt a framework in the beginning of a project. Some people just pick and choose libraries as they see fit and as the code evolves. I've worked on more than a few React projects and none of…

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

Re: Angular 2 versus React

#240

Earlier quoted context omitted.

I wrote a parenscript wrapper for it. [edit] No time tonight to make it pretty and publish it, but here it is[1]. Usage is identical to my parenscriptx[2] (a React tool I wrote that I based this off of). 1: https://gist.github.com/jasom/4ab84354fda405a8f67a 2: https://github.com/jasom/parenscriptx

I was thinking more along the lines of lispyscript[1]. It's not as good as SPOCK[2], or clojurescript[3], but there's less overhead than clojurescript, and SPOCK is known to stretch your javascript implementation in odd ways. 1: http://lispyscript.com/ 2: http://wiki.call-cc.org/eggref/4/spock 3: https://github.com/clojure/clojurescript

parenscript is quite low overhead; it's approximately lispyscript with common-lisp macros instead of whatever lispyscript has (it looks like some kind of pattern-matching style; there's only one macro example on the lispyscript documentation and the link to an article about more details is dead). In any event if you know lispyscript you can probably translate my code; it took me only a couple of hours to write the initial react version, and another 45 minutes or so to translate to mithril.
Post reply on HN