[deleted]
Vue.js: the good, the meh, and the ugly
231–240 of 382 posts
Re: Vue.js: the good, the meh, and the ugly
#232I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…
Also Vue is multiple languages. There's a pseudo-HTML language. There's a loop language inside v-for, a special assignment language. React is just JavaScript and HTML.
I'm not sure attributes named as "ref" or "className" qualify either as Javascript or HTML
Re: Vue.js: the good, the meh, and the ugly
#233Earlier quoted context omitted.
Netflix, Walmart, etc. solve a much different set of problems than most shops. I'm proud to work for a small company with simple (but rapidly changing) requirements. :)
That doesn't answer my question. What about Vue actually made it a better choice for those requirements? In my experience, the fact that React is a simple view library makes it the perfect choice for small shops. You're taking on considerable risk when you use a technology without a vested backer (Facebook is heavily vested in React, look at Angular 1 for an example of a framework with a big backer than is not vested…
> In my experience, the fact that React is a simple view library makes it the perfect choice for small shops.
Vue is also a simple view library.
You keep bringing up Angular, as if Vue has something to do with it. Vue is so much closer to React than to Angular.
> You're taking on considerable risk when you use a technology without a vested backer (Facebook is heavily vested in React, look at Angular 1 for an example of a framework with a big backer than is not vested, the API was completely broken in a rewrite). Smaller frameworks also suffer from a lack of sustained development.
Sorry, but that sounds a lot like rationalization and wishful thinking, written purely to make React look good and anything else look bad.
Vue also has backers that contribute financially, a large community using it and sustained development. The fact that it isn't as big as React doesn't make it unworthy of existing or unable to provide the same technical benefits as React.
Re: Vue.js: the good, the meh, and the ugly
#234Earlier quoted context omitted.
> the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. It took me many years to realize this. I think very few front end developers understand this. And more problematically: very few framework devs seem to understand it. Stated another way.... Your tree of UI widgets, and Your tree of data which feeds those widgets ... are two orthogona…
>Your tree of UI widgets, and >Your tree of data which feeds those widgets Not with a well-designed XML format and XSL-T! But hmm, nobody seems to use that anymore either.
Having done this in the wild a while ago, it seemed to be hard for most of the other developers to do anything complex with it.
You either really got it and then could do wonderful things, or you sorta muddled along with it and it was ok but it was like they were wearing a straitjacket.
I made a pivot table control out of it, with almost all the logic inside the XLST, it was amazingly fast compared to IE6's javascript at the time. I remember that Blizzard used it for the WoW online character viewer which was streets ahead of what anyone else was doing.
Also there's a DailyWTF about someone doing this on a large app, which brought the developer out of the woodwork to defend it who said in fact it wasn't a WTF, it was deliberate, it worked, loads of people loved it. Which prompted a huge debate about how it was actually kinda good, but just too high a learning curve (which is the death knell of many a tech).
Personally I don't miss it. The best way I can sum up XML/XLST up is that it made me feel clever, and now I know that when I start feeling clever about my code that's a sure sign I'm making something that's going to be a nightmare to maintain.
Re: Vue.js: the good, the meh, and the ugly
#235I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…
Also Vue is multiple languages. There's a pseudo-HTML language. There's a loop language inside v-for, a special assignment language. React is just JavaScript and HTML.
The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX. It's not much, really.
I personally find Vue templating syntax much easier to follow than JSX, but that's because I'm used to it. I honestly believe that's how React users feel about JSX too.
Re: Vue.js: the good, the meh, and the ugly
#236Earlier quoted context omitted.
If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…
So I see where you're coming from. To first address Redux, etc, React has no opinion on state storage, it's a feature not a bug. Obviously you need to store state somewhere, and Redux, Relay, etc are just tools to address that concern. But that's really unrelated to what you're trying to address, which is coupling between leaves that have shallow common ancestors, but are themselves quite deep. Although in my experie…
As someone one who rewrote a React/Redux project with bare React : Everything in your post is true, I made the same observations and I reached the same conclusions.
Right now with a few devs it is going very well but I do worry about on-boarding people who are not proficient in functional programming.
React code without a global state management library is very pleasant and easy to read/understand for many, but for some it is not always obvious to write. You may have to spend more time code reviewing and training newcomers who will sometimes feel like their task is impossible without Redux. I have yet to see if those requirements can still hold for a big team but I think it is possible.
My current opinion on Redux is that it is best suited for existing project migrating to React because you may inherit very odd relationships between the view and the data and Redux will avoid you a lot of pain on this regard. A new project should avoid Redux & co as long as it can.
Re: Vue.js: the good, the meh, and the ugly
#237Earlier quoted context omitted.
So I see where you're coming from. To first address Redux, etc, React has no opinion on state storage, it's a feature not a bug. Obviously you need to store state somewhere, and Redux, Relay, etc are just tools to address that concern. But that's really unrelated to what you're trying to address, which is coupling between leaves that have shallow common ancestors, but are themselves quite deep. Although in my experie…
Is there a blog post explaining higher order components in more detail, preferably with examples?
The doc is very detailed with good examples : https://reactjs.org/docs/higher-order-components.html
Re: Vue.js: the good, the meh, and the ugly
#238>You’ll be adding similar boilerplate for computed properties, component state, watchers, etc. Pretty much everything in Vue has its own special syntax with more boilerplate. I kinda like this syntax, when I first learned vuejs I knew immediately that some magic was going on in the background. If I saw marko's syntax I'd be wondering how this shit is getting done. It also makes it easier when searching for issues or…
I hadn't heard of laracast until starting Vue development a few weeks ago. The quality of answers were so low I found myself longing for the days of expertsexchange.com. Why did laracast get so popular for Vue? What was wrong with Stack Overflow?
AFAIK Vue got a big popularity boost when Laravel's lead dev posted https://twitter.com/taylorotwell/status/590281695581982720
Then the Laravel ecosystem adopted it widely, and a good Vue.js tutorial series was published on Laracasts (which also happens to host the official Laravel forum)
Hence the close link with Vue and the Laravel community.
Re: Vue.js: the good, the meh, and the ugly
#239We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works. TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen. There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design v…
I agree - the Typescript support isn't great... I was taking a look at vue + typescript and cobbled together something that worked but there was unpleasant weirdness.
I wasn't aware that vue3 was going to be written in Typescript - that is very welcome news.
Re: Vue.js: the good, the meh, and the ugly
#240Earlier quoted context omitted.
It saddens me that JSX became so popular in the React community. I find the syntax verbose and hard to read ... similar to HTML. At my last company we used `react-hyperscript` which was a simple wrapper around `react.createElement`. Ultimately, the React developers made the mistake of making `createElement` so annoying to work with, I assume because they bought into JSX. Granted, JSX might have been necessary when Re…
If you care about compile-time checking (you would, if you work on medium to large applications) then JSX (or the TypeScript variant, TSX) is much better because it catches invalid or mistyped attribute names etc.
Only because it is more mature. No reason you can't write a linter for hyperscript.