44 ms·

Vue.js: the good, the meh, and the ugly

• ilovecaching 8y ago
  I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extremely powerful and elegant (just read about gen_server in Erlang or the State monad). I am never a fan of two way data binding as an alternative. It's extremely hard to reason about, and it's not nearly as composable or simple as a tree of functional transformations. So I think that, if you compare Vue to React Component classes, Vue can be quite nice, but the reality is that idiomatic React should have you writing 80%+ small, simple, composable functions with no state, and you really can't get any syntactically barer then that. It's also the way I teach React. When you first see a function going from state to jsx, it really just makes so much sense, and you ask yourself why you'd ever bother with anything else.
  • certifiedloud 8y ago
    Do you have any suggested resources for learning React in this way?
    • ilovecaching 8y ago
      Honestly, there isn't much to learn. It's just a function that takes props and returns a React component (usually via JSX). The only big decision is the props API. https://reactjs.org/docs/components-and-props.html 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.
    • lhnz 8y ago
      My recommendation is to read through this: https://github.com/reactjs/react-basic https://github.com/reactjs/react-basic
  • swoongoonz 8y ago
    110% agree
  • jxub 8y ago
    State management by process-directed messages is a really neat way to avoid throwing oneself under the OOP bus. 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.
  • buremba 8y ago
    I wonder how you avoid writing stateful components in real-world complex SPAs.
    • ilovecaching 8y ago
      It's quite easy, I honestly think the only roadblock is how one thinks about computation. If you think of your UI as a single computational expression you're building up from functional composition, then the issue of state never arises. It's just about defining the shape of the interfaces.
      • buremba 8y ago
        Sounds cool but I can't actually imagine the way you described. :) Any tutorials, articles?
        • xj9 8y ago
          try working through some tutorials on erlang/otp supervisor trees. the concepts are very similar.
    • 33degrees 8y ago
      You manage your state outside your components, using Redux / Relay / MobX etc...
    • williamdclt 8y ago
      Quite easily. The state is held in Redux or whatever, the only state held by components are UI stuff (is this section collapsed? Is this date picker open?). In the last SPA I wrote there's about 100 components, less than 5 of them are stateful.
    • The_suffocated 8y ago
      Discussions of this sort are often confusing. When one talks about using Redux or some javascript library to do "state management", I always wonder whether one is talking about application states (i.e. states originating from business logic but unrelated to UI) or UI states.
  • stupidcar 8y ago
    If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a 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.
    • smackay 8y ago
      For me (Vue + Vuex) the choice was simple: you get undo for free. 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.
      • ilovecaching 8y ago
        You can have undo for free using React as well. React doesn't care about how you manage your state changes, and it will selectively render only the parts of your app that changed.
        • drb91 8y ago
          Not to mention, I believe time travel is an officially supported functionality for redux, if you choose to use that.
  • qudat 8y ago
    It saddens me that JSX became so popular in the React community. I find the syntax verbose and hard to read ... similar to HTML. At my last company we used `react-hyperscript` which was a simple wrapper around `react.createElement`. Ultimately, the React developers made the mistake of making `createElement` so annoying to work with, I assume because they bought into JSX. Granted, JSX might have been necessary when 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 https://github.com/mlmorg/react-hyperscript
    • wetpaws 8y ago
      excuse me if i'm wrong, but isn't it just a snippet for react.createElement?
      • aylmao 8y ago
        react-hyperscript seems to also parse class names ('div.example'), ids ('h1#heading') and come with other goodies. Looks pretty interesting, and I appreciate they doing away with the need of a pre-processor ¯\_(ツ)_/¯
        • wetpaws 8y ago
          I looked through the code and it's about 40 lines long. I don't mind of people using small libraries like this, but it's a bit fun to see it presented as some kind of revelation :)
    • interlocutor 8y ago
      If you care about compile-time checking (you would, if you work on medium to large applications) then JSX (or the TypeScript variant, TSX) is much better because it catches invalid or mistyped attribute names etc.
      • bodas 8y ago
        Only because it is more mature. No reason you can't write a linter for hyperscript.
  • kevin_thibedeau 8y ago
    > I am never a fan of two way data binding as an alternative. The author is wrong. Vue doesn't have two-way binding. It has one-way binding with events. Components can't force anything upon their parent's state with an event.
    • aylmao 8y ago
      I mean, Vue calls it two-way data binding. From their website: > "You can use the v-model directive to create two-way data bindings on form input and textarea elements. It automatically picks the correct way to update the element based on the input type. Although a bit magical, v-model is essentially syntax sugar for updating data on user input events, plus special care for some edge cases." I'm not knowledgeable 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 ¯\_(ツ)_/¯ [1] https://vuejs.org/v2/guide/forms.html https://vuejs.org/v2/guide/forms.html
      • orangecat 8y ago
        As discussed in https://vuejs.org/v2/guide/components.html#Using-v-model-on-Components https://vuejs.org/v2/guide/components.html#Using-v-model-on-... <Component v-model="foo"> is basically shorthand for <Component :value="foo" @input="foo=$event"> In particular, the child can't affect the value of the parent's "foo" attribute except by sending an event. This is in contrast to Angular 1 where changing "foo" in the child would also change it in the parent, which would often lead to confusing data flow cycles.
      • kevin_thibedeau 8y ago
        "v-model" is syntax sugar emulating a two-way binding to simplify form creation. Under the hood it's a one-way bound prop, an event, and an implicit event handler. Ordinary events can't mutate state without an explicitly created handler. 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. https://vuejs.org/v2/guide/components-props.html#One-Way-Data-Flow https://vuejs.org/v2/guide/components-props.html#One-Way-Dat... 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. https://vuejs.org/v2/guide/comparison.html#Data-binding https://vuejs.org/v2/guide/comparison.html#Data-binding
  • _bxg1 8y ago
    I've been using React full-time for a year and a half now, and I've never felt like pure-functional components are a good fit for more than a handful of use-cases. If all you're doing is displaying data, then sure, they're really elegant, but most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled, which means pretending they aren't feels gross and weird (I'm looking at you, Redux).
    • aylmao 8y ago
      > most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled I think this is what the Flux model is all about, making UI code actually be a pure function of state. By that, I mean literally a function, where state is the argument, and where all you render depends solely on said argument. If you want to change what is rendered, you send a message and a 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. (:
      • _bxg1 8y ago
        Well because the UI isn't just a function of state, it's also a function of those actions (the actions have to literally be passed in to the rendering function). So there's bi-directional coupling between the UI code and the Store (the UI code renders from the state, and passes messages back to the store). Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, 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.
  • sbjs 8y ago
    Also Vue is multiple languages. There's a pseudo-HTML language. There's a loop language inside v-for, a special assignment language. React is just JavaScript and HTML.
    • rawTruthHurts 8y ago
      I'm not sure attributes named as "ref" or "className" qualify either as Javascript or HTML
      • dmitriid 8y ago
        They qualify as JavaScript because className etc. are exactly how you work with HTML attributes from Javascript: https://developer.mozilla.org/en-US/docs/Web/API/Element/attributes https://developer.mozilla.org/en-US/docs/Web/API/Element/att...
      • deleted 8y ago
        [deleted]
    • ipntu 8y ago
      The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX. It's not much, really. I personally find Vue templating syntax much easier to follow than JSX, but that's because I'm used to it. I honestly believe that's how React users feel about JSX too.
      • dmitriid 8y ago
        > The amount of special cases in Vue templating syntax is comparable to the special cases and gotchas of JSX 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 https://pbs.twimg.com/media/DbVEoKOX0AEEen6.jpg:large https://pbs.twimg.com/media/DbVEoKOX0AEEen6.jpg:large
  • toolongdidntwri 8y ago
    The only thing that bothered me was that there wasn't a way to tell Vue to disable reactivity with a clear pattern: see https://github.com/vuejs/vue/issues/1988 https://github.com/vuejs/vue/issues/1988 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 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.
  • xiphias 8y ago
    Two-way data binding and composability don't have to be exclusive. I wrote a web framework that provides the two together, though it's right now in early state. Feel free to try it out / use it though if you're interested: http://reactiverelations.org/ http://reactiverelations.org/
• parr0t 8y ago
  Interesting timing with coming across this article for me. I have started developing re-designing our site frontend to use Vue with Vuex and the point this author makes about where to put the API logic also made me scratch my head a bit. Sometimes I just need to make a simple API call that does not alter the application state and just needs to grab some information and render said information in 1 component. Technically, in the component, I can just call Axios and get the data then and there, but then I have other components such as the Login that does need to set some Vuex state and therefore that's abstracted away further in the actions/API class as all documentation seems to suggest that's what you should do. I suppose I am just finding it a bit of a challenge to keep things a) consistent and b) not overly abstracted for the task at hand.
  • petepete 8y ago
    It's not perfect, but I think Vuex Pathify can help keep Vuex organised and somewhat sane. https://davestewart.github.io/vuex-pathify/ https://davestewart.github.io/vuex-pathify/
    • davestewart 8y ago
      Is there anything in particular you found sub-optimal?
  • noir_lord 8y ago
    I just put those Api calls in a module in the same dir as the component usually. Then api.fetchFoo(bar).then() mostly does it. Benefit is separation of API from component.
    • RussianCow 8y ago
      This doesn't actually solve the dilemma of where to put the logic—all you've done is moved the API code into its own object, but your component is still the one controlling the higher-level flow in this case.
  • RussianCow 8y ago
