[alipang]

The React core team has done a wonderful job incorporating actual CS concepts like algebraic effects into their framework. I understand that it's only an approximation of the real thing, but they're clearly managing to at least get the core idea out there into real production systems.

The Vue implementation seems to ultimately lack this core understanding, and comes off almost a bit cargo-cultish in comparison. React has hooks, so we must have something similar.

I don't mean this as singularly bad, I'm certain Vue can be productive and that this can be a productive feature for Vue devs - but when will we as an industry manage to evaluate software by semantics rather than the syntax we prefer? Does Vue truly offer anything over React that's not in the realm of preferred syntax?

[acemarke]

I'm a complete React fanboy and fully engaged in the React ecosystem, but I'd like to speak up in Vue's defense here.

Yes, there's some obvious copying going on here, but this is not a bad thing! There's been a lot of cross-pollination and inspiration between the major frameworks and ecosystems.

While I haven't deeply inspected the exact details of the new Vue APIs, my understanding based on discussions is that the Vue team has heavily adapted the hooks APIs for a more Vue-idiomatic approach. This includes things like removing the need for the call order limitation, only calling them once on setup, making use of Vue's reactivity, and so on.

Those changes fit well into Vue's stated focus on ease of use and handling a lot of behavior automatically.

This gives the Vue community a chance to benefit from some of the same concepts and improvements that the React team has described for hooks, while staying with their same toolset.

I'm entirely happy with React and have no plans to switch, but there's plenty of reasons for folks to choose Vue (and similarly, each of the other frameworks). I gave a list of some reasons why you might pick each of them a while back on Reddit [0].

[0] https://www.reddit.com/r/javascript/comments/avsuei/react_vs...

[palerdot]

Copying is a harsh word IMO. Vue has been liberal and open in quoting prior art, particularly from the React ecosystem. For example vuex[0] docs, actually quotes Dan Abramov regarding flux implementations for state management.

[0] - https://vuex.vuejs.org/

[bpicolo]

Programming and open source is a massive ecosystem of making use of prior art and incorporating diverse ideas to make alternative, better, or more robust abstractions. That's the whole beauty of it. Very few things are entirely new.

[brlewis]

More on the relationship between hooks and the proposed Composition API: https://vue-composition-api-rfc.netlify.com/#comparison-with...

[preommr]

> a wonderful job incorporating actual CS concepts like algebraic effects into their framework.

What does "actual CS concepts" event mean? This is the first time in my life that I've heard about algebraic effects.

If I am understanding your comments, the implication seems to be react is implementing concepts that elevate the tool while vue goes around in circles to make an alternative syntax.

I don't even agree that the react team has done a good job with implementing a clear concept for their framework. Things like Elm have done a much better job of that. Granted that's a lot easier to do when they don't have to force themselves to deal with js directly.

But even then, why is react implementing hooks not bad, but vue implementing them is? There's a reason why react made the switch, and some of those advantages also apply in vue. These changes aren't just made to follow trends.

[alipang]

There's been an unfortunate trend in the JS world where a lot of frameworks are created, but without any real meaningful sense of progress, resulting in a sense of going around in cycles in various "reskins" with different syntax and conventions, all round some kind of core MVC idea.

When I say "actual CS concepts" I mean things that have been broken down into it's core using a suitable mathematical model. This is ultimately a much more suitable way bo build tools used by engineers.

My personal concerns is that Vue to me is mostly just a reskin with new syntax on things that are already in React. Hooks become the "composition api". Redux becomes VueX. Is this necessary?

Could VueX just have been an alternative to Redux, like MobX is?

Could we just have implemented a Webpack-loader to put styles and react components together?

Some people don't like that React uses `className` instead of class. Is `v-bind:class` and various `@` notations really so much better we can justify a whole new ecosystem?

So roughly - Vue provides fragmentation in the frontend ecosystem. I like competition - but what does it really offer that justifies it? I don't get it, and now what they have been working on is just catching up to React.

[vcoelho]

Well, I started with Angular and couldn't make any sense of it. It had two versions with huge differences between them and React offered a more concise path for learning.

