3 ms·

I prefer angular over react. 1) It is opinionated (wasting time for decisions is bad) 2) It is simpler to organize the code (it is MVC) 3) (click)="onSelect

I prefer angular over react. 1) It is opinionated (wasting time for decisions is bad) 2) It is simpler to organize the code (it is MVC) 3) (click)="onSelect()" is simpler. You dont have to create an object with "bind" function like in react. 4) I dont want web designers mess with my code. So putting html on JS is bad decision.

mercer 11y ago
But do you want web designers to mess with your markup? Many of the projects I work on still involve the 'old-fashioned' server-side rendering approach with bits of jQuery for interactive elements. If a non-coder webdesigner were to mess with my markup, everything would break anyways. I guess what I'm saying is that I've worked on many types of projects in many kinds of environments, and whenever a front-end framework was necessary, the 'webdesigners' were not. I've just never run into the situation where it actually ended up being useful to create logic-less templates...
- eseehausen 11y ago
  I don't have a horse in this race, but do you think that learning JSX is going to be any easier for non-coders?
  - iLoch 11y ago
    Honestly I wouldn't hire a web designer that can't code a little Javascript. It's been a while since knowing only HTML as a web designer has been acceptable. To answer your question though: they're probably about the same level of difficulty, and I don't think it's a great argument for vanilla/React/Angular because a person who doesn't understand code trying to modify stuff that is controlled by code is going to break something regardless of what JS framework you're using. I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. The ESX syntax is just a nice way of forming a hierarchy of class instances. The beauty of React is that you could come up with your own syntax for doing that and use it just the same, because React is just Javascript.
    - mercer 11y ago
      > I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. Yeah, that's what it really boils down to. Many of the principles we apply are holdovers from when we used HTML and CSS for what it was originally intended: pages with content. The way I see it, HTML and CSS were not meant for any of these apps. But if we are going to 'abuse' these technologies, we might as well chuck out the rulebook and optimize for what apps need to do. That said, please don't do this if what you're making is 'pages with content'!
  - mercer 11y ago
    Not at all! I might not have expressed myself clearly... The point I was trying to make is that JSX is significantly more convenient for coders like me, as the markup is is the trivial part and the logic is usually the complicated part. So a javascript-first approach benefits me tremendously over trying to figure out how to get my logic working around the logic-less templating systems, or over learning a html-like DSL as in the case of Angular or Vue.js. I've even considered not using JSX at all (a bit like mithril.js). The only reason I still do is that I like the visual separation of code and markup, and that I like seeing what the the end result will look like (more or less). So if the JSX approach is so much more convenient for coders (not all, but many), and if the types of projects where you use React tend to be too complex to involve non-coders writing html/css anyways (in my experience), why not just use JSX? That said, I don't really have a horse in this race either, I guess, because I'll adjust my choices based on circumstances. A while back, for example, I used Ractive.js instead of React.js for a project, because Ractive.js uses mustache templates and simpler two-way binding (a bit like Knockout.js). Because of the particular circumstances and the relative lack of complexity of the app, I figured I'd optimize for what cheap(er) front-enders with less coding experience could take over from me, as I wasn't planning to stay on the project long-term.
dev360 11y ago
> 1) It is opinionated (wasting time for decisions is bad) I've wasted A LOT of time debating controller vs directive; asController syntax; service classes vs static factories vs rich models (resources); best way to deal with nested components etc. The problem is, most of the time I wasted with decisions in React was right in the beginning (deciding on how you control flow, how you build your app)... But with angular, all the pain points came late in the game when you thought you had done a helluva job designing a GREAT app, then you slowly come to realize its a tangled tag soup piece of crap. > 2) It is simpler to organize the code (it is MVC) If you call it MVC, then Id case it like this: mVc ... because the view portion of it is enormous! In fact, the very idea that they made the "template" do so many things is a huge reason why it could be considered a very bad flavor of MVC to begin with.

mercer 11y ago

But do you want web designers to mess with your markup? Many of the projects I work on still involve the 'old-fashioned' server-side rendering approach with bits of jQuery for interactive elements. If a non-coder webdesigner were to mess with my markup, everything would break anyways. I guess what I'm saying is that I've worked on many types of projects in many kinds of environments, and whenever a front-end framework was necessary, the 'webdesigners' were not. I've just never run into the situation where it actually ended up being useful to create logic-less templates...

eseehausen 11y ago
I don't have a horse in this race, but do you think that learning JSX is going to be any easier for non-coders?
- iLoch 11y ago
  Honestly I wouldn't hire a web designer that can't code a little Javascript. It's been a while since knowing only HTML as a web designer has been acceptable. To answer your question though: they're probably about the same level of difficulty, and I don't think it's a great argument for vanilla/React/Angular because a person who doesn't understand code trying to modify stuff that is controlled by code is going to break something regardless of what JS framework you're using. I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. The ESX syntax is just a nice way of forming a hierarchy of class instances. The beauty of React is that you could come up with your own syntax for doing that and use it just the same, because React is just Javascript.
  - mercer 11y ago
    > I prefer JSX because it's not pulling wool over your eyes - you're building a JS app, not an HTML app - so let's stop pretending. Yeah, that's what it really boils down to. Many of the principles we apply are holdovers from when we used HTML and CSS for what it was originally intended: pages with content. The way I see it, HTML and CSS were not meant for any of these apps. But if we are going to 'abuse' these technologies, we might as well chuck out the rulebook and optimize for what apps need to do. That said, please don't do this if what you're making is 'pages with content'!
- mercer 11y ago
  Not at all! I might not have expressed myself clearly... The point I was trying to make is that JSX is significantly more convenient for coders like me, as the markup is is the trivial part and the logic is usually the complicated part. So a javascript-first approach benefits me tremendously over trying to figure out how to get my logic working around the logic-less templating systems, or over learning a html-like DSL as in the case of Angular or Vue.js. I've even considered not using JSX at all (a bit like mithril.js). The only reason I still do is that I like the visual separation of code and markup, and that I like seeing what the the end result will look like (more or less). So if the JSX approach is so much more convenient for coders (not all, but many), and if the types of projects where you use React tend to be too complex to involve non-coders writing html/css anyways (in my experience), why not just use JSX? That said, I don't really have a horse in this race either, I guess, because I'll adjust my choices based on circumstances. A while back, for example, I used Ractive.js instead of React.js for a project, because Ractive.js uses mustache templates and simpler two-way binding (a bit like Knockout.js). Because of the particular circumstances and the relative lack of complexity of the app, I figured I'd optimize for what cheap(er) front-enders with less coding experience could take over from me, as I wasn't planning to stay on the project long-term.

dev360 11y ago

> 1) It is opinionated (wasting time for decisions is bad) I've wasted A LOT of time debating controller vs directive; asController syntax; service classes vs static factories vs rich models (resources); best way to deal with nested components etc. The problem is, most of the time I wasted with decisions in React was right in the beginning (deciding on how you control flow, how you build your app)... But with angular, all the pain points came late in the game when you thought you had done a helluva job designing a GREAT app, then you slowly come to realize its a tangled tag soup piece of crap. > 2) It is simpler to organize the code (it is MVC) If you call it MVC, then Id case it like this: mVc ... because the view portion of it is enormous! In fact, the very idea that they made the "template" do so many things is a huge reason why it could be considered a very bad flavor of MVC to begin with.