• fiatjaf 8y ago
  It is good just for the simple stuff, the world of webapp examples, todo lists and so on. For all that, Elm is much better. 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".
  • keithnz 8y ago
    do you have any concrete reasons why? I've done a lot of Vue and React, and long term I have found Vue much more maintainable and productive. Not saying there is anything wrong with React. But I just don't see Vue as a limitation on writing complex apps.
  • pier25 8y ago
    > 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. Can you elaborate on that?
  • tarellel 8y ago
    Care to explain how complicated apps are a no go? I've used Vue for about a year and half now. Some of my apps have been very simple some of them have been extremely complex. I can say I've had very few issues along the way. VueJS is absolutely amazing. You just need to throw-in some mixins, Vuex, Vue-Router, and whatever else you may need and you should be golden!
• condescendence 8y ago
  >You’ll be adding similar boilerplate for computed properties, component state, watchers, etc. Pretty much everything in Vue has its own special syntax with more boilerplate. I kinda like this syntax, when I first learned vuejs I knew immediately that some magic was going on in the background. If I saw marko's syntax I'd be wondering how this shit is getting done. It also makes it easier when searching for issues or 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.
  • patrickmay 8y ago
    Could you recommend two or three non-chat based communities? I'm just starting to try Vue and the first handful of tutorials I've tried simply don't work as described.
    • voltagex_ 8y ago
      I'm always interested when people say that tutorials don't work - I had a site planned called wrongtutorial.com but I couldn't work out how to make it funny/informative without being demeaning. What tutorial are you using? How old is it? What didn't work?
      • condescendence 8y ago
        when Vue went from 1.0 to 2.0 a lot of functionality became deprecated. So all those tutorials are basically useless now. I ran into the same issue. Vue 2->3 won't be so bad because they're promising backwards compatibility.
      • 8y ago