But I found JSX hard to read and there was no consensus on how to write CSS and some people were saying that it was ok to use inline styling. WTF? The web design community have been telling me the opposite for years!

Then I started working with Vue and everything fallen in place: no deprecated lifecycles, CSS into style tag and easy to read markup with no Array.map() returning HTML tags.

Fragmentation is bad, but is nice to have a balanced option between extremes.

[pixelbash]

The hook that got me started on Vue was being able to straight swap with a previous two way dom binding library (rivets.js) and continue from there, I've found Vue to be incredibly easy to pick up, and very productive now I'm up to speed.

[nickdandakis]

Preferred syntax should be enough, but here's a couple more differences:

- Vue has a set of core libraries (Vuex, vue-router, etc) maintained by the same org.

- Single file components with scoped styling out of the box.

- Vue integration as a standalone runtime is a little easier than React (unsure about this one).

You can read more about the differences here:

https://vuejs.org/v2/guide/comparison.html#React

I couldn't find any official comparison documentation from the React docs, though.

[Rapzid]

Wouldn't mind some other opinions on this but having used Mobx a lot in the past and starting to look at Vuex for current employer it's not looking enticing in comparison.. Mobx will work with Vuejs and I'm reading about a lot of people who have switched from vuex and been very happy. Considering just jumping in with Mobx and the bindings..

My and many others dev environments lean heavily on Vetur and it.. Is plagued with various issues in various releases. JSX/TSX JustWork™ while SPCs are okay sometimes but other times are found wanting..

[ng12]

> Single file components

Honestly I think this is a step backwards. How many components my "component" is built out of should be an implementation detail.

[zamalek]

You're misinterpreting what an SFC is, it's just something like the following:

    <template>
      <!-- A mustache-like template -->
    </template>
    <script>
      // JS, TS, or whatever
    </script>
    <style scoped>
      /* CSS, LESS, SCSS or whatever */
    </style>

That components may use other components itself, no part of SFCs disallow that.

[ng12]

That's not what I'm saying. What if I have a child component I don't want to put in a separate file? What if I want a child component defined as a closure inside my parent component? What if I want one file that exports many components? React makes no judgements here -- it's completely up to me to decide what's best for my application.

[cooperadymas]

I don't think anything would stop you from creating multiple components in a file using 'Vue.Component' and a template string.

I've never remotely wanted anything similar to this in Vue, but I have seen what you're talking about used in React, mostly for component wrappers to encapsulate logic. It's not something I like using or seeing but that could easily be swayed by my preference for Vue.

See how it's done in the guide. It wouldn't be as natural as react allows but should suffice for tiny, contained sub components.

https://vuejs.org/v2/guide/index.html#Composing-with-Compone...

[adamwathan]

> I've never remotely wanted anything similar to this in Vue,

This was true of me as well until actually playing more with React. In practice, being able to very quickly extract a child component by just copying a chunk of code to a different spot in the same file is a very nice workflow benefit I now sorely miss when using Vue. In Vue my components tend to be larger and more complex than they are in React because I feel like some small extraction I want to make doesn't "deserve" it's own dedicated file, whereas in React I just quickly make a new function that returns some JSX and I'm done.

[ng12]

> 'Vue.Component' and a template string.

But the template string is just a string, right? Can you get the same IDE integration while avoiding SFCs?

[zamalek]

You don't have to use SFCs (I don't in Vue 2 or Vue 3). However, you would be able to nest components in an SFC so long as you don't expect the <template> tag to work in the interior components (I can't imagine how that would even look and work).

The only thing that SFCs do is create a render function for you (as well as some CSS scoping magic). You can do that all yourself and that is all documented and supported behavior.

You have completely the wrong idea here and, honestly, this is all in the documentation.

> React makes no judgements here

Vue typically has fewer opinions than React (and FAR less than Angular) in my experience.

[ng12]

I'm explaining why I don't like SFCs because the above poster referenced them as a "pro" for Vue over React. Whether or not you _have_ to use them in Vue is immaterial.

[reubens]

You can do this within Vue if you like - you just increment the complexity of your exisiting component, rather than creating a new child

