Vue.js: the good, the meh, and the ugly
medium.com
medium.com
https://reactjs.org/docs/components-and-props.html
The best thing to do is just to brush up on functional concepts, thinking about things in terms of composition and application, and threading state through your application and flowing back through to the top via dispatches. Learn more about flow (the concept, not the framework). I like to picture a waterfall, where the water is state that always keeps flowing no matter what it hits. State should start at the top from some source, we don't care what that is, and then flow through the application down into the leaves. Functions can do transforms and reductions on state, but they should never hold on to state the way class components do.
Furthermore, Elixir has Agent, a higher abstraction on top of Erlang/OTP gen_server that's easier to grok and use in many simple cases with no need to separate the public interface and OTP callbacks.
In the last SPA I wrote there's about 100 components, less than 5 of them are stateful.
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 complex web app, a component nested twenty levels deep may need to display pieces of information, like the user's date of birth and the current temperature on Mars, that none of its parent controls cares about.
At that point, you can either bite the bullet and pass state through layer upon layer of props, completely eliminating any semblance of separation of concerns in your component layering, or inject state into your components via some other mechanism, like Redux/MobX/Context. At which point, JSX is basically just another fancy HTML templating library.
"Idiomatic" React is a fun game to play when doing basic examples, using something like a todo manager, but as soon as you're in the real world, you hit its limitations very quickly.
Having a shared store really does change the way you look at web apps - it's almost a completely different paradigm. If you can avoid re-loading the data for a view if you already have it then then opening a new view to edit a subset of the data instead of dealing with popup makes life so much easier - you get a lot more freedom with the UX and going back to the previous view with the parent data is almost zero-cost.
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 React+Redux is what is needed to build a React app.
Meanwhile Dan Abramov, Redux creator says [1]:
> Flux/Redux is meant for big apps with complex nested UIs that have many independent parts but share common caches of data.
That's not "every semi-complex React app". In most "semi-complex React apps", most state can be derived from the route (e.g. react-router) or is relatively local. Redux is not required.
[1] https://twitter.com/dan_abramov/status/732719257579065345
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.
As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise some sort of longevity. We also need to pick tools where best practices and idioms have been established.
To do this we have to trust someone else's opinion and try to gauge which solutions have the best prospects. This means not just evaluating software based on its own technological merits, but also listening to what "the community"/"the industry" seems to be rallying around; you don't want to be stuck using a library that nobody is maintaining, just as you don't want to be stuck using something that's just badly designed.
When we started using React, there was no state management framework available, and everything was handled somewhat ad-hoc. Then Facebook described Flux, and we realized they were onto something, so we started using their patterns, with some simplifications where theirs seemed overly complicated. Then Redux came along and seemed like a better way to do things.
At each point there was uncertainty about what best practices and "idiomatic" solutions would turn out to be, because the technology was immature. I don't think anyone was cargo-culting. It was just that a lot of people were busy trying to create things, and when there isn't clear guidance, and the alternative is going back to Backbone or jQuery or something, then you just forge ahead, trying to do fit the pieces together.
Can you really look at where the community is, the perception that still exists that React+Redux is necessary, projects like redux-form (that now admit Redux was a poor fit for forms) and honestly say no cargo-culting happened?
Sympathy for 'attempting to follow the mainstream' though, I understand that. Personally I stuck with Backbone for years longer than most, avoiding the Angular/Ember wars, and the early days of React+Flux til the React ecosystem had matured a little, before jumping over to React at which point it was clearer that Flux/Redux were being misused.
I never got the impression, even from the start, that setState() was a good solution, by the way. But it's not like the React authors were completely sure of where the right design was, either. Flux, for example, as it was originally described, appears completely overdesigned at this point. The good design is to be found in Relay and GraphQL.
It's not really about blaming bloggers.
It's really on software team leads and senior engineers to not just follow blog posts blindly. They should be pushing back on bad advice like redux-all-the-things, because to a senior software engineer the tradeoffs of something like Redux should be fairly obvious.
> The good design is to be found in Relay and GraphQL.
Nah again, good example to question what you read/hear.
GraphQL is great from a front-end point of view but complex to implement in the backend, so it really depends on your use-case whether that backend complexity is worthwhile.
The claim isn't that there's no cargo cult around the React ecosystem — but not everyone writing React code is approaching it with experience, which means they try to pick up best practices from other people. That's not "cargo culting"; it's a reasonable thing to do when you have to solve a problem you don't know how to solve!
Ultimately, people aren't being "tricked" into using these tools. They proliferate because they solve real problems people have, and a lot of people would rather work with a popular and well-documented solution (with known advantages and drawbacks) than trying to forge their own path and seeing how it goes.
> Also, everyone high up in the React community, including both inventors of Redux [1], say that Redux is not the best place to keep form data. Oops.
[1] https://github.com/reactjs/redux/issues/1287#issuecomment-17...
An isolated login form? Yeah, no point keeping that in Redux - it's not being shared, it's not being persisted, there's no real need to track the history of changes. But, there are certainly situations where you might want to keep some form data in Redux.
As a specific example from my own app: we show some polylines on a 3D globe, and allow the user to edit them. We need to be able to live-update the point locations and labels on the globe as the user edits them, allow resetting edits, and still be able to show the original values elsewhere in the UI. Keeping all that data in Redux makes it easy to do so.
The Redux FAQ has a list of suggested rules of thumb for deciding what state should go in Redux: https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... .
Now, the other app my team works on is built with Backbone/Marionette. We've introduced React and Redux to it, and are progressively refactoring over time. It works, although we've got some rather ugly code in several places (some data is in Backbone collections, other data is in Redux, and occasionally some bits of data are mirrored in both places).
I wrote about some of the techniques we're using to integrate them here: https://blog.isquaredsoftware.com/2017/07/react-redux-backbo...
I also spent just 1 hour completing multiple RFCs in another app built with create-react-app using redux/connect as a purely syntactic-sugar state propagation layer.
I love the complexity and feeling of fulfillment for triumphing in the former scenario, but it is definitely much more of a distraction than anything else.
IIRC there were a lot of comments about having to pass props to children constantly (without using a state management library). Seems like it's a lot easier to not use a state management library now that an official, non-experimental Context API exists. But remember, this was only added a few years later.
> At which point, JSX is basically just another fancy HTML templating library.
JSX is optional syntax sugar; my team uses React and Redux heavily, but we've opted not to use it.
HTML templating is great actually, all the rendering is data -> UI.
If you go back to the early Rethinking Best Practices presentation[0], it boils down to asking why client side development isn't like like HTML templating. The answer is that updating the entire page DOM on every change is unworkable, there needs to be support for partial updates. That's what React offers, a return to the data -> UI paradigm, without having to write a secondary code path for partial updates.
dom.div({ props }, ...)
MyComponent({ props }, ...)
Isn't a good chunk of AirBnB, Facebook, Instagram, Netflix, The New York Times and Dropbox written in React?
The built-in state management has limitations, of course. I see it best for keeping state relevant to display-- React is supposed to be a "view" library, not a state management one.
The vast majority of our codebase is comprised of simple idiomatic React components. Our reducers and glue code (e.g. @connected containers) are a very small portion of the codebase. If I woke up tomorrow and decided Redux was the source of all our problems I could completely remove it while only needing to refactor a small portion (<5%) of our codebase that's mostly boilerplate anyways.
One thing to realize is that you always get to decide on the granularity of your compositions. It is not necessary to build a deep hierarchy if you design the granularity of your interfaces correctly. Another great tool is higher order functional programming, such as passing components to components (via children). In this way, it is easy to describe generic interfaces and supply specific pieces of data without having the intermediary interfaces know or care about that data. Another approach, akin to using something like the state monad, is to use Reacts context feature, but this is rarely needed, in my experience.
Personally I make heavy use of higher order components, and I find I rarely exceed a component tree height of three.
Examples of HOC are the connect() call from Redux, or the withNavigation() from React Navigation, or injectIntl() from React-Intl. These respectively add Redux functionality, navigation functionality, and internationalization functionality to your component.
I think the name "Higher Order Component", like many things in the React world, is poorly chosen and actually obscures what it is, how it works, and makes it look more intimidating than it really is. It's technically correct (like 'reducer' is), but communicates nothing.
It's effectively a replacement for the old React mixin system.
It happens to use functional programming methods, but that's an implementation detail.
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.
That's my experience as well. If you use a deep component hierarchy you have bigger problems than those solved by Redux, VueX or the Context API.
Higher order components or even simple functional components are really underrated when it comes to making your application simpler to reason about and to maintain.
I understand that such an open-ended product is frustrating to use because redux is insanely overengineered, mobx reintroduces data binding, and context is buggy and terrible, but I don't think what you're calling "idiomatic React" is actually considered idiomatic by anyone, including the core development team.
Interested in hearing what you think, though. My Redux experience has been more limited by trying to avoid it on small projects.
First, your points about `dispatch` and `context` are specifically about the React-Redux bindings, not the Redux core itself. React-Redux is specifically intended to act as an abstraction layer so that your own components are "unaware" of Redux, which keeps them more reusable and more testable. It also saves you from needing to write store subscription handling every time you want to make use of data from the store. My "Redux Fundamentals" workshop slides [0] show examples of what it would look like to hand-write store subscription code all throughout your UI, and it would be a pain.
If you _really_ want to, there's nothing stopping you from importing the store globally across your application and using it, but that misses out on the benefits of React-Redux, and also ties you to that one specific store instance.
Second, you can absolutely do async logic without any middleware. However, one of the key design points of Redux was to allow users to choose which approach they want to use to handle async logic, without limiting users to whatever was built in to the core. I discussed this in my "Redux Ecosystem" talk at ReactBoston last year [1].
You can certainly do async logic without any special middleware - just `connect()(MyComponent)`, throw in a `setTimeout`, and call `this.props.dispatch()`. The point of `redux-thunk`, the most common async middleware, is that it provides a generic way to move async logic outside of your UI and make it reusable [2].
Finally, the "dispatching an action === calling a function" comparison can be true, but only if you're using Redux with a limited mental approach and treating actions like "setters". If you start thinking about actions as more of an "event that occurred", then that leads to having multiple parts of your reducer logic independently respond to the same action and update their own pieces of state (which is an encouraged usage pattern). Justin Falcone had some good thoughts on this a while back [3], and I talked about this some in a fewmore of my blog posts [4] [5] [6].
[0] https://blog.isquaredsoftware.com/2018/06/redux-fundamentals...
[1] https://blog.isquaredsoftware.com/2017/09/presentation-might...
[2] https://blog.isquaredsoftware.com/presentations/workshops/re...
[3] https://medium.freecodecamp.org/whats-so-great-about-redux-a...
[4] https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-th...
[5] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[6] https://blog.isquaredsoftware.com/2017/01/practical-redux-pa...
However, some of the things that have been traded are default configuration that represents typical use, standardisation across the ecosystem, and brevity. I think that for a lot of use cases, these tradeoffs make React-Redux harder to use, and that as a whole they make it easier to cause significant architectural problems for a newer or less technical user.
> If you _really_ want to, there's nothing stopping you from importing the store globally
What I've taken to doing is exporting a dispatch function that calls the store's dispatch, not the store. I think this better captures the intention behind Flux than a higher-order component, without much cost, since dynamically swapping between stores doesn't seem common.
> ...one of the key design points of Redux was to allow users to choose which approach they want to use to handle async logic...
This power and choice, while allowing a lot of freedom, comes at the cost of a fragmented ecosystem. The Redux documentation page for async actions lists six different packages that can help.
> the "dispatching an action === calling a function" comparison can be true, but only if you're using Redux with a limited mental approach and treating actions like "setters"
I may not have explained that very well. Actions themselves make perfect sense from the perspective of a reducer, and clearly they must be dispatched, but they're a state management detail that the UI doesn't need to know about. Something similar to redux-action could be the default.
I suppose my core problem with Redux/React-Redux is that I don't understand why a typical component in a typical app doesn't look like
import { connect } from 'redux'
import { deleteFoo } from '../actions'
const FooList = ({ foos }) => {
return foos.map(foo => <button onClick={() => deleteFoo(foo.id)}>Delete {foo.name}</button>)
}
export default connect(state => ({ foos: state.foos }))(FooList)> What I've taken to doing is exporting a dispatch function that calls the store's dispatch, not the store.
Not sure I follow that train of thought - could you point to an example?
> Actions themselves make perfect sense from the perspective of a reducer, and clearly they must be dispatched, but they're a state management detail that the UI doesn't need to know about. Something similar to redux-action could be the default.
This is why we recommend use of action creators, so that a component is just calling `this.props.doSomething()` without it "knowing" that a Redux action is actually being dispatched.
Per your snippet there at the end:
- `redux` and `react-redux` are deliberately separate packages, because the Redux core is 100% vanilla JS, and independent from React (in the same way that `react` and `react-dom` are separate packages - the core React logic is independent of the platform-specific reconcilers). So, `import {connect} from "redux"` wouldn't be appropriate.
- The use of `deleteFoo()` that way assumes that it's pre-bound to a specific store instance, which limits the reusability of your logic, and also makes it a lot harder to test. `connect` abstracts away the question of "which store instance am I interacting with?", so that your components and logic are more testable and reusable.
> Something similar to redux-action could be the default.
For what it's worth, earlier this year I threw together a small `redux-starter-kit` package: https://github.com/markerikson/redux-starter-kit . The goal behind it is to simplify some of the most common pain points around Redux: store setup (including thunks and devtools), writing immutable updates in reducers, and having to install multiple packages out of the box. The biggest thing I know it's still missing at this point is indeed something akin to `redux-actions` - see my notes at https://github.com/markerikson/redux-starter-kit/issues/17 .
I haven't had time to push it forward further, but I would seriously like to get some more eyes on it, see if there's any other use cases we should be covering, and then make it an official Redux-branded package and update our docs to recommend that people use it.
Something like
const store = createStore(...)
export const dispatch = (action) => store.dispatch(action)
> `redux` and `react-redux` are deliberately separate packages
Yeah, my bad, got the import wrong.
> ...limits the reusability of your logic...
When would this become a problem, in practice? Reusable actions across different react/react-native UI, or multiple apps? Switching between user accounts? How common a use case is it?
Even if this is a constraint, I'm of two minds about whether a hack in isolation is worse than more complicated action boilerplate in general.
> ...and also makes it a lot harder to test...
This can be mitigated by Jest's mocks.
> https://github.com/markerikson/redux-starter-kit
That's really good. Unfortunately, it's not the same thing as bundling it with Redux proper.
Anyway, thanks for engaging with me. I never intended to do a deep dive into Redux's design, only to sympathise with stupidcar's comments about third-party state management, but it's interesting to hear the perspective of a maintainer.
Your `dispatch` snippet could be simplified to just `const {dispatch} = store`, because the store isn't a class instance - it's a closure. However, I'm not sure why you'd feel a need to "remove the temptation to read directly from the store". In what scenario are you trying to dispatch actions (presumably from the UI), but not read any data?
A basic example of reusability is the unit testing scenario itself. Ideally, you want to minimize the amount of other app code that's getting pulled in, so you can test this one piece in isolation. A React component shouldn't "know" about a store at all - it should just be getting data and functions as props. Similarly, even async logic _should_ be testable in reasonable isolation. If you are directly importing a singleton store instance throughout the entire app, you're coupling all of your logic to that one instance.
Typical testing of store-related logic involves the `redux-mock-store` package, which is just similar enough to a real store to let code run, but records which actions have been dispatched. Similarly, if you do want to test a Redux-connected component and its pieces all together, you would normally provide a unique store or mock store instance there in the unit test - you don't want to drag in the rest of your codebase to test that one piece. (And sure, Jest has some pretty good mocking abilities, but not everyone's using Jest.) I've got some slides on standard Redux unit testing practices [0], and a large section on testing in my React/Redux links list [1].
Outside of testing, yes, reuse of React+Redux across multiple platforms is viable, as is sharing code in libraries. But, again, that only works if the store is effectively dependency-injected at runtime, and that's the point of how things like `connect()`, thunks, and sagas are set up.
I agree that a separate "starter" package isn't the same as putting that all in the core, but that's kind of the point. The starter kit depends on several other packages (`redux-thunk`, `immer`, `selectorator`, etc), while the core Redux library is tiny and standalone. The intent has always been to keep the core small, and let people build pieces on top of it. So, for this package, the specific goal is to help simplify the most common use cases and concerns I've seen, while still avoiding dictating the rest of their app design.
[0] https://blog.isquaredsoftware.com/presentations/workshops/re...
[1] https://github.com/markerikson/react-redux-links/blob/master...
It’s easy to point out frustrating things or hard problems; it’s not easy to point to a way out.
Personally I love the explicit state flow react forces, and I would hate to move to a framework where I spend time figuring out how data goes from point A to point B.
I don't understand your point that injecting state into your components (e.g. with Redux' connect function) means JSX is just another fancy HTML templating library. All you need to do is have your React component export a "dumb" version as well as a connected version. Your dumb version will still be reusable in other parts of your application, and any other application could also use your dumb component and connect it to their global state through whatever means they please.
There's your problem I think, as other sibling comments pointed out.
Redux is what you get when people try to use React as a "full-app" framework instead of what it's meant to be: a view layer.
You build a DataSource class/prototype with methods such as :
- fetch
- addChangeListener
- removeChangeListener
You extend this class for each data type :
class CommentsData extends DataSource {
// Your custom data source with your data treatment and data getters
}
I'm not a fan of Redux either, but I fail to see what problems this approach solves.
- It checks to see if the root Redux state is different than last time, and bails out if it's the same reference under the assumption that nothing changed
- It checks to see if the return values from your `mapState` function are shallow-equality different than last time, and again bails out if they're the same
- The handling for `mapState` and `mapDispatch` is heavily memoized to cut down on unneeded work.
If you have specific performance concerns with a Redux app, please let me know - I'd be happy to offer advice and point you to possible solutions. But, a blanket statement that "Redux is quite slow" is meaningless without context for what's happening.
We now speed things up buy removing redux and just using events with multiple stores anyone can access - we can easily tune the system and don't have to rely on magic that can never be as efficient. Plus the syntax is much cleaner.
I have exactly the same experience and implemented the same solution. An ex-colleague also did the same thing. We both worked on collaborative webapps but in different companies at the time so performance gain was very important.
I still use Redux on some projects but I definitely start the new ones without thinking about it.
Could you clarify what you mean by that?
Per both of your comments: generally speaking, your `mapState` functions _should_ run as quickly as possible. Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those.
If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut down on unnecessary work.
So, in a well-written app, your `mapState` functions shouldn't be bottlenecks.
As I said, if you've got some examples of specific perf issues, I'd be happy to offer advice.
[0] https://blog.isquaredsoftware.com/2017/12/idiomatic-redux-us...
A call to dispatch is significantly more expensive than the update of a JS object
> Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those.
Ideally it should, but in practice it is really much more expensive than getting a value in a JS object
> If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut down on unnecessary work.
I used Reselect before removing Redux. Beyond the fact that it adds a lot of boilerplate it does not help if you do need a lot of data updates.
> So, in a well-written app, your `mapState` functions shouldn't be bottlenecks.
It shouldn't but a few dozen of updates per second through Redux on a mobile take a toll on its performance serious enough to not be able to keep 60fps in a WebGL context.
I decided to remove Redux after noticing the performance overhead per function call in the Chrome performance profiler, so I know that in practice "dispatch" and "mapState" are not comparable to just editing or grabbing "a couple values from the Redux state"
My ex-coworker had the same issues because he needed to display a lot of items handled collaboratively with smartphones. In both of our cases we have a high rate of data updates, even if we optimize like crazy we are never going to fall under 4-5 update/second per connected user.
So yeah Redux can run well for webapps with a slow/regular pace of update but for more performance sensitive apps you do pay a Redux performance tax.
Again I still use Redux on some projects and I like it but the limits are there. So now I don't hesitate to do without it first and to use it when I need its abstraction.
A good way to test it would be to make a simple websocket server that simulate n users each sending n' fake xyz position and rotation data per second. This data updates a Redux store in a React app made with Aframe (HTML wrapper around ThreeJS). You make n cubes move and rotate along the data in the store. Compare the fps you get against the fps you get with a vanilla solution. Also check what happens on the performance tab of chrome
I am able to recognize that my use case is very specific. I used React/Redux/Reselect and Aframe/ThreeJS with sockets a year ago. Now I kept React but the rest of the stack have changed for nearly a year
If you ever do have some free time to throw together an example app that demonstrates this behavior, please feel free to link it in that issue, or ping me directly (Twitter and Reactiflux are usually best).
I mentioned it in the pull request, here it is : https://github.com/Kalkut/redux-data-frequency-benchmark
> I fail to see what problems this approach solves.
You are absolutely right I gave an ad-hoc Redux as an example of Higher-Order Component.
Being OOP or not is only a matter of implementation of your data source. Here you have absolute control on it and depending on the type of your data, the frequency at which it is updated or its (a)synchronicity, you may prefer/need something very different from a dispatcher/action/reducer system.
The real pattern here is the HCO and yes Redux also use this pattern to build "smart components" with "dumb" ones. But it does it in a very opinionated way.
As an example : for performance reasons you really don't want Redux to handle real-time data with very frequent updates, it is better to manage this kind of data your own way.
A more common case is having only a few amount of data that have to be shared across the tree (things like an user session or the chosen language). If your component tree has too many level of depth an ad-hoc solution can do fine here.
IMHO there is two type of arguments for why Redux might not be needed :
1) A reasonable UI respects separation of concerns.
There should be limited need for data exchanges or interactions between two unrelated components. Making the data flow from the local state of a "smart component" is fine most of the time.
2) What Redux does can be done with less boilerplate when and where it is needed.
You can make your component "smart" in a lot of ways. It can be done with pure React state management, it can be done with custom data sources and HCO, it can be done with JavaScript CustomEvents and so on.
The worst problem here is that because Redux is a (very good) opinionated abstraction, lots of developers forget it is a library and not a framework so they try to find what they think is the most Redux-way of doing things. I've seen tons of projects that ended up being a mess of Redux/Thunk/Reselect plus whatever middlewares where updating a single property implies at least handling it in the reducer, adding a selector, and adding the result in mapStateToProps. Redux is definitely not a bad solution but in becoming a standard one it hurt a lot of projects.
This situation is very well explained by pcstl above when he says
> People mainly use Redux because they don't understand that React isn't Angular.
> Redux is what you get when people try to use React as a "full-app" framework instead of what it's meant to be: a view layer.
Is Redux not exactly that?
Your application's state should live outside of React, and be passed in as the root's props.
Redux should have your application state, and any UI state should be in pure React (portals, context, etc).
Redux -> app data React -> UI
Ironically, Redux came out around the time Angular popped. While not everyone, a significant portion of early adopters came in because they were rejecting the Angular 1.X way of handling state, and Redux was the polar opposite.
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 orthogonal trees.
If you are a front end dev and you haven’t spend time wrestling with that, I strongly recommend it. It’s extremely likely your front end architecture is suffering because of it.
React take the strongest stance on this matter, by making the interface to every widget be one giant shared global. But globals are bad, so while it’s good they acknowledge the situation, they mostly punt on the question of how to deal with it.
>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.
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.
Oh well, at least Web Components seem to finally be around the corner, a decade later.
https://thedailywtf.com/articles/Sketchy-Skecherscom
The featured comment at the bottom is from the original devs.
One of the early comments is that it only worked properly on Firefox, which is wrong. IE6+ had excellent, extremely fast XSLT support.
The company I worked for at the time actually had an enterprise app that didn't work properly on FF as it relied on some IE only functionality, some sort of VBScript controls you could embed in IE that I forget the name. They dropped support for them in IE8 or 9. The app was otherwise excellent, basically a sort of dropbox + basecamp for the construction industry before dropbox + basecamp were even made, users loved it. The founding developer was the best developer I have ever known (his quirk was that he'd often forget to rename his functions after prototyping something so a lot of his methods were called Something or Thing or Something2 and we'd have to rename them later to make it clear what they did).
We had a SQL helper that would allow you to write XPath in the SELECT names something like this (I have totally forgotten xpath by now, but hopefully you get the jist):
SELECT c.CompanyId [@companyId], c.Name [@companyName],
o.OrderId [/orders/order/@orderId], o.Name [/orders/order/@name], o.Quantity [/orders/order/quantity]
FROM Orders o
JOIN Company c ON o.CompanyId = c.CompanyId
ORDER BY c.CompanyId
<companies>
<company companyId="1" name="thing">
<orders>
<order orderId="142" orderName="Sally's Order">
<quantity>1</quantity>
</order>
<order orderId="156" orderName="Sally's Other Order">
<quantity>1</quantity>
</order>
</orders>
</company>
<company companyId="2" name="different company">
..etc
</company>
</companies>
Because you had the XSLT on the page, you could make it dynamic, just post back for the new XML on a drop-down change, button-click, etc.
Another story from there is that they made their own version of jquery just before jquery rose to prominence. It was a nightmare to debug, that fully got me onboard the jquery train.
however it's also really too trivial and really straightforward and boring as a piece of code to be mentioned as a WTF, having difficulty understanding that code would just be a case of not understanding the language, which is also a thing that happens.
The context of that article was more that doing XML/XSLT at all was a WTF.
Agreed. Possibly a microsymptom of the "business only does boring things, developers do interesting things" mindset.
In my experience, one needs to constantly guard against thinking anyone else is mindlessly turning a crank. In fact, they're likely doing just as complex and interesting stuff as you, only with different tools.
Same. Long ago I replaced an expensive Crystal Report solution with reports delivered as XML/XSLTs that used IE's feature at the time of applying the XSLT at the browser. It worked very well and provided nice interactive reports. I also wrote a bunch of cookbooks (for lack of a better term) that allowed the business analysts to create additional reports.
Pierce? Is that you?
Because React = state to DOM while Redux = how to get from previous state + action to a next state? :)
They do different things.
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 React was first created in order to ease people into transitioning to HTML in JS, but I feel like we can move passed that now.
I highly recommend `react-hyperscript`: https://github.com/mlmorg/react-hyperscript
A translation from the JSX example that was the first (only?) example on the React homepage at the time:
https://github.com/jasom/parenscriptx/blob/master/example/co...
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.
> "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 enough on the matter to say if this is or isn't, and to compare vs Angular, etc. But don't blame the author for this one ¯\_(ツ)_/¯
<Component v-model="foo">
<Component :value="foo" @input="foo=$event">
All props form a one-way-down binding between
the child property and the parent one: when the
parent property updates, it will flow down to
the child, but not the other way around. This
prevents child components from accidentally
mutating the parent’s state, which can make
your app’s data flow harder to understand.
AngularJS uses two-way binding between scopes,
while Vue enforces a one-way data flow between
components. This makes the flow of data easier
to reason about in non-trivial applications.
As other people mentioned, Vue indeed doesn't have two-way binding, and v-model doesn't have the pitfalls that Angular had. It is just syntax sugar.
Maybe it's about time Vue people remove the mention of two-way binding from their websites, since it is being used to attack the framework. I've seen that in other discussions here in Hacker News.
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 Store deals with the state modification. Once it's done, it calls your pure function again, this time with a different state, so you get a different render.
This IMO, decouples state and and view instead of tightly coupling it. Redux is the best Flux implementation to demonstrate this IMO because it puts all state in a single Store. The messages to this Store can come from anywhere: UI, server, me typing on the console, etc. The state changes independently of the UI and in fact I could have a full application without having a UI whatsoever. Or I could have a UI without knowledge of my state's topography, because Redux lets me morph and cherrypick my state before I pass it to a component as props.
I think that's a good exercise: to try and build an application thinking of it as a series of actions on state first --and then how that may play onto UI-- to get to appreciate functional components. I'm curious to know why you think why you think Redux only "pretends" they aren't though. (:
Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, and isn't just idyllic, agnostic "data". Things like "is this menu open or closed?" and "what's the current string value of this input (which isn't meaningful until the form is submitted)?" In Flux, those things tend to add a ton of boilerplate in terms of change actions, and split tightly-related concerns into separate corners of the codebase (if I remove this menu component I have to remove its open/closed state variable and the corresponding action).
To be sure, there's not really a great way to decouple things in the reactive architecture. I personally lean towards stateful components that are decoupled at their boundaries instead, which does carry its own downsides. The only solution I've ever seen that truly felt right was two-way databinding, which Vue (sort of) still has, but which has fallen out of fashion in general because it requires "magic" and because it tends to come with performance costs.
https://redux.js.org/faq/organizing-state#do-i-have-to-put-a...
The entire UI is specific to the UI. Trying to separate "entities" or "server data" from "UI concerns" is IMO a waste of time and just confusing.
At the end of the day, you have a state tree, and you project it to a UI. Where that data comes from and what it represents doesn't really matter. Events in the UI generate an log that can get folded into new state to then be projected again. These events could be generated by a button being clicked, or an XHR request completing, but that doesn't change the nature of the payload.
One important thing though, in most of these models, the state shouldn't be "is this menu open or closed". It should be "Is the user focused on an arbitrary task or not". The menu being open or closed is a projection of that. This way when your designer comes and says "No, this thing shouldn't be a dropdown menu anymore, it should be a modal", you don't feel the need to rename your arbitraryMenuOpen: true state key to arbitraryModalOpen: true instead. Saves a lot of time.
Elm is a pretty good example of how all of this works. Its fairly different from Redux and co (even though it inspired it a lot), but its interesting to see how all of these things absolutely can work. They get messy when retrofit into React and JavaScript, but it's not an issue with the concept, just the implementation.
In fact, the reason we have the particular toolbox of standard GUI elements that we have these days is precisely because they serve different use-cases. Each serves a particular one, and the reason it's survived is because it isn't made redundant by any of the others.
The only thing not practical about it is that in these days and age, the amount of people with data modeling experience is low. But it totally does work in practice and is, IMO, the only way to really be productive with Redux. Otherwise any change you make or any new feature requires modifying components, actions, AND reducers. At that point you're just doing 3 times the work for everything.
Wait, they don't though. That's the whole point of functional components. They are of the form:
const Component = (props) => <JSX />
> 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).
This isn't bi-directional binding. state determining UI, UI sending queued actions and actions determining state is one-way data flow. Bi-directional coupling would be tying a reference in the state to a UI element.
> Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, and isn't just idyllic, agnostic "data". Things like "is this menu open or closed?" and "what's the current string value of this input (which isn't meaningful until the form is submitted)?"
This is architectural, and is why components have their own state. Its up to you wether you want to keep this as application state or local volatile state.
> In Flux, those things tend to add a ton of boilerplate in terms of change actions, and split tightly-related concerns into separate corners of the codebase (if I remove this menu component I have to remove its open/closed state variable and the corresponding action).
Which is why I don't put it in the main application state (:
> To be sure, there's not really a great way to decouple things in the reactive architecture.
I mean, not if you're dumping everything on your application state, no.
> I personally lean towards stateful components that are decoupled at their boundaries instead, which does carry its own downsides.
Curious to learn what you mean by "decoupled at their boundaries". You mean components that are de-coupled from each other? You can make re-usable, functional or stateful components that are de-coupled from application state.
I think the main takeaway here is that not all state is the same, there's state that's part of your core application logic and state the component needs for its display only. Treating them as the same thing does limit the re-usability of your code and make dealing with your application state tedious.
> The only solution I've ever seen that truly felt right was two-way databinding, which Vue (sort of) still has...
There's other solutions (: I don't think Netflix, Facebook or AirBnB have all the state of their menus tied up with the state of their user data and and have all components be use-once because of that. Good state management can make things scale, and functional components very useful!
> but which has fallen out of fashion in general because it requires "magic" and because it tends to come with performance costs.
Yup. It's also hard to know where or how certain state is changing. It definitely allows you to build small applications very quickly, but it doesn't scale all that well.
React is just JavaScript and HTML.
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.
This is patently not so.
Vue has:
- three different html-like attributes
- three different scripting languages in templates (two Javascript-like, one Javascript, but only expressions)
- one scripting language for controller/model which actually breaks JS assumptions (about what `this` is, for example) by magiacally hoisting some (but not all) properties of an object
This is patently not so.
- three different html-like attributes
v-bind and v-on (and v-if) accept regular javascript, and it's not just expressions... you can use `active = true` to change a data value, for instance.
The only exception is v-for, as you mentioned, but it is close enough to ES6 for syntax to make sense, at least IMO.
- three different scripting languages in templates (two Javascript-like, one Javascript, but only expressions)
- one scripting language for controller/model which actually breaks JS assumptions (about what `this` is, for example) by magiacally hoisting some (but not all) properties of an object
> accept regular javascript... The only exception is... but it is close enough to ES6
So you basically validated all I've said. And it's also incomplete. Because the amount of gotchas and things that you have to constantly keep in mind in Vue is mind-boggling compared to JSX. Because JSX is a paper-thin wrapper on top of React.createComponent, and goes out of its way to keep everything in Javascript. Unlike Vue.
Lets see your defence:
- : and @ as shorthands
It means new syntax that you have to learn, and know differences between. For all intents and purposes Vue has three different types html-like attributes. JSX has only one: javascript names.
- v-bind etc. accepting regular Javascript
Let's see how this is false:
<label @click="edit(todo)">
- exception is v-for, as you mentioned, but it is close enough to ES6 for syntax to make sense
So, it's not Javascript (unlike some other places where it is Javascript), and it's not ES6 syntax, but it's "close enough to ES6". So it's not. It's a different Javascript-like scripting language.
The only place where Vue allows regular unadulterated Javascript is inside curly braces: {{}}. And there it only allows expressions (Note: JSX also only allows expressions inside curly braces).
However. Even there it's not Javascript. Not really:
{{ record.commit.message | truncate }}
- You mean the script part of components? Do you have any examples of that?
Of course. See inline comments. Example from here: https://vuejs.org/v2/examples/tree-view.html
Vue.component('item', {
template: '#item-template',
props: {
model: Object
},
data: function () {
return {
open: false
}
},
computed: {
isFolder: function () {
// `this.model` magically hoisted into `this`
// from `object.props.model`
return this.model.children &&
this.model.children.length
}
},
methods: {
toggle: function () {
// `this.isFolder` magically hoisted into `this` from
// `object.computed.isFolder`
if (this.isFolder) {
// `this.open` magically hoisted into `this` from
// `object.data` which is a function that
// returns an object whose keys and values are hoisted
// into `this`
this.open = !this.open
}
},
changeType: function () {
if (!this.isFolder) {
// this.open can be set directly. Magic
// this.model.children cannot. Not magic
Vue.set(this.model, 'children', [])
// `this.addChild` magically hoisted into `this` from
// `object.methods.addChild`
this.addChild()
this.open = true
}
},
addChild: function () {
this.model.children.push({
name: 'new stuff'
})
}
}
})JSX is actually just JavaScript with this one special rule:
<foo bar={baz}>child1 {child2}</foo>
transform("foo", { bar: baz, children: ["child1 ", child2] })
<label @click="edit(todo)">
You're wrong. The contents of the event handler is JS, the whole snippet is obviously HTML.
<button onclick="alert('Hi')">Say Hi.</button>
> This is also plain regular HTML and has been since HTML4 (1997).
What below is plain regular HTML? Taken from here: https://vuejs.org/v2/examples/tree-view.html
<div
:class="{bold: isFolder}" <--- binding to JS-like objects doesn't exist in HTML
@click="toggle" <--- If it was HTML it would've been toggle()
@dblclick="changeType"> <--- If it was HTML it would've been changeType()
{{ model.name }} <--- etc
<span v-if="isFolder">[{{ open ? '-' : '+' }}]</span>
</div>
For reference: https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Ev... etc.
Edit
Let's add more "plain old HTML". Plain old HTML v-ifs that accept JS booleans. Ah, plain old HTML v-fors that accept a ES6-like (but not truly ES6) mini-DSL. And other plain old HTML attributes.
<ul v-show="open" v-if="isFolder">
<item
class="item"
v-for="(model, index) in model.children"
:key="index"
:model="model">
</item>
<li class="add" @click="addChild">+</li>
</ul>> <label @click="edit(todo)"> > This is not Javascript. If it was, it would assign the result of the function call to @click. It doesn't. It's a Javascript-like scripting language that has magical binding into regular Javascript.
Great, so it's not javascript.
To a lot of folks it looks a lot nicer than
<label onClick={() => this.edit(this.state.todo)}>
There's a lot less noise, and it's _much_ friendlier for (most) designers.
I have never felt that I had to keep hundreds of gotchas in my mind while using vue. The syntax is extremely intuitive (unlike angular). Takes maybe one hour to read through the docs, and you have it.
Have I ever mentioned apollo or graphql tools? Let me check: no
> There's a lot less noise, and it's _much_ friendlier for (most) designers.
I love how you could find exactly one thing out of a whole list of things that may be just ever so slightly better than JSX.
And of course, it's not better than JSX for very obvious reason that you chose to ignore: how { } in JSX accepts plain JS with the only exception that it has to be an expression. And (and it's the most important part): curly braces in JSX mean and accept the same thing everywhere in JSX.
In Vue though: What do @ attributes accept? What do : attributes accept? What do curly braces accept? etc.
> I love how you could find exactly one thing out of a whole list of things that may be just ever so slightly better than JSX.
It's not a question of "better" or "worse". It's a question of tradeoffs on spectrum of abstraction.
I'm not here to bash JSX or react. But you apparently are, and I'm just trying to open your eyes a bit.
When vue came out with JSX, I tried to force it on my team, and there are a serious backlash, to the point where I came to realization that the vue's major strength is actually the templates, and the magic.
You may not like the magic, but a lot of folks do.
As for your specific questions
@ and : are just short hands. That's like saying: what's the difference between `map` vs `reduce` in my component to iterate over an array. They _can_ do the same thing, but map is shorter. In plain JS I can do `i = i + i` `i += i` or `i++` to increment an variable.
@ just means "event handler". @click = "onClick" : just means "use a dynamic value for this prop { } you can put any JS expression, with the plus that you don't have to litter your code with `this`.
Yes. But just because it has that potential, doesn't mean that Vue's DSL(s) are not without the many problems anf gotchas I described. Just because Apollo's/GraphQL's DSL is potentially good, doesn't mean that Vue's is. etc.
> It's not a question of "better" or "worse". It's a question of tradeoffs on spectrum of abstraction. > I'm not here to bash JSX or react. But you apparently are, and I'm just trying to open your eyes a bit.
My eyes are wide open. Where in JSX I see a uniform approach that works in all JSX contexts, in Vue I see several DSLs bound together by magic of the library.
> @ and : are just short hands. That's like saying: what's the difference between `map` vs `reduce`
Shorthands mean:
- new syntax. For all intents and purposes it's a new syntax (call it a DSL syntax). And you have to know the difference and gotchas of that syntax. You have to know where you can:
-- provide a thing that looks like a function ref
-- provide a thing that looks like a function call
-- provide a thing that looks like a bound variable
-- provide a thing that looks like a Javascript expression
etc. etc. etc.
And that is further compounded by the fact that `v-` attributes sometimes take single Javascript-like expressions, sometimes not (v-for), some have additional "arguments". some have additional modifiers etc. etc.
And of course, some of it is Javascript expressions inside strings (`v-` attributes), some of it is Javascript-like (but not really Javascript) DSL inside mustache's curly braces (inside tags).
So here's the original statement that started this thread: "The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX"
This is demonstrably provably patently not so, as this thread has demonstrated.
> with the plus that you don't have to litter your code with `this`.
"Littering code with this" is exactly how plain old vanilla JS works. Besides, "littering your code with this" very much depends on where your callbacks and variables come from... as in any old plain vanilla Javascript code. Because JSX is a paper-thin DSL on top of vanilla JS. Brilliantly and succintly described in this comment: https://news.ycombinator.com/item?id=17474370
In Vue you don't litter your code with this. You litter your code with hoisted variables and functions that are arbitarily hoisted into scope and injected everywhere. See my comment here: https://news.ycombinator.com/item?id=17471199 starting at "Of course. See inline comments."
The amount of gotchas and special syntaxes, and special cases, and the amount of moving part you have to understand to see where things come from and go to in Vue is insurmountably larger than in JSX.
So e.g. if you want to have a Leaflet map i.e. `this.map = L.map(...);`, Vue will automatically add reactivity to this property. Sometimes I had big problems with this behavior (or it was simply annoying), so I wrote vue-static based on ideas of the core developers:
https://github.com/samuelantonioli/vue-static
Now I can have big objects in the Vue component which don't get automatically tracked using the reactivity system.
- - -
A problem for many beginners:
Another problem with the reactivity system is that sometimes you have a route like `/employees/:id` and edit an object. But on abort, you want to rollback. One thing you always have to do is to copy the object you want to edit (I use lodash's `_. cloneDeep(obj)` for this). If you use Vuex, it's not such a big deal because it works using immutable state, but when you work with a plain javascript object this will definitely generate some headaches.
- - -
But otherwise, I think Vue is definitely the way to go. `v-model` can be seen as syntactic sugar while you have to add it to react inputs and textareas manually (using onchange and setState).
You can write stateless Vue code just fine and use JSX. On the other hand, React misses some of the cool features like the Vue component files (.vue files) and its templating language. And the best is: The framework doesn't say that you have to use it. It's not so opinionated but still feature-complete with the official plugins.
- The reason the API call is made at `created` lifecycle is that the video is a quick, 5 minute intro for beginners. Beginners, as in "people who are familiar building static websites using html/css/js". There is no need to bring in Vuex or vue-router yet. In fact the whole beginner example can be put into a single HTML file by including a Vue script tag. The approachability is what made Vue shine. Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work.
> To answer to my initial question: API logic should not be written in Vuex nor in components. There is even a good example on how do that in some of the official code examples.
- The example[0] clearly has the API logic in the Actions. The `/api` folder is a mocked API for illustration purpose.
[0]: https://github.com/vuejs/vuex/blob/dev/examples/shopping-car...
Okay, say I do the tutorial and build a simple page - how hard is it to retrofit routing or whatever to it? A lot of the time with new frameworks, if I get past the initial setup hurdle, I can't work out how to easily move away from toy apps to something I can use in production.
Example 1: A great typographer, Wenting Zhang, author of Type Detail[0], contributing to Source Han Serif, learning Vue to do some interactive widget for variable fonts[1].
Example 2: Brian Terlson on TC39. He's using Vue without Vuex or Vue-router to build an app to track TC39 discussions[2].
I hope we can admit that many people might not need store and router[3]. Store and Router are necessary for building complex SPA, but don't make them necessary, as many don't want complex SPA. They impose learning efforts in exchange of better architecture, but the imposed effort might not be worth it for many people who just want some data-rendering, some reactivity and some interactivity on their websites.
[1]: https://twitter.com/DesignJokes/status/1015003288528400386 and https://twitter.com/DesignJokes/status/1014260361535647744
[2]: https://twitter.com/bterlson/status/913433979239436293 and https://github.com/bterlson/tcq
[3]: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Previously on vue-cli 2.x, it was just a question on the project initialization step.
This clearly outlines a suggested structure for non-trivial apps, where API requests are separated from the state management. It also references the Shopping cart example as a guide.
Due to this glaring oversight I can't see any criticism the author has as valid in the section about "Unclear architectural patterns".
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 varies pretty wildly. I think this is just the reality of a young framework casting a wide net, we'll see what the future brings.
It's not perfect, but like the author, Vue was a great decision for my team.
Most Angular devs I know are happy to use TypeScript. (In fact going out on a limb, most JS devs I know).
Will be using TypeScript. For internal implementation only. Does NOT affect ES users, but should improve TS integration for TS users.
An example of this is how in Redux, anything that uses the state in TS needs to add an annotation to type the store, because its completely decoupled (and thus theres no way for the state type to "follow"). Any way to make it follow requires some API changes (eg: creating mapStateToProp functions by calling a method on the store)
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.
I hear this line a lot, and it reminds me of Warren Buffett's line about finding out who's swimming naked when the tide goes out. He's referring to unprofitable companies that get exposed during economic recessions, when their stock prices are no longer boosted by generalized positive sentiment (I'm oversimplifying).
In this context, I think frameworks get exposed when big company support gets withdrawn. Angular didn't always look like an abandoned beached whale. Initially, having the backing of Google made it look like a de facto obvious choice. But when support from a large backer wanes, it quickly accelerates the demise of a framework as what the halo effect previously presented as well-considered design choices are suddenly recast as clear mistakes in hindsight.
This might never happen with React. But if it does, it will be swift and loom with unmistakable signs in the rearview mirror.
1. Js doesn’t support immutable data structures so trying to return a deeply nested model using spread and other things was ugly. The answer seems to be “flatten your data”. I didn’t have to flatten my model with vuex. Vuex uses mutations when I can keep a flat model of observable but also keep my pristine model that I can send back over the wire with no changes . I suspect mobx may do the same sort of thing for vue. I feel like the react pattern would work better with a language like clojurescript that actually has immutable data structures.
2. Prefer html to Jsx although vue does support jsx. Admittedly this is just a preference thing.
3. Less boilerplate. I felt like I was writing more code that didn’t really do anything useful in react/redux. Vue seemed to have the smallest ceremony to code ratio.
4. Vuetify seemed a lot easier to use and was more polished than the react counterparts. I know it’s just a widget library but I found it fantastic and the docs were great. Vue slots are a great idea
5. Documentation . Vue has second to none documentation and this is important when you are starting out
I build a medium sized app in vue and was astounded that I literally did not run into one issue. That has never happened to me in 30 years. Kudos to that team.
6. React router was on its 4th rewrite. I can’t deal with constant breaking changes
7. Router and vuex felt more cohesive and integrated into vue
Whatever you choose please do support these guys on patreon!
The JS ecosystem really has a problem with bloat in my opinion and Vue trumps React in the regard (react eject anyone?).
My cofounder suggested I check out vue for the rewrite of our legacy project, and I was able to onramp SO easily. I can easily hand off components to other team members to write, and it rarely broke stuff in the rest of the project. On the whole, vue feels a bit less powerful but a LOT simpler to wrap your head around while subscribing to the reactive UI paradigm.
For example, JSX is an abstraction level I'd like to use. It requires an npm install to set up to contribute to production code. It has already crossed the threshold of an easy on-ramp for say, an intern -- because if this involves a first-time npm set-up on their machine, there goes the rest of the week.
With Vue to start using another feature/abstraction layer, you never have to do additional setup (your html file includes the vuejs script already), you just read the syntax docs and get going.
Additionally, React (and redux even more, yes) involves much more boilerplate than Vue does for every new feature you want to use, which is often more verbose/obtuse and hard to parse for a junior web developer.
Sorry, in your last post you specifically mentioned only terms that apply to Redux. React has no concept of actions, reducers, etc.
If you read my top comment I specifically talk about React’s function component, which is the least verbose way to describe an interface across any framework. Unless you can think of something easier than (props) => <h1>{props.name}</h1>
Honestly you just need new interns.
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-router, and redux, and on almost every occasion something from my last attempt was broken because the api had changed, and the documentation changed with it (in the span of 3-4 months). That lead to several WTF moments. IIRC there was a period where react-router made some breaking changes from v2 to v3, and then less than a year later made more breaking changes for v4.
Vue is also a lot simpler to drop into an existing application. The .vue single-file component is very approachable, albeit a bit magic but about as magic as JSX. You can add a vue-loader for sass/less/etc. and simply specify lang="less" in these as well.
Vuex was a little easier for me to grok, although I had the advantage of trying out redux first. It has the advantage again of sharing documentation with the rest of the project.
Also, because react has worked for big companies as you mentioned, does not mean vue couldn't work for them as well. React gained a lot of momentum early among western programmers. Vue first gained traction in Asia - Evan You, the creator of vue, is from there. Also you might remember the massive amount of confusion for early React adopters regarding how to manage state. People liked react, but it only really had the view part ready out of the gate. Facebook's explanation of what the early-best-practice flux model entailed was vague, and there were several slightly different implementations.
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).
You can't really have it both ways though: if you're going to say React doesn't do all those things then you have to accept that people who want something more streamlined and comprehensive should legitimately look somewhere else, and React is only for people who want to spend the time assembling their own solution (for some acknowledged benefits). Vue has taken the more comprehensive approach while still being pretty flexible, and therefore suits a slightly different (but I would argue, broader) set of people.
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. You did ask originally what makes one easier to learn than the other.
> to give people to freedom of choice to choose or omit other libraries or frameworks. [...] Those pieces of functionality were easy to implement on my own.
And I listed some problems that I had using those other frameworks which were recommended to me. "Just do it yourself" isn't exactly helpful.
> (Redux itself is incredibly small)
Ok, but it has had some API churn as well - EDIT: I was wrong about this. See replies.
There's definitely boilerplate that goes along with it. There are libraries that deal with that to an extent, but there are many. Which one does someone learning choose?
> I remember working on Angular 1 projects...
What's that got to do with Vue? Vue isn't Angular.
> Personally, I think it's silly to use Vue. I mostly hear either minor grievances from the Vue crowd
I gave you my examples. You seem to compare only the view layer functionality. I'm examining the ecosystem and preexisting examples of how to implement functionality, which is going to be important for someone new to the library. Of course you can write this yourself, but for people trying to learn React, only having the view layer makes it more difficult to figure out how to "implement it on your own".
> I also don't think Flux was vague, it just lacked an implementation.
Not having any public implementation is pretty vague!
> There just seems to be a big fear in the JS community about writing code instead of pulling in a framework
Well, again, my response was from the perspective of someone learning React and how one might architect a SPA using it. As stated, there was no official flux implementation in the beginning, just a diagram from Facebook and some hand-waving documentation. Vue has official and router library and state management library which are linked to from the official documentation.
> 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).
You can apply this your own argument. React is just reactive functional programming. Why just pull in a view library when you can just render using functions? Why not write it yourself, if you're writing everything else yourself? Are you afraid to? Why include a 240kb library to render functional components?
What do you get out of using React over Vue, which also uses the virtual DOM and has functional components?
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.
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).
I'm curious whether Facebook actually have any endpoints where exceedingly fast rendering is necessary because it'd be the bottleneck. Facebook tends to be really slow for me but I figure that's down to it being really slow fetching data.
I wasn't aware that vue3 was going to be written in Typescript - that is very welcome news.
We've built our single page application (SPA) web app with vue.js and are very pleased with the results -- https://checkoutclip.com. We were able overcome most of the stumbling blocks by looking up https://vuejs.org/v2/guide/, https://github.com/vuejs/vue/issues and https://forum.vuejs.org.
For server side rendered (SSR) pages, we're using nuxt.js, which is working out great as well. E.g. SSR page: https://video.checkoutclip.com/-LDQ5TtL_yywYCgUNb6K
I would recommend vue.js for anyone building their first SPA even if they don't have prior experience building one...it's easy to pick up.
vue is used only for the web app. No js frameworks used in the chrome app.
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 complaints. This one is more "brave" but I use Modernizer and show a clear message outlining all the required features the user's browser doesn't support and why they would want that feature in a browser. There's a link to a website to help them find a modern browser on their platform.
Edit: I realised that based on what I said you could argue that users are annoyed but I'm just not aware. I doubt this is the case since the users are keen and vocal. I get messages almost daily from them telling me the features they want to see. The last time this had to do with browser support was one message 3 years ago about IE9 not supporting the TLS certificate or something. They were forced to use IE9 at work.
> I doubt this is the case since the users are keen and vocal. I get messages almost daily from them telling me the features they want to see.
Maybe existing users (and even for that, I'm skeptical), but how many potential users did you lose because they couldn't even open your app?
I'm not saying you are wrong, just that "users didn't complain" != "users weren't affected".
And I wouldn't miss you.
I can make the service better faster if I don't support the lowest common denominator. I'm sure I'd lose more users if the website was bloated with fallback code and my development speed was such that features are a year behind where they are now.
You're making the assumption I don't have and use data like that? That's an incorrect assumption.
It has been my experience that I've gained more valuable insight from talking with users than I have from the numbers.
But, as a little Latina girl once said, why not both?
I absolutely hate the "does it work on ie6".
The time you spend dealing with old browsers is never returned in profit. I had one customer (ie10) in 4 years, and losing him cost me and made me nothing.
I haven't tested myself (I'm just one dude - there's a lot I'd like to do but haven't yet), but I see no reason why it wouldn't work well. I try to design semantically and everything is rendered server-side.
But, in reality, I don't think this is the kind of website that would be usable for a blind person anyway. There's not really anything to read. There would be much better ways for a blind person to get information than using this website.
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 alternative ways to get information - if there's ones you can link to (without linking to a competitor or whatever), there's no reason not to provide links.
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:
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 enough to use this website.
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]
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.
0: https://www.freedomscientific.com/Products/Blindness/JAWS
Edit: using a screenreader effectively is a skill in itself. There are consultancies around accessibility testing. I am not affiliated with any of them.
We don't complain, we just go somewhere else.
https://en.wikipedia.org/wiki/Fault_tolerance
Progressive enhancement:
Then please have a noscript tag.
> Serious question: is it common for folks to disable js?
That's not the only reason you'll find for JS being unavailable.
Windows Updates has managed to disable JS in various situations across both Edge and IE over the years due to tightening security policies.
Chrome has had V8 crashes over the years, as has Firefox.
The browser might be misbehaving, but rarely will the user attribute it to the right place - your site will get the blame.
JavaScript-only is not friendly for SEO.
> The single best improvement I've made to my mobile browsing experience in years wasn't getting a new faster phone, it was installing Brave and disabling javascript. [1]
To be honest, (s)he was right. But at the same time, it's disgusting, and plainly bad, to see how much of the Internet is _broken_. Which by my definition means requiring JS even to show some text and images on a web page.
I understand that more advanced features might require some scripting, but come on, I'm pretty sure that's not the case for printing some good old letters and pixels on a browser window! And still, lots of places seem to not know how to do it without dynamic code all around. (I'm not talking about this specific site, in any case. Just felt like ranting.)
I'm also not familiar with vue so I was trying to work out if it was used to build your web page or the actual chrome app. The web page is fine but I just wasn't sure where vue came into the picture for such a simple site.
With that said, the new vue-cli uses Webpack 4 now which can do code splitting, and you can code split on route also to make individual page bundles smaller.
Saving the site on the hard drive gives me a wooping 10Mo for a home page. with a menu, a few pictures and some text.
This is insane.
There are some things I really, really hate about React. It is not kind or accommodating (Vue is both of these things), but it gives you control. I was head-over-heels for the first few days of using Vue; "breath of fresh air" is exactly the phrase I'd use. But the project I was using it for was an IDE of sorts, and eventually I just needed more control than it allowed for.
If someone told me they were going to build a basic website - not a web app - with React instead of Vue, I would laugh at them. Vue truly is a successor to jQuery for the reactive age. But for really complex applications, it's too "magical" in my opinion.
With ember you got controllers, models, inheritances, many special methods...
The VueJS documentation also makes it easier to get in. The Ember beginer tutorial starts with a full fledge app with a cli to install and use and features routing and addons O_o
All that templating and two-way-binding stuff.
Sure, Vue goes a bit more in a lean direction, because it doesn't offer as much out of the box as Ember, but the idea behind the components seem to be similar.
React or Angular (>2) have entirely different approaches, from one another and from Ember/Vue.
They felt fresh to me.
How long have it been since you at least looked at Ember?
> With ember you got controllers, models, inheritances ...
You use those now only when you choose to or not at all.
> ... many special methods
= adding features Vue does not have.
> The Ember beginer tutorial starts with a full fledge app with a cli to install ...
Ember-cli is something everyone is desperately trying to copy. Even Vue!
Sorry, but this sounds like generic anti-JS-hate: tons of misinformation to bash something you have no clue about.
Mithril.js is a framework that is truly "magical" in my opinion. I mean its 8kb, includes routing and XHR Utilities out of the box. Faster render times than Angular, Vue and React. You can write HyperScript or JSX. The syntactic variants allow you to write your components as ES6 Classes or closures. Lifecycle methods, a render and mount option and the list goes on and on. People tend to dismiss Mithril because it's a lesser known framework but it has a vigorously thought through programmatic approach and you've got a direct line with the maintainers, you cannot match that.
Sure, each to their own but calling Vue "Magical" is an incorrect assessment.
When I ran into an issue using React, tracking it down was extremely difficult (by the end it was just "difficult" due to improved tooling around react). Mithril is small largely because of its simple implementation, which makes debugging a joy.
1: They seem to mean magical in the sense if "I'm never going to understand how it works"
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 suggestions. "vuejs computed property" vs searching generic terms.
>Chat based community
This part is simply not true, there's tons of individual vuejs communities all pretty decent. Shoot me for saying this but laracast isn't a bad option for Vue help. Everytime I have an obscure problem I find a solution on there.
>The reactivity system will only track changes under certain conditions. Don’t expect to throw anything you wish at it
This is the one part I hate about vue.
>Does this mean authentication logic goes in Vuex too? Will a state manager start mediating all application logic now?
Been there done that. I typically use vuejs for lightweight applications solely because I do run into this issue.
What tutorial are you using? How old is it? What didn't work?
Vue 2->3 won't be so bad because they're promising backwards compatibility.
https://www.adcisolutions.com/knowledge/how-build-single-pag... https://codeburst.io/full-stack-single-page-application-with...
The first one doesn't build, if I remember correctly, and the second doesn't display anything after about the halfway point. I'm running them on MacOS.
I tried a couple of others with similar issues, but didn't save the URLs.
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?
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.
>This is the one part I hate about vue.
Haven't used Vue for a while, but if I recall correctly it will only track changes on keys defined in the original data object. Is that what you and the parent are referring to?
Don't know how vue compares with this but for angular beginners this is a very common mistake.
I dislike that Vue feels too much like Vue and its magic and not enough Javascript. With React I feel like writing normal ES6 Javascript.
I love the official Vue documentation and examples.
I am a bit cautious about the ecosystem surrounding Vue. About a year ago when I looked at various interesting projects/tools extending Vue it seemed most of them were in China with very limited English documentation.
Finally the job situation for front-end work. In my region it seems to be about 75% React/20% Angular/5% various(Vue rarely mentioned)
> This trend of using chats for questions is plaguing open source projects and I think it needs to end. There is no collective learning anymore.
This is a very important notion not least of all from an archival pov.
That's basically Reddit
I don't know how many times I've found answers for versions of my libraries/toolkits that are so old that they're useless. There's little point these days in persisting answers to questions about Node 0.4.0, for example - and that's only ~7 years old, downright modern by some viewpoints.
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.
Ok, but where's an example that shows how this backfires? Why should the API logic not be written in Vuex?
One more thing I think deserves mention: Vuetify - Vue's material design component set. It's being used in the project I'm currently in and I worked with Angular's material design component set and I have to say the former is way better built.
(Author here. I didn't really expand on that because the article was getting pretty long already.)
For example, think about authentication logic.
It involves more than just calling the API. Eg: extracting the JWT, saving it to localStorage, decoding it, maybe checking user roles, etc.
If you do that kind of logic on Vuex actions then these will start being responsible for a lot of your application. If you are fine with that, by all means, use Vuex actions to do (a lot of) stuff not really related to managing state.
Personally I don't think it makes any sense to delegate that kind of logic to Vuex in the same way I won't use Axios for anything other than making HTTP requests.
There are also practical aspects. Vuex actions need to have a very particular signature, since you never really call them yourself. To me that was the final reason for moving a lot of logic to their own modules.
In my latest projects I've almost stopped using Vuex actions altogether and it feels really good. Authentication is not managed by some parts of Vuex, but by my own auth module.
It then has some getters which just get the state from the store, but the actions call to a separate module which manages storing it in LocalStorage or making the http requests.
Works for me, but I just took what I learned (Vue) moved it to when I learned a year later (Vuex), when things became complicated in Vuex I just moved the complicated bits back 1 bit more and everything became simple again (which seemed like the logical thing to do).
Although at this point in time it is pretty cumbersome to get the entire Vue stack type safe. I think it's getting better but it's far from ideal. You'll need a wide range of libraries to get everything set up. For instance here's the list of libraries I use for bootstrapping projects:
Vue-class-component - Vue-loader - Vue-property-decorator - Vue-template-compiler - Vuex - Vuex-class - Vue-router - Vuex-router-sync.
The ecosystem just keeps getting larger and larger and for a beginner it can seem pretty daunting. I don't complain though - UI's have become a lot more technical and complex the last 10 years - and of course that'll increase the learning curve of learning how to program them.
I have worked with multiple Vue projects now. The time is spent about 50/50 in pure development and getting the build setup working correctly.
Better pick another tool to do the job which has mature integration with build tools.
Granted, the reason it works well for us is because we started out right by looking at existing templates using Vue + Typescript which probably saved us a lot of hassle. The wrestling with configuration switches was by and large already done for us, but having used this combination extensively now I can say I'm familiar with all configuration matters in our projects and I find none of them particularly poorly documented or obscure.
I really like Vue for the many great strong points it offers. But I'm equally ready to completely ditch Vue for its complete and utter garbage with respect to build/debug configuration.
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
<script src="https://cdn.jsdelivr.net/npm/vue"></script>
vue init webpack my-project
cd my-project
npm install
npm run dev
... Vue has already done the hard work of getting the build apps configured for you.
Probably, but Vue only officially supports Webpack or Browserify.
For all things more complicated and that require intelligence to think about good architecture and how to structure state, the magic of Vuex won't do the job for you, and in fact it will hinder you from doing it. React doesn't have these limitations.
Also, the community on Discord is not friendly, in fact the community and the limitations of the framework are quite similar, they're all "write a todo-app like the tutorial, or I won't be able to help you".
Can you elaborate on that?
I disagreed with the "unclear architectural patterns" -- I've found just writing Vue components that function as Services to hold all that kind of logic more than adequate, and have never really needed to follow the Flux-ish/Vuex approach. 90% of the time all you're doing is making web requests and possibly displaying data or results to the user on the frontend... If you're clever, you're doing a little caching and figuring out when to perform remote fetches, or storing stuff in local/session storage.
I think Model-Service-View frameworks are the (minimal) future, where you just pair a view library with a data management component (something like Backbone, if not Backbone itself). MVC was the dominant paradigm (angular 1 days), then MVVM made an appearance (knockoutjs), and now MV-? where the ? is some event-driven system or flux/vuex style system. I think abstracting to Services allows flexibility at the model-management layer -- if you want your services to send out events (and wire up your components to listen), then good. If you want them to have promised based interfaces, that's fine too.
I tried out knockout's components way back when I saw the blog post[0], and they were pretty nice.
[0]: http://www.knockmeout.net/2014/06/knockout-3-2-preview-compo...
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?
But I guess old habits die hard...
Otherwise, yeah.
Then api.fetchFoo(bar).then() mostly does it.
Benefit is separation of API from component.
(Disclaimer: I use React/Redux and not Vue/Vuex, but I think the above applies equally to both.)
That then leads me to my next question though, if I am using Vuex to abstract the API calls is it bad practice to use Vuex actions for API calls that don't need to be saved into the store?
Sounds like he wants a convention over configuration framework from a barebones DIY from the ground up style framework.
I guess Ember and Angular are more of one-stop-shops in that way.
There's nothing wrong with using chat for collaboration and support. However, using a proprietary platform like Discord for this purpose a braindead move. It's astonishingly dumb to do this.
Listen, IRC is not sexy. But it works, and has been chugging along for decades now - in the same time that a few dozen proprietary chat platforms have come and gone. It's supported by dozens of open source clients and servers, has integrations with all sorts of bots and git and ticket trackers and such, there are dozens of libraries for working with it, and networks dedicated to open source projects. It's a no brainer.
The particular issue called out in this article is trivially solved on IRC. There are a half dozen ready-to-roll public IRC log softwares, and most of your users have clients which are automatically keeping logs that can be restored from if there's ever a service outage on your logger. Hell, if you send me an email I will put my IRC client in your channel and publish public logs for you for free.
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.
Oftentimes beginner would create just a single React component that references the state - which immediately couples the visual parts of your Application to your data, making it harder to introduce automated testing later on. When using the smart/dumb pattern together with react-redux it is very straightforward to come out with a good architecture, that does not mix ui and business logic/data handling.
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?
https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-v...
I want to be able to have essentially have everything server rendered with reactive views. Not sure if there is anything that supports that, but I feel like that's how a SPA "should" work to an extent.
Also, what gets really weird is if you are trying to use environmental variables. The solution is to inject your environmental variables into the client (https://nuxtjs.org/api/configuration-env/) which is what I want to avoid.
I can do what I want to an extent with Ruby and Sinatra, I just want to avoid setting up webpack and babel for getting the reactive components.
All my similar issues went away after discovering that.
https://github.com/egoist/vue-no-ssr
Regarding the "client/server render results do not match" issues: Fixing these is mostly easy in my experience, especially since vue will log the offending dom nodes to the dev console.
My challenge is that I don't want everything to be rendered on the client. I only want very specific things to be client rendered and nuxt does not have a way to do this (I think).
The no-ssr thing is the opposite of the functionality that I would like. I want to have the ability to declare which pieces are only server rendered and sprinkle in in client-side rendering where it makes sense.
[0]: https://github.com/vuejs/vue-class-component/blob/master/REA...
The author refers to the shopping cart sample -- which is exactly what I used as a blueprint. I think that's acceptable that the design pattern suggestion is coming from the store layer vs. the template layer (who is focused on the UI/UX).
You have one component with data. You may bind it do a template. You insert it in the DOM, or in another component, and if the data changes, everything rerender automatically.
That's it. There is nothing more to it.
Their reasoning for why surplus uses real dom nodes seems pretty solid[3]. My oversimplified TL;DR: a virtual DOM mainly solves the problem of JavaScript not being reactive; the DOM already is. So if you have an efficient general solution for adding reactivity to JS, the need for a virtual DOM is reduced as well, and removing it then saves on the performance / complexity / interop overhead that it would add.
And S.js looks like pretty sweet reactivity library, even without surplus - lots of fine-grained control options too.
[0] https://github.com/krausest/js-framework-benchmark
[1] https://github.com/adamhaile/surplus
Oh? I've only ever been in the gitter room... I had no idea there was a discord too...
- why ever choose Vue over a minimalistic React setup?
I mean, yeah, when people say "React" they mean "Reach + a ton of other heavy complex stuff", but core react + redux seems even more lightweight than Vue. Or you'd just choose Vue to keeps way the "React gurus" that would come in and overcomplicate everything? :)
React achieves much more with much less.
Rubs me the wrong way. Better performance is always a net gain, and a high performance website provides miles better UX than the same website with waiting all the time.
I think that's easily disputed: it's always a trade-off. A 0.001 ms improvement in performance is a net loss if makes code 10x less readable, because that means programmers are more likely to introduce bugs, which would be a net loss. For example, I one worked with someone who changed all i++'s in a codebase to ++i's, even though they were not in performance-critical codepaths. That was not worth the effort.
> I one worked with someone who changed all i++'s in a codebase to ++i's
Did you use the previous value of i, or did you just intent to increment it? ++i communicate that I'm not interested in the old value, where as i++ does the opposite. I actually use it as such, because my intent to a future reader of the code is more clear.
That said, for complex types, and with "stupid" compilers ++i can absolutely be significantly faster.
I would consider that a valid reason to use ++i. In this case, however, he indicated performance as being the reason. Furthermore, this was for a school assignment demonstrating that we could properly implement a particular algorithm, so the performance difference was absolutely irrelevant.
It's 2018, we're all walking about with supercomputers in our pockets, and yet we're putting up with <60FPS UI.
The impact of UI performance on user experience is serious enough that Netflix wrote their own rendering engine. https://medium.com/netflix-techblog/crafting-a-high-performa...
I think Vue is great for smaller projects and would absolutely recommend it.
Vue 3 they are moving to TypeScript:
> Will be using TypeScript. For internal implementation only. Does NOT affect ES users, but should improve TS integration for TS users.
I know of two ways in vue to do this and both ways either completely break or make modularity awkward. The first way is to signal the parent with emit. This ties the parent object to a signal and if you want to pass info even further up past the direct parent you have to have components explicitly pass that signal up. While this doesnt break modularity it absolutely makes it awkward.
The second way is to use vuex as a global. This breaks modularity by immediately tying the component to a global. Vuex makes things easy but breaks modularity completely as soon as a component refrences vuex.
I understand why things were done this way. Essentially it's done to prevent a certain class of endless looping bugs but there has got to be a better way.
Can you explain a bit what you mean here?
I haven't used vuex yet, but to use my Redux/React experience as stand-in: the channel to emit data changes through is passed as a prop as well, so the component is still "modular" in that it is not hardwired to redux (or, presumably, vuex). Since it has to connect to the outside world somehow, that can't be the criterium for breaking modularity either. So I don't see where the modularity
Having the data in a Single Source Of Truth seems a sensible reason to store it globally as well.
(aside: elsewhere here I discovered S.js, a reactivity library that looks really interesting. Perhaps using something like that to make the data reactive to UI changes is what you're after?)
Any time you have something reference a global it becomes tied to that global whether it's a function, component or something else. If I want to take that component and move it to another project then I have to take that global and move it along with the component. That is a form of broken modularity.
Passing a closure or global channel from parent to child is not modular. It ties the parent to the child.
Observe function composition, lets say I want to build a function that adds 3 to a number and then adds 2 to a number. I have a base function called f defined as:
f(n) = n + 1
now I create two functions through composition:
g(n) = f . f . f
h(n) = f . f
by composing f 3 times then 2 times I have thus created the equivalent:
g(n) = f(f(f(n))) = n + 3
h(n) = f(f(n)) = n + 2
the final function d(n):
d(n) = g . h = g(h(n)) = n + 3 + 2
Every aspect of my created function is modular and I have maximized code reuse. Vue or React components do not have this property. If I build a UI from vue components, the majority of those components can never be reused while on the other hand my d(n) function is the reuse of a single function composed 5 times. The main reason is because data from the child must be sent back to the parent this either makes the child tied to the parent or the parent tied to the child.
The property of composition is achievable with a single source of truth cascading data down to stateless components that only display the data. Modularity breaks on the feedback loop. Is there a category we can invent that will fit the UI mold?
You can also implement v-model, but I don't think that's what you're looking for.