• carusooneliner 8y ago
  I can vouch for the author's points on the good parts of vue.js. We've built our single page application (SPA) web app with vue.js and are very pleased with the results -- https://checkoutclip.com https://checkoutclip.com. We were able overcome most of the stumbling blocks by looking up https://vuejs.org/v2/guide/ https://vuejs.org/v2/guide/, https://github.com/vuejs/vue/issues https://github.com/vuejs/vue/issues and https://forum.vuejs.org 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 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.
  • ppiuser 8y ago
    Have you looked at your site with javascript disabled? Additionally, was vue used just for the website or the chrome app as well?
    • carusooneliner 8y ago
      Our site does't work with js disabled. Serious question: is it common for folks to disable js? vue is used only for the web app. No js frameworks used in the chrome app.
      • jazoom 8y ago
        It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript. If JavaScript is disabled I just show a message saying the site needs it. I also only support modern browsers and haven't had a complaint for 3 years. About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no 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.
• CryoLogic 8y ago
  Funny, the meh and the ugly points are all non-issues with Ember.js. Sounds like he wants a convention over configuration framework from a barebones DIY from the ground up style framework.
• dsco 8y ago
  A lot of the boiler plate can actually be removed if you combine Vue with TypeScript decorators. Here's a library which will do that for you: https://github.com/vuejs/vue-class-component https://github.com/vuejs/vue-class-component 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.
  • sharpercoder 8y ago
    I would highly recommend against this setup. While Vue is already very challenging to get right with any build tool, it's especially terrible regarding typescript and much more so with typescript decorators. You need to enable hardly documented configuration switches in multiple dependencies. Then, you must wrestle through a plethora of error messages coming from a diverse set of build tools/libraries/scripts. After you've done that, the only options is praying to the gods a config will work. 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.
    • breakingcups 8y ago
      Just to provide a different point of view. We're using Vue + Typescript + ASP.NET Core in about 4 mid-sized projects now and it's working really well. The only thing which was excruciating to get set up right was Webpack, but that's not Vue's fault nor Typescripts. 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.
