91–100 of 159 posts
Earlier quoted context omitted.
Yeah, I've heard this before. It really makes no sense why you'd want to use getters and setters when FPR is so exceedingly powerful and easy to reason about, which circles back to my point about people not understanding FPR and the benefits thereof.
What is FPR you keep referring to?
Earlier quoted context omitted.
Vue's templating engine, honestly, seems somewhat poorly thought-out. The usual way of writing it errs on the side of HTML over JS, using quote marks awkwardly to enclose a statement rather than JSX's more sensible curly brackets. It makes it harder to visually parse, and it's sometimes annoying to not be able to use one type of quote marks unescaped within the statement. Overall, this is one of many ways in which Vu…
> rather than JSX's more sensible curly brackets I'm still waiting for the 2019 equivalent of http://haml.info/
Here's a Pug -> JSX transformation: https://github.com/pugjs/babel-plugin-transform-react-pug
Detouring from the most popular path tends to come at the price of tooling idiosyncrasies that are rarely worth it, but it seems to at least work with eslint-react and has syntax highlighting in some editors.
Earlier quoted context omitted.
Check out quasar-framework
Or Ionic, which now supports Vue (and others) and is IMO substantially more polished.
As a React developer I have yet to hear a compelling reason to use Vue. Most of the time it seems like the Vue defender was just looking for the next hot thing and would have used literally anything else, didn’t understand that React is just a library and conflated it with the React ecosystem, or couldn’t wrap their head around FRP. From a business standpoint I can’t understand why you’d put anything on Vue unless th…
Earlier quoted context omitted.
Yes I've used React. React was ok, but I had to think React and work the React way. With Vue, I work my way with minimal conformance.
Weird, I came away with just the opposite impression. Vue forces you to organize everything in a certain way: data goes in data, computed properties go in computed, methods in method... it all felt very Rails to me. React sort of used to have this problem, too, when you had to rely on classes for state, but the hooks era is a breath of fresh air. Everything is just a function. It feels freeing.
Earlier quoted context omitted.
2 things for me: 1) 2-way bindings. i used to hate the concept of it as it was a form of black magic and had hard to debug performance issues ala Angular. but in Vue, it is actually fast and straightforward, it's essentially a light boilerplate around getter/setter methods. it took me a while to convert to this way of thinking but once i did, i never looked back. 2) @click, @submit, @emit, :some_property. at first gl…
Yeah, I've heard this before. It really makes no sense why you'd want to use getters and setters when FPR is so exceedingly powerful and easy to reason about, which circles back to my point about people not understanding FPR and the benefits thereof.
Earlier quoted context omitted.
React and Vue have 6.25 and 1.01 weekly downloads respectively. As of now, they are not even in the same league.
Using NPM stats is just not correct. I believe React to be about 2.5x larger than Vue rather than 6x.
As for what's next, I have a hard time envisioning anything usurping React any time soon. Its breed is basically the state of the art in UI paradigm and an active field of research. I'd put things like Elm in that cohort as well.
I think the better question is: what's next for React and its cohort?
When are we going to see these ideas appear first-class in Cocoa/UIKit/etc? When will we finally see "OOP is good for UIs" (OOP's final foothold in our dogma) lose out to "FP is good for UIs"? What's the next big thing inside the React ecosystem? How far can something mainstream like React move towards the strictness of something like Elm?
I write Vue every day, in a large application. Only small bits use VueX. Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid. I HIGHLY recommend it, and this is from someone doing web since 1997.
Vue's templating engine, honestly, seems somewhat poorly thought-out. The usual way of writing it errs on the side of HTML over JS, using quote marks awkwardly to enclose a statement rather than JSX's more sensible curly brackets. It makes it harder to visually parse, and it's sometimes annoying to not be able to use one type of quote marks unescaped within the statement. Overall, this is one of many ways in which Vu…
The "I wouldn't use Vue except for a small project" meme really needs to die too. Vue's build process is mature, has server-side rendering, and is used by some of the biggest companies in the world. If it's good enough for them at scale, it's good enough for the rest of us.
I write Vue every day, in a large application. Only small bits use VueX. Of all the frameworks I've used, it's brilliant because it hardly takes any thinking away from the business logic, so I'm not bogged down, it stays OUT of my way, and it's rock solid. I HIGHLY recommend it, and this is from someone doing web since 1997.
I'm too inexperienced to have a definitive opinion, but I'm not nearly so positive and wanted to toss out a contrasting opinion to the current comments. After a few years of using React and some past experience with various other templating/view systems (webdev of one sort or another since '99) I started picking up a little Vue. So far it's been easy enough, but it is highly confusing compared to most other systems I…
It's not wrong, but this way it sounds way more scary than:
"Properties which start with "v-" are treated specially by Vue and don't end up in the rendered output."
The revolving door of front-end frameworks is somewhat irritating; spending a nontrivial amount of time in Angular (1), then React, and now Vue. I wonder what the next one will be