141–150 of 382 posts
For me personally it took the MVC into SPA territory, got rid of all the muck that's jQuery and replaced it with a fun, easy to design UIs with platform.
If you ask me it's biggest achievement is that it put design, experience and interaction on the same level, literally - thanks to .Vue files :) Consolidating them just made sense.
I don't get the thing about ReactJS boilerplate where he says "Moving from React to Vue seems like a breath of fresh air. No more bind(this) or setState() everywhere. Yay! " Surely there's better ways of doing ReactJS rather than lots of setState? Of course I use setState but try to avoid it generally. And I almost never, ever use bind() - don't es2015 fat arrows make it obsolete?
Earlier quoted context omitted.
Vision impairment is a spectrum, so someone who can see to some extent may be using a screen reader to assist. People might be using your site at 150% zoom, etc etc. One thing you can do is put a note somewhere easy to find that says "if you require assistance using this site, email someone@domain.org". Sites that I've worked on also had a phone number here but I understand that's an edge case. You also mentioned alt…
Hi voltagex, thank you for your input. I don't think this is the kind of website where I "help someone to use it". Instead of speaking in the abstract I may as well show you so you can see what I mean: https://pricehipster.com As you can see, the whole point of it is designed around quickly glancing at prices. And I don't think it makes sense to tell people other places they can find prices if they can't see well eno…
It's been a while since I looked at things like this but have you done simple stuff like check whether the colour contrast ratio [0] meets WCAG standards?
What about making the orange highlight work when tabbing through the website with the keyboard?
What about having a Skip Navigation / Skip to Content link? [1]
Earlier quoted context omitted.
> I am never a fan of two way data binding as an alternative. The author is wrong. Vue doesn't have two-way binding. It has one-way binding with events. Components can't force anything upon their parent's state with an event.
I mean, Vue calls it two-way data binding. From their website: > "You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases." I'm not knowledgeable eno…
Earlier quoted context omitted.
I'm curious to know, what about Vue makes it easier to learn than React? It's just a function that takes in data and returns a piece of html. React also just works, and unlike Vue, it's worked for companies like Netflix, Wallmart, Facebook, Instagram, etc that have exceedingly complex requirements and require exceedingly fast rendering. What did you really buy with Vue over React?
For one: vue, vuex (centralized state library) and vue-router are stewarted by roughly the same people, which has a few benefits. The documentation is all pretty decent and uniform. I never sit for very long wondering how to do something. Changes that break backwards compatibility are reflected across all three at the same time, and the correct versions are installed by vue-cli. I had several starts with react, react…
I remember working on Angular 1 projects, where literally everything from loops to http calls was mandated by the framework. Then everything suddenly became legacy. Angular was going to be completely rewritten, and everything I had learned was going to be tossed away. I still, to this day, have to work with projects that are Angular 1 code rot hell.
I think that's probably why I have never had the problem's you have had, because I never wanted to use React Router or Redux. Those pieces of functionality were easy to implement on my own. (Redux itself is incredibly small)
Personally, I think it's silly to use Vue. Angular had serious deficiencies and project mismanagement, and React was a real solution to those problems. I mostly hear either minor grievances from the Vue crowd, or no response at all as to why they switched (hype train most likely).
I also don't think Flux was vague, it just lacked an implementation. Again, there just seems to be a big fear in the JS community about writing code instead of pulling in a framework. React itself is just reactive functional programming. The sell of not writing it yourself is that you get to work with a nicer API while the React team improves the backend for you (a la Fiber).
Earlier quoted context omitted.
I'm curious to know, what about Vue makes it easier to learn than React? It's just a function that takes in data and returns a piece of html. React also just works, and unlike Vue, it's worked for companies like Netflix, Wallmart, Facebook, Instagram, etc that have exceedingly complex requirements and require exceedingly fast rendering. What did you really buy with Vue over React?
Our company used React when starting a new project, but we still had an existing project with a vanilla HTML/CSS/js website, which really needed a rewrite. I had a talk with my cofounder about the strengths and value of React, but hadn't dived deep yet - I wasn't working actively in the codebase of the new project. I tried to, and all the moving parts were monstrous to wrap my head around - states, redux, actions, wh…
Earlier quoted context omitted.
Hi voltagex, thank you for your input. I don't think this is the kind of website where I "help someone to use it". Instead of speaking in the abstract I may as well show you so you can see what I mean: https://pricehipster.com As you can see, the whole point of it is designed around quickly glancing at prices. And I don't think it makes sense to tell people other places they can find prices if they can't see well eno…
Okay - that makes sense. It's been a while since I looked at things like this but have you done simple stuff like check whether the colour contrast ratio [0] meets WCAG standards? What about making the orange highlight work when tabbing through the website with the keyboard? What about having a Skip Navigation / Skip to Content link? [1] 0: https://webaim.org/resources/contrastchecker/ 1: https://webaim.org/technique…
Thanks for the link about "skipnav" I haven't heard that term before. I don't really see how that can fit in, though? I guess the category links right at the top of the page is the closest concept?
It doesn't make sense to skip down to item number 200 since there's no way to know what's down there. Best to look at items 1-199 first. That is the same for all users.
I 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…
I've been using React full-time for a year and a half now, and I've never felt like pure-functional components are a good fit for more than a handful of use-cases. If all you're doing is displaying data, then sure, they're really elegant, but most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled, which means pretending they aren't feels gross and we…
Earlier quoted context omitted.
> most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled I think this is what the Flux model is all about, making UI code actually be a pure function of state. By that, I mean literally a function, where state is the argument, and where all you render depends solely on said argument. If you want to change what is rendered, you send a message and a St…
Well because the UI isn't just a function of state, it's also a function of those actions (the actions have to literally be passed in to the rendering function). So there's bi-directional coupling between the UI code and the Store (the UI code renders from the state, and passes messages back to the store). Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, an…
I think both React and Vue become difficult when working with complicated UIs. If you're already using Vue or React, these simple articles are not comprehensive enough to be convincing. React and Vue basically manage state the same way, which is 90% of what you'll be doing in these libraries. And just like in React, default state management is insufficient in Vue.
That hasn't been my experience at all. The medium-sized app I worked on used what is apparently called the "store pattern": a state class with data and methods that mutate it, and components that read the data but only update it by calling its methods. This provides the major benefits of Redux ("functional" components whose only state is purely local) with much less complexity.