• sharpercoder 8y ago
  One particular weak point of Vue is it's dependency on build tools. I spend a few days buiding a great app, and then another few days on getting the build apps configured right with Vue. You google from one error message to another, where each message is unclear and no relation to any build tool/plugin/library/script is made. 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.
  • mlevental 8y ago
    literally in their docs they have you <script src> into a plain HTML file to get started. and it's not like react doesn't the same issue - hell CRA had to be built.
  • keithnz 8y ago
    this is really weird, not sure what you are doing...... one of the nice things about vue is it's super easy to just add to any page, I've done that a lot with transitioning pages from a mish mash of javascript to vue embedded on the page.
  • amelius 8y ago
    My experience as well.
  • zmmmmm 8y ago
    Such a strange comment to read ... quite literally, the reason I first started using Vue over other frameworks was I wanted to put it into legacy apps and did not want to use a build tool. It's one script tag. Not in a half lying way like people say about React, for real. It falls down if you start throwing in components and libraries that presume webpack based setups (which is annoying), but Vue itself is completely and trivially usable with zero build step.
    • k__ 8y ago
      Such a strange comment to read ... literally, the reason Facebook first started creating React was they wanted to put it into legacy apps. :D
• Sir_Cmpwn 8y ago
  >Chat based community 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.
  • KaoruAoiShiho 8y ago
    UI clients unfortunately suck in comparison. That's really the problem with these no-owner platforms. Nobody has the financial incentive to make the big monetary investment needed to get the last 10% user experience stuff fixed.
    • MaxLeiter 8y ago
      Work is being done in this front with ircv3 and modern clients, though
      • Operyl 8y ago
        We’ve been hearing this for the past ten years now it feels like. IRCv3 seems to have fallen short on most of its promises.
  • frou_dh 8y ago
    It's getting bad. There are a couple of communities that I have resigned myself to not being able to make ties in, because I have absolutely zero interest in doing anything "on the Slack", as is so often casually mentioned.
