{ heroes.map(hero => {hero.name} )}
Angular 2 versus React
221–230 of 249 posts
Re: Angular 2 versus React
#222Asterisk-ux isn't cutting it, and god knows we need a buzzword.
Re: Angular 2 versus React
#223From someone with years of experience with javascript, how is this "plain 'ol javascript"? { heroes.map(hero => {hero.name} )}
Re: Angular 2 versus React
#224Earlier quoted context omitted.
This is beautiful.
It's the circle of life. I've been programming since I was a kid in the 80's, after a while you learn to stand back sometimes and let the bandwagon roll on past or as I've joked in the past "these days I simply get on every third bandwagon".
Re: Angular 2 versus React
#225Earlier quoted context omitted.
I love mitril so much. It would be soooo much better with a lisp syntax, though.
I can't tell if you're joking. I personally despise Lisp syntax.
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.
Re: Angular 2 versus React
#226Earlier quoted context omitted.
There is also a lack of best practices, combined with constantly breaking changes. Every tutorial before the last month is already outdated, and everybody has a different way of setting up webpack / isomorphism / templating.
>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…
> 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 numerous ways to create a service. Because of this confusion, the Angular team provides best practices. It's like saying, 'we screwed up in designing this thing, so you have to read all the documentation to find out the subtle differences in all this bullshit.' It's not the lack of best practices that concerns me, it's the abundance of them that gets shipped with a bloated framework that wasn't designed well.
>Every large release?I seriously doubt it.
Think of all the pain involved in removing all of the digest cycle code when switching from Angular 1.4 to Angular 2.0.
> No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular.
Seriously? There are no small differences between Django templates, Soy templates (client and server side), and Angular templates to name a few. They are all very different yet they do essentially the same thing. At least Soy templates can be used outside of a framework (with either JS or Java).
Re: Angular 2 versus React
#227Earlier quoted context omitted.
It's the circle of life. I've been programming since I was a kid in the 80's, after a while you learn to stand back sometimes and let the bandwagon roll on past or as I've joked in the past "these days I simply get on every third bandwagon".
Sounds like a viable strategy. That's basically my device upgrading plan. Wait for three new releases (in the same series) then "Alright, time for a new tablet/phone/laptop!" I haven't quite jumped on the watch bandwagon yet.
I'm still using knockout.js since I've used it for two years, it's maintained and each release is a big improvement in features and recently speed (massive improvements in 3.4).
Its not that react et al don't interest me but the switching costs are real and I'm not sure what they'll look like in a year.
Re: Angular 2 versus React
#228Earlier quoted context omitted.
Yes, it would seem as a developer there is a certain amount of bandwagon jumping going on in the last few years. You're very right, you really have to pick your battles. It's interesting since I'm doing more contract work and finding out that one shop uses Angular and another Backbone and a third React. Which one should I really learn and focus on, when nearly every shop has a totally different philosophy?? Even tryi…
Truth is, it doesn't fucking matter. People are still building jQuery apps. The key is solving real world problems with nicely designed solutions. Doesn't matter what you do it in, how you do it. Just solve a problem.
Re: Angular 2 versus React
#229Earlier quoted context omitted.
I can't tell if you're joking. I personally despise Lisp syntax.
...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.
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 syntax is optional.
Re: Angular 2 versus React
#230To me it really feels like Polymer is taking all of the pros from both of these "libraries" or "frameworks" or whatever you want to call it and none of the cons. Why aren't we talking more about that? Polymer is a fraction of the size. It's one of several ways right now to write custom components. React and Angular2 do the same thing yet they are both bloated and force tons of tools and tech down your throat. For wha…
> 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.
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 UNIX before it, are attempts in this direction. It's not really gelling yet though. The various component systems are trying, but inevitably fail because they are trapped in a single layer of the framework stack. I think we need a few more breakthroughs in social organizational strategies (things like Flickr, Uber, Bitcoin, etc) before it becomes obvious how to do it.