[jimktrains2]

It isn't? You don't have to define them in a single file.

I prefer having the template, styles, and code together, but it isn't required.

[cooperadymas]

It largely is an implementation detail. The official guide starts you off without them. You ostensibly could develop an entire application without touching SFC or using the vue cli. But they're such a well implemented pattern that you'll find almost no one in the wild avoiding them, which is pretty telling.

[jplayer01]

A bit tangential - I've been messing around with vuejs and Django recently (I'm not a web developer in the slightest) and I haven't found a decent way to get webpack integrated. So I can't use SFC or cli and I wonder how people do this in the real world. Do people even use vue with Django?

[thefreeman]

They are generally deployed separately. Django is used to build a rest API and webpack / Vue are deployed on their own to consume the API. You can put something like nginx in front to route API requests to Django and everything else to an s3 bucket for your single page app.

[jplayer01]

Any tips on where to look or what to read to implement something like this? I put in an hour or two experimenting with how I could do it and there seem to be a lot of moving parts I’m not familiar with.

[conradfr]

I don't know Django specifically and not sure exactly what you want to do but yes you can integrate Vue, webpack & all in anything.

In fact that's what I've encountered in most companies, and what I usually do for my side projects. Basically you output a <app>.js and <app>.css and integrate those in your app layouts / templates.

That's a problem with all these CLI and all those tutorial targeting SPA with a node backend. But IIRC vue-cli as options to help you achieve that, but the docs are not always the clearest for this.

[jplayer01]

Nothing exotic really. The problem has been how to figure out the process for writing the frontend with npm/webpack, building it and getting Django to serve js files on different pages. I simply couldn’t get it to work. I’ve resorted to just skipping the npm part and writing js scripts in Django's static directories without any libraries or other js tools except for those I could add to an html template with a script tag (which is quite limiting).

I'm going to try separating the frontend and serving it with nginx instead, and only use Django to provide an API for the DB. Maybe I’ll be able to figure that out. My biggest issue is that there are no decent guides for any of this, documentation is allaround terrible and even if there is some guide, it doesn’t work.

[aitchnyu]

I've been hacking together a Webpack setup so I can include small Vue apps in a Django app instead of making it an SPA. Will Vue cli help me with that?

[ng12]

Correct me if I'm wrong but I imagine that's more for the tooling (e.g. syntax highlighting for my template and styles) than an actual preference for SFCs.

[cooperadymas]

Shrug. Maybe? I think Vue is popular enough that if people actually disliked SFCs once they started using Vue they you would see blog posts about how to avoid them, complaining that's why they're leaving Vue, or tooling that makes it easier to bypass them. I don't really see this so my assumption is devs generally like them once they start using them. I could certainly be proved wrong.

[neya]

Have you used both? This is a comment I usually see from people who have used only one, but not the other.

Let me give you some background about myself - I'm a full time consultant, I write both frontend and backend code for a living. I have worked for almost 27 companies in the last 2 years as a consultant. I have used both.

Vue may copy react, but their implementation and opinionated code structure (Eg. Single file components, Vue-Router, Vuex, etc.) is so much better than the complete freedom that React gives you. Almost all of them who used React had terrible code quality and really bad code organization. In contrast, the Vue code base I've worked with all had some level of uniformity enough for an external consultant to come in and understand what was going in. The worst code I've ever seen till date was on React from an analytics firm. I lasted 15 seconds after which I closed the tab and re-negotiated the contract to do only backend for that firm.

I'm not saying React is bad, end of the day, they're all just tools, but a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app. Especially for large codebases, this is so true when you work with stuff to manage state like Flux/Vuex.

I also observed that companies using React usually also tend to do more re-writes of their codebases as it becomes unmaintainable over time without an opinionated way to do things like with Vue. Companies with Vue also seem to be more profitable and less reliant on VC money. You can feel free to verify these stats by heading over to LinkedIn/Angel.co and checkout the companies who hire for Vue/React.

So, to answer your question - Does Vue truly offer anything over React that's not in the realm of preferred syntax?