• mey 8y ago
  I wish Typescript and Vuex played better together.
  • cholmon 8y ago
    Agreed. Luckily "Better TypeScript inference" is on the roadmap for Vuex 4. https://github.com/vuejs/roadmap#vuex-4x https://github.com/vuejs/roadmap#vuex-4x
• KaoruAoiShiho 8y ago
  Pushing so much support to chat is an astonishingly big mistake. Not only are platforms like stackoverflow vastly better at answering questions and providing long-term documentation, it also builds broader communities. People use things like "number of stackoverflow questions tagged vue" to determine health and activity. You don't want to miss out on those metrics that other libraries are rolling with.
• ElatedOwl 8y ago
  We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works. TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen. There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design 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.
  • dangerbird2 8y ago
    Typescript support has gotten much better in the past few months. In particular, the vue-cli scaffold provides the correct stubs so typescript doesn't freak out when importing single-file components.
  • heisenbergs 8y ago
    vue 3 will be entirely rewritten in typescript. https://github.com/vuejs/roadmap https://github.com/vuejs/roadmap
    • sheeshkebab 8y ago
      And that will probably be the end of vue...
      • blencdr 8y ago
        have you even tried to use TypeScript on a real project to say something like that ?
        • Ronsenshi 8y ago
          He's possibly meaning that if you completely rewrite framework it would lead to something like what happened to Angular when it was rewritten and promptly lost huge number of followers/users?
• deckar01 8y ago
  There is a plug-in that lets SFCs use es6 class syntax instead of objects [0]. The code looks so much better. I don’t think the docs ever mention it. [0]: https://github.com/vuejs/vue-class-component/blob/master/README.md https://github.com/vuejs/vue-class-component/blob/master/REA...
• Tade0 8y ago
  >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. 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.
  • pier25 8y ago
    > Ok, but where's an example that shows how this backfires? Why should the API logic not be written in Vuex? (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.
    • philliphaydon 8y ago
      I use vuex with namespaced modules, but then those modules just call out to abstracted implementations if it's more than just http request. So for example with auth, I have a vuex 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).
• k__ 8y ago
  I like the WebComponents integration, but the rest feels like Ember components to me. React achieves much more with much less.
• mmcnl 8y ago
  The ugly in this article isn't really the ugly, it's the good. Nobody's holding you back from writing a simple ES6 module that handles API requests for you. Vue is a view layer, nothing more and nothing less.
  • k__ 8y ago
    People aready hated on this with React, why should they stop with Vue? :D I guess Ember and Angular are more of one-stop-shops in that way.
  • enraged_camel 8y ago
    This is what I do and it works wonderfully.
  • narrowtux 8y ago
    To be fair, being used to full frameworks such as angular, you think that you have to do it in some kind of vue-way or react-way. I even made the mistake of using a vue-specific HTTP library when I started. Only later I learned that Vue and react give you the freedom to do whatever you want.
    • Too 8y ago
      Great comment. Seeing all the hate Angular gets I think this is the biggest mistake people do when they use angular, they try to do everything the angular-way with an angular service for everything, like you say even getting a angular-specific HTTP library, wtf?! They should have just removed the whole concept of services to not confuse people. If you instead only use it as a view layer it is actually quite nice. Same with vue and react, you should only use it as a view layer, not build your entire business logic on top or around of it!
• andrewstuart 8y ago
  I don't get the thing about ReactJS boilerplate where he says "Moving from React to Vue seems like a breath of fresh air. No more bind(this) or setState() everywhere. Yay! " Surely there's better ways of doing ReactJS rather than lots of setState? Of course I use setState but try to avoid it generally. And I almost never, ever use bind() - don't es2015 fat arrows make it obsolete?
  • acemarke 8y ago
    Sort of. The nicest-looking approach is to use the Stage 3 Class Properties syntax to write class methods using arrow functions, which auto-binds them to the component instance as it's created (the equivalent of calling `.bind()` in the constructor).
  • k__ 8y ago
    Funny thing is, React uses that API because two-way-binding is considered bad practice. But I guess old habits die hard...
  • toddh 8y ago
    The react tutorial uses bind all over the place. So they apparently think it's still necessary.
  • NathanCH 8y ago
    If you're using arrow functions for handlers I suspect your components are difficult to work with, unless they are very simple? Why not abstract logic to a function and bind it? That's totally normal for Javascript.
  • eknkc 8y ago
    Arrows create a brand new function on each render call. Say you have a pure component that you pass an onChange handler. If it’s an arrow function, the component needs to re-render as you created a new function. If it’s a pre bound function reference, the sub component will not receive any prop changes. Otherwise, yeah.
