What the article refers to as boilerplate is actually something I like about Vue. Standard component organization is a good thing.
Vue.js: the good, the meh, and the ugly
171–180 of 382 posts
Re: Vue.js: the good, the meh, and the ugly
#172Earlier quoted context omitted.
> I think the issue is that people keep expecting something from React that React has specifically stated it does not do, which is handle everything. Ok, but people learning React - with no guidance from the library or its maintainers, as you said it's only the view - are going to search for "react how to route" or the like. They end up using things like react-router, and some of them run into problems like I did. Yo…
> Redux has had some API churn as well Uh... what API churn? The Redux store API hasn't changed meaningfully since about a month after its 1.0 release. 3.0 came out around September 2015, and it's been the same since. React-Redux has stayed API-consistent too, even though we rewrote the internals for 5.0.
Ah, It seems I was very unlucky as I started learning it right before 3.0 and tried to pick it up after 3.0. Upgrading my previous project gave me strange errors, and the documentation had changed with it, leaving me to puzzle over what had happened.
Re: Vue.js: the good, the meh, and the ugly
#173Earlier quoted context omitted.
Our site does't work with js disabled. Serious question: is it common for folks to disable js? vue is used only for the web app. No js frameworks used in the chrome app.
It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript. If JavaScript is disabled I just show a message saying the site needs it. I also only support modern browsers and haven't had a complaint for 3 years. About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no…
> If JavaScript is disabled I just show a message saying the site needs it.
We don't complain, we just go somewhere else.
Re: Vue.js: the good, the meh, and the ugly
#174Earlier 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? Sadly it seems that's mainly been cargo-culted. It's not the case that React+Redux is the equivalent to say Angular, but by some unfortunate accident due to Facebook's announcement of Flux, and then the hype around Redux as a 'better Flux', people started assuming Re…
Agreed. Cargo culting is the main issue. The solution is to try and remain unbiased, and not look for direct synonyms between two very distinct approaches to managing user interfaces.
Well, FWIW js is not the most friendly language for functional programming. I'd argue that the trend toward immutable.js and redux occurred partly because rest/spread syntax was/is relatively confusing, and so immutable patterns without a library feel less elegant until one really groks the somewhat visually opaque semantics of the rest/spread syntax.
Redux also offered a simple approach to the "action bus" idea from Flux, but omitted first class async support, etc. React itself also somewhat overlooked async patterns, which created the idea that their absence was by design and so an additional (opinionated) library was appropriate.
In sum I'd argue that React actually fights against js quite a bit and that it will truly come into its own once reason gets more mindshare.
For those of us who invested heavily in react as all this was becoming clear (and being ironed out) I hope we learned enough to allow better decision making in the future.
Also, React has a few "on by default" performance enhancements that are a bit conceptually confusing and create something of a mismatch with the functional approach.
But still it's difficult (and unpleasant) to imagine the world without React.
Re: Vue.js: the good, the meh, and the ugly
#175I mention this is pretty much any thread talking about frontend framework architectures. Check out ClojureScript's re-frame project. It's maybe not for everyone but in my opinion it's an elegant and distilled method for writing React-esque views and handling data subscriptions. The syntax is of course polarizing but it really gets rid of a lot of boilerplate.
Re: Vue.js: the good, the meh, and the ugly
#176Earlier quoted context omitted.
It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript. If JavaScript is disabled I just show a message saying the site needs it. I also only support modern browsers and haven't had a complaint for 3 years. About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no…
> If JavaScript is disabled I just show a message saying the site needs it. We don't complain, we just go somewhere else.
And I don't complain when you go somewhere else.
Re: Vue.js: the good, the meh, and the ugly
#177I tried nuxt (a vue framework) the other day and was disappointed. It seemed like a very straightforward way to create a UI over a REST backend, but I kept getting stuck with the issue of how to have a clean separation of the back end and front end responsibilities.
For example, I wanted to have a UI that was rendered based on the JSON payload that would get committed to a Vue Store. I consistently ran into issues where Vue would complain about the client rendered code differing from the server rendered code.
Are there any js frameworks where you can specify which components are rendered on the server and which are clientside?
Re: Vue.js: the good, the meh, and the ugly
#178Earlier quoted context omitted.
Five (5) megabytes of JavaScript for a basic brochure site... I assume 99.9% of that is only necessary after signing up and signing in, not while unfortunately viewing the page on a less-than-flagship mobile device and metered data plan?
It's going to change and get less hefty, we're looking into code splitting.
Vue makes it incredibly easy!
Re: Vue.js: the good, the meh, and the ugly
#179Earlier quoted context omitted.
> Redux has had some API churn as well Uh... what API churn? The Redux store API hasn't changed meaningfully since about a month after its 1.0 release. 3.0 came out around September 2015, and it's been the same since. React-Redux has stayed API-consistent too, even though we rewrote the internals for 5.0.
Ah, It seems I was very unlucky as I started learning it right before 3.0 and tried to pick it up after 3.0. Upgrading my previous project gave me strange errors, and the documentation had changed with it, leaving me to puzzle over what had happened.
That must have been a pretty tight time window :) Per the releases page at https://github.com/reduxjs/redux/releases?after=v3.0.1 , you can see that 2.0 and 3.0 were only a couple weeks apart, and basically just tightened up the API around hot-swapping the root reducer.
Since then, the most meaningful API change was 3.1.0, which redid the `createStore` signature to allow passing an enhancer as an argument (as opposed to the original more FP-style approach).
Re: Vue.js: the good, the meh, and the ugly
#180I tried nuxt (a vue framework) the other day and was disappointed. It seemed like a very straightforward way to create a UI over a REST backend, but I kept getting stuck with the issue of how to have a clean separation of the back end and front end responsibilities. For example, I wanted to have a UI that was rendered based on the JSON payload that would get committed to a Vue Store. I consistently ran into issues wh…
Strapi just released their tutorial on nuxt and other backend stuff.
https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-v...