Definitely (as I explained above). I personally would never touch React for a prototype or a project that needs to go to market with less bugs.

[ng12]

> a vanilla TODO Vue application with its syntax is much much better to work with a vanilla TODO react app

These would be almost identical in structure and design. You're drastically overstating the difference between React and Vue.

[aitchnyu]

Picking your brain. Somehow React+Redux feels the stuff of horror stories. Which of React, React+Redux, Vue, Vue+Vuex will lead to the least disaster for a sloppy team?

[lhorie]

Approximating Suspense to algebraic effects is a pet peeve of mine. Algebraic effects are more akin to DI or at best to using a generator than the throw-and-retry-everything hack that Suspense does. And to boot, that's not even necessarily the right abstraction (e.g. AFAIK multiple nested suspense things are still an open issue).

I do agree that Vue seems to be reactive in its choice of features, in the sense that it tries to be everything to everyone.

The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing.

I feel like Angular is the one framework that sorta "gets it" now. It went all the way to CS lala-land w/ 1.x and rewrote from the ground up for v2 taking several lessons from its v1 and from elsewhere.

[brlewis]

>The underlying problem IMHO is that these frameworks are unwilling to create major breaking changes (since that would hamper marketability) so it's easier to just shove things into the unused edges of the semantics space until they becomes a hodge podge of a million ways of doing the same thing.

Sounds like you want Mithril, but keep in mind that backward compatibility and marketability are, in fact, useful features.

[lhorie]

> backward compatibility and marketability are, in fact, useful features

They are (and FWIW, the Stroustrup quote[1] is quite applicable here). I'm merely pointing out that feature creep leads to bloat/complexity which lead to people to complain, and that feature creep also leads to marketability (which is a reason why mainstream language spec documents typically have hundreds of pages). Personally I think this pattern is a problem, but I don't know if anyone has managed to figure out a solution.

[1] https://www.goodreads.com/quotes/226225-there-are-only-two-k...

[brlewis]

Ha! The HN feature of emphasizing comments and de-emphasizing their authors worked too well. I did not notice I was replying to the original author of Mithril. Hi Leo.

If "long copy sells" is the reason why feature creep leads to marketability, then maybe an abundance of examples would help.

[Scarbutt]

Picking on your brain and hindsight ;) , and as someone who did little ES5 and DOM/browser API programming in the past, what would you recommend today for a fast track to a SPA for a solo project? (The learning process is not an issue). The interactivity is not very high but the UX can benefit from a SPA, is an invoicing system.

JS Framework, CSS methodology(UI framework?), etc... or any other perspective you want to share.

[ilrwbwrkhv]

apprun https://apprun.js.org/

[jaequery]

"The React core team has done a wonderful job incorporating actual CS concepts like algebraic effects into their framework"

Is that a good thing?

[al2o3cr]

TBH, React feels like what you get when a bunch of very smart devs decide to "incorporate actual CS concepts like algebraic effects" into showing people ads.

Arguing that we should pick tools based on semantics without considering syntax is like arguing people should pick spouses based on genetics and not personality.

[apatheticonion]

The thing that I find most amusing about modern front end is the over-emphasis developers put on the rendering engine.

Presentation is only a small portion of an application. A view rendering engine is required to do a couple of things, accept and render data.

The semantics of how it accepts data enables good software engineering practices like dependency injection and dependency inversion.

The semantics of how it renders data enable ergonomic usage of the renderer (templating, JSX).

Modern web developers tend to write "React" or "Vue" applications - not "Type/JavaScript applications that render with React"

Global objects, singletons fetched from module-powered service locators, unlimited power global stores and enough boilerplate to make the most hardened Java developer confess their sins to Oracle.

Looks like Vue 3 is fine but continues the trend of doing it all.

[jakobloekke]

This! But I find that a combination of Typescript, MobX and React brings me very close to a good place.

[nailer]

> The Vue implementation seems to ultimately lack this core understanding, and comes off almost a bit cargo-cultish in comparison. React has hooks, so we must have something similar.

Aren't hooks only needed because React and Vue still use a virtual DOM?