• _bxg1 8y ago
  I've used React full-time at work for a year and a half now, and I did a personal project in Vue for a while to try it out, before converting it to React. 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.
  • k__ 8y ago
    Vue reminded me so much of Ember that I could not understand how people could think of fresh air...
    • sametmax 8y ago
      Embed is more complicated than vue to use. Vue has components. Updating the dom is mostly mutating your component attributes. That's it. Nothing else. 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
      • k__ 8y ago
        The Vue components remind me very much of Ember components, that's what I wanted to say. 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.
      • _Tev 8y ago
        > Vue has components. Updating the dom is mostly mutating your component attributes. That's it. Nothing else. 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.
• octref 8y ago
  Have to do some clarification here on the point of "Unclear architectural patterns", as the article is way too misleading. - 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-cart https://github.com/vuejs/vuex/blob/dev/examples/shopping-car...
  • voltagex_ 8y ago
    >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. 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.
    • octref 8y ago
      One thing I want to say is: Don't assume only developers make websites. Don't assume everyone wants to ship a heavy and complex SPA. 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. [0]: http://typedetail.com http://typedetail.com [1]: https://twitter.com/DesignJokes/status/1015003288528400386 https://twitter.com/DesignJokes/status/1015003288528400386 and https://twitter.com/DesignJokes/status/1014260361535647744 https://twitter.com/DesignJokes/status/1014260361535647744 [2]: https://twitter.com/bterlson/status/913433979239436293 https://twitter.com/bterlson/status/913433979239436293 and https://github.com/bterlson/tcq https://github.com/bterlson/tcq [3]: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
• deleted 8y ago
  [deleted]
• david-cako 8y ago
  If this is your article I'd love to know your VS Code color scheme.
• crimsonalucard 8y ago
  My problem with current gen frameworks is composition and modularity with components. Making components stateless and having all data come in as props from parents is good for modularity but how do you pass data back to the parent? This is where the modularity becomes awkward. 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.
  • vanderZwan 8y ago
    > 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. 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?)
    • crimsonalucard 8y ago
      >Can you explain a bit what you mean here? 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?
• bryanlarsen 8y ago
  Rather than abandoning chat, they could use a service that is google-able and linkable. I recommend zulip. Added bonus: open source.
• vanderZwan 8y ago
  Has anyone checked out the linked framework benchmark[0], and some of the other frameworks linked in there? I had not heard of surplus and S.js before, but they look like an interesting combo[1][2]. 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 https://github.com/krausest/js-framework-benchmark [1] https://github.com/adamhaile/surplus https://github.com/adamhaile/surplus [2] https://github.com/adamhaile/S https://github.com/adamhaile/S [3] https://github.com/adamhaile/surplus#why-real-dom-nodes https://github.com/adamhaile/surplus#why-real-dom-nodes
• HumanDrivenDev 8y ago
  I started out with vue, but found it too heavyweight and clunky. A viewmodel framework shouldn't need its own god damn compiler or file format. I ended up switching to mithril.js, which is much smaller than vue and comes with its own router. Haven't missed vue at all.
• jorblumesea 8y ago
  One of the best arguments against Vue is typescript support. React has really good support for it, even for the state libs like Mobx/Redux etc. Until they turn that around it will be hard for any frontend application to scale properly. I think Vue is great for smaller projects and would absolutely recommend it.
  • philliphaydon 8y ago
    TypeScript works fine?!?!? With @vue/cli it's trivial to setup, it's literally option in a new app. 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. https://github.com/vuejs/roadmap#3x https://github.com/vuejs/roadmap#3x
    • jorblumesea 8y ago
      Hardly as polished as other frameworks. Sorry, just not true.
• NathanCH 8y ago
  I think both React and Vue become difficult when working with complicated UIs. If you're already using Vue or React, these simple articles are not comprehensive enough to be convincing. React and Vue basically manage state the same way, which is 90% of what you'll be doing in these libraries. And just like in React, default state management is insufficient in Vue.
  • orangecat 8y ago
    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.
    • littlecranky67 8y ago
      Redux is only a little more work/complexity than the "singleton state class" approach but brings a lot more benefits: timetraveling debugger, serialization of the state (i.e. to localStorage to allow multi-tab operation or resume after tab was closed) and separation of pure HTML/Visual Components versus Container components. 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.
• dstick 8y ago
  This is going to be a drop in the ocean but Vue is the bomb! It made perfect sense, and that's a big compliment for a framework. 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.
  • manasn 8y ago
    I liked this drop in the ocean :)
  • marcstreeter 8y ago
    +1 for .Vue files. I really like the organization around components and not around file types(.css, .js, .html) within a project's file structure. For me it's an immense time saver knowing exactly which css and javascript was intended for a particular component (using scoped scss for example - which for me is still a pain in the React I use at work).
• ld00d 8y ago
  >Will a state manager start mediating all application logic now? 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).
• hvidgaard 8y ago
  > Vue is really fast. Maybe not the fastest, but its performance is overkill for the vast majority of web projects. When was the last time you needed to render and update thousands of DOM elements per second? 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.
  • Vinnl 8y ago
    > Better performance is always a net gain, 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.
    • hvidgaard 8y ago
      I was speaking in the context of two different frameworks, not code, but I suppose the clarification is nessesary. > 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.
      • Vinnl 8y ago
        > 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. 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.
• caseymarquis 8y ago
  What the article refers to as boilerplate is actually something I like about Vue. Standard component organization is a good thing.
• bschwindHN 8y ago
  I mention this is pretty much any thread talking about frontend framework architectures. Check out ClojureScript's re-frame project. It's maybe not for everyone but in my opinion it's an elegant and distilled method for writing React-esque views and handling data subscriptions. The syntax is of course polarizing but it really gets rid of a lot of boilerplate. https://github.com/Day8/re-frame https://github.com/Day8/re-frame
• rajangdavis 8y ago
  I tried nuxt (a vue framework) the other day and was disappointed. It seemed like a very straightforward way to create a UI over a REST backend, but I kept getting stuck with the issue of how to have a clean separation of the back end and front end responsibilities. For example, I wanted to have a UI that was rendered based on the JSON payload that would get committed to a Vue Store. I consistently ran into issues where Vue would complain about the client rendered code differing from the server rendered code. Are there any js frameworks where you can specify which components are rendered on the server and which are clientside?
  • KaoruAoiShiho 8y ago
    Strapi just released their tutorial on nuxt and other backend stuff. https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-vue-js-graphql-strapi-and-stripe-bonus-deploy-part-7-7/ https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-v...
    • rajangdavis 8y ago
      I appreciate the share, but looking at this example(https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-vue-js-graphql-strapi-and-stripe-restaurants-list-part-2-7/#gist90478038 https://blog.strapi.io/cooking-a-deliveroo-clone-with-nuxt-v...) it appears that they are employing a pattern that I do not want. 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/ 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.
  • breakingcups 8y ago
    With Nuxt, use the <no-ssr> component: https://nuxtjs.org/api/components-no-ssr/ https://nuxtjs.org/api/components-no-ssr/ All my similar issues went away after discovering that.
• pwaai 8y ago
  is there any progress on progressive web apps regarding with vue.js or is this still an after burner project?
• philliphaydon 8y ago
  > The Vue community hangs out on Discord Oh? I've only ever been in the gitter room... I had no idea there was a discord too...
• zubairq 8y ago
  I used React for 3 years but once I discovered Vue I switched. The reason is that React and Vue have different audiences. Vue is more for people who don't think in code whereas I think tht React is more for "Hard Core Developers", so I chose Vue for a Javascript development platform that I built
• hardwaresofton 8y ago
  I agree with the point that one of the biggest warts on Vue are the corners of the reactivity system (first point in the "Not so magic" section of the article") and how it can surprise you. IMO if Vue had reactivity like KnockoutJS did, it'd be perfect on that front. 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.
  • easymovet 8y ago
    Has anyone actually run into limitations of knockoutJS that Vue or React solve? Knockout has typescript support, stable codebase, excellent tutorials, large plugin base, and components that can be loaded with requireJS. We've had great luck with it in the wild too.
    • DCoder 8y ago
      TSX views with full typechecking blow all stringly-typed templating solutions like Knockout Templates out of the water. In addition to that, immediate DOM repaint without any consolidation is inefficient and hard to debug at times.
    • hardwaresofton 8y ago
      I think they're just about equivalent -- especially since Knockout's addition of components explicitly as a paradigm (which was a loooong time ago[0]). It's really just a matter of where the hype-train ends up going over the years. 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-components.html http://www.knockmeout.net/2014/06/knockout-3-2-preview-compo...
• nnq 8y ago
  What I still never saw so far, and what this article also avoids, was an actual explantion of - 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? :)
• deleted 8y ago
  [deleted]
• noname120 8y ago
  Previous discussion: https://news.ycombinator.com/item?id=17349849 https://news.ycombinator.com/item?id=17349849
• vmware505 8y ago
  It is just my feeling that Vue.js is almost like Ember.js, the only differences that Ember.js is more matured?
  • sametmax 8y ago
    VueJS has a lower API surface than Ember: you just have components. Not a specific type of object for your model, and the a controller on the side, and specific methods, etc. 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.
• baby 8y ago
  I'd say today, there is little to no reason for small to medium sized websites to use React instead of Vue.js
  • plopz 8y ago
    For small to medium websites, what benefit does React or Vue have over plain HTML + jQuery?
    • baby 8y ago
      It’s a framework, meaning it makes a lot of things easy out of the box, if you’re willing to re-implement this stuff or if you don’t need it then html+query all the way
• ixtli 8y ago
  One of the gems in this that i think might be getting overlooked: > 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.
  • tnolet 8y ago
    Yes! Also things like Gitter and Slack are really messy for storing knowledge. Questions get lost, answers are interspersed with more questions. Maybe I'm getting old, but give me a forum based, one-thread per topic any time of the day.
    • anderspitman 8y ago
      I prefer forums as well, at least for technical questions/discussions. It seems to me the biggest advantage of chat apps over forums is that you can use a single account to join many rooms. Are there any forum platforms designed around that idea?
      • dave7 8y ago
        > Are there any forum platforms designed around that idea? That's basically Reddit
      • b34r 8y ago
        Spectrum.chat
  • biggerfisch 8y ago
    I see why many people consider this to be a problem, and it does severely limit the ability of knowledge to persist, but I think there are some benefits to it, namely that the answers can always be up-to-date. 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.
• tnolet 8y ago
  Been writing a lot of Vue.js lately. Tried React, but hit the same snag when learning (ancient) Greek in high school: when I look at a page of JSX my mind just freezes. It's the type of symbols and the syntax that just make me glaze over. Of course, this is very very personal and doesn't say anything about the validity of JSX or ancient Greek for that matter.
• sireat 8y ago
  I like that Vue is easy to add to an existing site (ie the new jQuery). 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)