I think the best part about Vuejs is that how simple it is and everything just works!
A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it was so easy to switch to it.
Transition from vue1 to vue2 was really simple. I'm sure the same will be true for v3.
Maybe it's the constant React vs Vue articles that make me suspicious, but if you are referring to React when mentioning webpack / transliteration, i'd like to mention that you don't need them for React neither. It can be resumed to a simple script tag as well.
I hate this misconception and wish it would just go away.
Could you paste the simple script tag that makes React work without transpilation? I always thought you needed Webpack (or an equivalent) to transpile JSX into a vanilla js function the browser can interpret.
If you're referring to Create React App, it uses Webpack - just preconfigured so you don't have to fiddle with it before you start building.
No, I meant simply adding a tag and using react directly, in any context. That's how it was originally designed, btw. It wasn't meant only for SPAs when it was conceived, but as an addon to existing websites.
The other comment gives a perfect example and there are a few tutorials (although I do agree not very mainstream) that teach React without JSX/Webpack/Babel/etc.
edit: You are correct that you need transpilation for JSX but you don't need JSX for React. The confusion of JSX/React sounds eerily similar to how newbies confused jQuery for JS.
I don’t think the comparison with JQuery vs JS is at all similar. JSX was created for React, and nearly every time you see React code it’s using JSX. Technically, each of them can be used separately, but it’s a very reasonable impression to consider JSX one of the main features of React.
JS was not created for JQuery, and you can not used JQuery without JS.
"jQuery was created for JS, and nearly every time you see JS code it's using jQuery." Doesn't that sound like something you would hear a few years ago?
Sure, but that’s a linguistic trick. That sentence implies a completely different meaning for the word “for”.
When I say JSX was created for React, I mean that it was created to be a part of the design of React. Meaning they both first came into broader public awareness at the same time, together, and have continued to be promoted as two independent parts of a single system.
As an aside, is that really a problem these days? All modern browsers now offer comprehensive native ES6 support. Unless you still need to support older platforms like IE or some of the legacy mobile browsers, it's mostly a non-issue.
Like you said, it depends how much you're betting on your JS to work perfectly, and who your intended market is. If all you're doing is hoping for the most optimistic JS runtime (and perfect connectivity, high bandwidth, etc.) and your site is a white screen of death otherwise, then you're not really building a robust piece of software for the web. Of course, that may not be what you're trying to do, then it's a non-issue.
Presumably IE11 will hold out forever, since it's not under meaningful development any more.
What's missing from any recent version of iOS Safari, though? Anything from 10 upwards supports pretty much all of ES6 with very minor exceptions, AFAIK. Even features from more recent versions of ES tend to be supported quite well quite quickly in the era of self-updating "evergreen" browsers.
There's also a babel script that you can drop into a script tag and will transpile stuff in the browser for you if you want JSX.
Not recommended for large projects in production (but then I'd be using webpack or similar for large vue projects too), but it works pretty well (and surprisingly fast) for quick experiments.
Moving the goalpost. I'm only pointing the fact that it is possible, and saying it is impossible is false.
Personally, I don't find the function-call format that "annoying", and I think it presents some advantages neither JSX nor template strings have, along with some disadvantages (it's more verbose, like you pointed out).
And I think GP was saying even if possible it seems rather irrelevant. You could use react without JSX but most likely you will not because you would be throwing away the good things about react.
Technically you can eat soup using a fork, but you won’t because...
When React was new and compilers/tooling wasn't that good it was pretty common to use it without JSX. JSX is pervasive because the tooling is now first class (and you'll need it if you make a non-trivial app sooner or later...at which point might as well use JSX since its there), but it works perfectly find without. My first couple commercial apps for React didn't use JSX and it was quite usable. There's just a lack of examples on how to do it these days because no one bothers.
The only time when you won't really have access to a tool chain is for quick demos with just an html page and a script tag (if you don't want to pull in babel as a script), but most online tool allow jsx too now anyway.
Agreed. When evaluating both of them, it looked like React and Vue implement the same concepts, but React did it in ways that made it more complicated than it needed to be. I specifically didn’t like that Redux and it’s docs were too heady for what it really is (it’s just event triggering and handling, why does it have to be so complicated?), and the fact that React didn’t have any official “here’s is how to build a complete app” docs. It was always “well here are different choices and project layouts you could use”. I don’t want to care about using this templating system or that. I want batteries included. Vue did that well.
If you've got any specific suggestions for improvements, please let us know! I'm always looking for ways we can make the docs better.
As a side note, React is separate from Redux, and Redux is definitely not tied to React. Here's a recent post about a team that opted to use Redux with Vue: https://snipcart.com/blog/redux-vue .
Sorry I just saw this. If you see this comment, yes I know Redux and React are separate and that you can use other state management systems besides Redux with React. However, that doesn’t help when evaluating the React ecosystem at first. I don’t want to play “pick a library, build a framework”. What I do most of the time is pretty common stuff: SPA with login, CRUD data manipulation, etc. I want a a framework that does 80% of that and has flexibility to create the other 20%. Many React/Redux tutorials are happy to oblige. But they are also all incomplete and unofficial. And by the time a large comprehensive tutorial is written by some kind soul, the APIs have changed, and you are back to SO looking for how to make the damn thing run.
Specifically with Redux, I would suggest clarifying stuff around reducers and possibly renaming them. As is, reducers sound like “a monad is a monoid in the class of ...” Vuex specifically does a very nice job of calling their equivalent thing “mutations” which is more intuitive.
My visualization of Redux/Vuex is basically an application of the event system to state management. Instead of manipulating global.state.foo directly, you ask the system to change the value of foo and a callback does it. A simple explanation like that from the start with some examples of benefits of it would be really helpful.
Also, Vuex has a less strict but more usable idea of not having to import actions. You just refer to them as strings.
Also also, examples of XHR/promises handled by Redux especially with error handling all the way from “server returned 404/400/500/etc.” to how to hand that off to a UI element would be helpful. Takes way too long to discover the right pattern for action returning a promise.
Redux is an independent project from React. You could use redux with Vue. Your other points are valid but detracting from one library because people often use another you don’t care for seems outside the scope of React vs Vue.
Which IMO is simpler to understand as a newbie than Redux. Maybe because it had the luxury of coming after Redux/similar projects and underpinning a simpler parent framework.
I’ve yet to build a Vue app that I felt needed external state management (though admittedly none are huge SPAs) but I have felt the pain in React working on a similar sized project. Just something about how the events work out of the box. React I felt like I needed to pass in functions to change parent state through a callback function in props, whereas in Vue I just emit the event and forget about it.
You can still use the function prop pattern in Vue but it doesn’t make much sense when event emission is so much simpler to reason about.
I purposefully avoid Vuex until a) the state becomes large or b) deeply nested objects (which reacitivity handles poorly, as whole trees rerender) or c) when I have lots of deep nested Components with a maze of events.
This is where I've found Vuex is a life saver for reducing complexity, organizing state in a seperate area, and having a consistent interface for accessing/mutating data without a tangled web of events and functions across multiple files/layers.
For me, how vuex works was very very easy to visualize. State, mutations and actions are very intuitive.
On the other hand, redux's reducers are harder to visualize at the beginning. Until you learn how the reducer works, every reference to "reducer" leaves you slightly confused.
I visualized redux's better with a simple example. It helps you to see how state and reducers interact.
Long before learning of React or redux I built a similar system to do IPC between two embedded MCUs.
All state was owned by the master MCU, slave MCU sent messages to the master requesting changes of state, the entire state for the slave CPU was then sent over with the requested changes.
Even what UI screen was shown was handled this way.
I was much more junior then, so the entire system wasn't event driven, all state was transferred every 33ms (iirc).
Redux is moderately more complex than that system, although my system was built in pure C and involved interop between C and C# running in an interpreter.
What I like about react is that it's batteries NOT INCLUDED, allowing me to choose tools best fit to the job. I think it's good that there's a healthy choice between vue and react, however!
"v-model" isn't two-way binding like in AngularJS where both parent and child can modify the same data. It's just shorthand for defining a property and an event handler. Like in React, properties flow down and events flow up. See https://vuejs.org/v2/guide/forms.html
Makes sense, I've done some Angular but I'm not used to Vue.
Not really related but forms really are the most painful thing to handle in all those frontend frameworks, it's driving me insane how much work has to go into them when it's dead simple with a backend framework (eg Symfony/Django)!
I ended up taking over a Vue 1.x codebase and tried to update it to vue2. We used single file components and it was a nightmare trying to upgrade. I spent a good two weeks trying to upgrade and eventually just stopped because it was just taking too long. There were a lot of breaking changes from 2.0 to 1.0, especially with the way events were handled. Now, I will admit that the person who wrote the vue 1.x version did not write idiomatic vue and that caused some problems in updating. A lot of the components we used were also not updated to vue 2.0 and, of course, they were using deprecated features. That meant I had to search for something similar to replicate the existing functionality.
I'm very happy to see React and Vue influence each other. They definitely are the highest quality frameworks out there and having two different research teams only improves the overall quality of the ecosystem.
I'm a React fan, yet I really applaud all the nice stuff which is coming in Vue 3. Well done.
Similarly, I'm a Vue fan, and them having to keep up with and learn from React's moves keeps it solid. I am very happy with recent updates to Vue and their framework is a pleasure to develop with (the tradeoff being a certain level of power that React provides that Vue cannot obtain, but it's plenty).
What makes you say that? People are actively earning phds researching implementations in different languages. JS is different because it’s useful? Runs in a browser?
Currently the architecture forces you to import the Vue object entirely , has Vue under the hood isn't really modular...
With 3.0 Vue has taken the typescript way and is using packages , similar to angular , it looks absolutely awesome to work with now.
I really hope class based components will be supported natively without compiling or transpiling.
Working "out of the box" has always been part of Vue philosophy , I really hope this continue.
This is really a big release , but it's still sad to see the 3.0-alpha branch is not visible on GitHub , i really would have loved to have a look at it.
My feeling is that most people who use Vue or React only need a template engine. Typical use case: You have an array of objects and a template how each object should look like.
So you do...
<div id=users>
<a v-for="user in users" :href="'user/'+user.id">
{{ user.name }}
</a>
</div>
<script>
let userList = new Vue({
el : '#users',
data: { users: users }
})
</script>
...to make Vue render the list of objects.
This is the only thing I ever use these frameworks for. Everything else I think I can implement in a better, leaner way myself. So I wonder if I should switch to a template engine instead.
What is the next most basic/common usecase for Vue?
One should use what is necessary and no more. If server side templates work for you - great.
My rule of thumb: if I need to do more then a trivial amount of DOM manipulation then I will use a framework, because otherwise I will end up writing my own anyway (which I can easily do) which wastes development time.
For projects with several developers a framework can help maintain common coding style and reduce ramp up time for new hires.
Also, good frameworks come with nice tooling that make for more productive development. For example, Vue + Vuex and the Vue browser plugin are great for inspecting the state and observing state transitions.
An example of my use case: I have a non-SPA app that receives various data via Websocket and the view is immediately updated. Several components take this same data and render it in different ways. Vue is excellent for this. I still use templating on the server side for the basic page structure.
So very simple, and nothing that I couldn’t do without Vue but it takes care of the boring DOM manipulations and using the browser extension during development I can watch state change (which becomes interesting when there are multiple subscriptions with data combined).
If you're just rendering HTML, you might as well do it on the server with your choice of language/framework. The power of Vue and other Javascript frameworks is in their reactivity and the ability to create extremely powerful interfaces.
I only use Vue when I need to alter the data clientside before it gets rendered. For example mark some of the users in the list as friends depending on which friends the user has stored in localStorage.
If the data is ready to render while still on the sever, I do so.
I'm DevOps, with 20+ years background in Ops. So the Dev side of things often fascinates and confuses me.
Thank you for clearly talking about why you'd use Vue and when you wouldn't. It's this sort of experience-based knowledge that I often lack.
I'm currently writing basic (very basic!) node stuff intended to further my understanding of Kubernetes: accessing a database, talking to a redis instance, etc etc. It can be bewildering trying to navigate the "oh-so-easy" basic examples of different frameworks and compare their different features.
Hm, that sounds like I'm asking for help, which I'm not - I just want to give an example of why your comments were so helpful to me!
Not sure if your use case includes automatic rendering (new/delete/mods) when the underlying data changes. If it can be done automagically (via unique id in the data) that is a big win (aka, code I do not have to write). Things like shadow DOM et al, are not something I want to implement or maintain.
When the user triggers a change of the underlying data, I do a roundtrip to the server and re-render the current page. I keep the time needed to do so under a second. My users regularely express how WOWed they are by the snappyness of my sites.
I guess what other sites save on re-rendering html, they lose multiple times on bloated code.
„Under a second“ might be ok for websites, but doesn’t cut the mustard for web applications. People expect highly dynamic user interfaces which react almost instantaneously.
That literally means that you aren't doing SPAs. If you aren't doing SPA then yes using React or Vue is rather a waste.
However the majority of sites these days use some form of SPAs.
Also under a second is a very low bar to strive to. a fast round trip to the server is 100ms. A reasonable one is somewhere around 300ms. Displaying effects to changes is often under a millisecond in SPAs and is basically impossible to reach in Multi page applications.
I'm not saying that React/Vue aren't important and drastically changing what's thought of as best-practices in web development... but just because everyone on HN uses a front-end framework for their websites doesn't mean "all websites" do it.
as a React developer, SPAs in general are overused. Most LOB apps could (and should) still be written in a backend templated language. SPAs should be reserved for applications (or even individual components) with advanced interactive features, ie a proper web app.
That's also my conclusion after toying a bit with those frameworks. You want to use them for specific pages ressembling applications, but you still want the main structure of your frontend to be defined server-side, using the most standard technology.
This lets you split your interface into more isolated components, and makes you free to use different framework depending on the type of interaction your page needs, as well as be able to update your site progressively.
yeah, for most web apps that are primarily regular CRUD+routing interfaces, you can/should use SPA tech to progressively enhance your more advanced controls. There are cases where it makes sense to build a whole SPA (I'm working on an in-browser editor that wouldn't work very well as a backend app, for example) but the vast majority of cases where React is used, it just adds complexity and challenge.
React/Redux hasn't been around long enough for its best practices to solidify in the general industry so you'll often find that companies that picked up React have a hodge-podge of incorrectly used technologies included because they didn't know the use case for Thunks vs Sagas, how to use Reselect correctly, whether to store any given state in Redux or a Container, and so on.
Enterprise apps are also a suitable venue for SPAs. You've got some developers coming from e.g. Swing, MFC++ or even Tcl/Tk, and for those doing every frontend bit in JS is closer to standard UI toolkits, instead of the constricting request/response cycle of old webapps (except those few that did some hacks with server-side continuations).
Also, in those cases a few extra seconds for the initial load or the general size of the application don't matter. It's all better than your average Swing application ("Challenge accepted", said the Electron developer).
Although this isn't something contemporary frameworks seem to aim for (ExtJS is dying, and that's good), you get close enough to desktop UI development with Vue/Vuex/Ant Design, Angular/AngularMaterial or React/Material-UI/Redux-boilerplate-reducer-of-the-week.
yeah that's basically the TL;DR of it - the more "desktop app" type functionality you need in your web application, the more SPA technology you're liable to need.
You could use string tags. The only thing that is really needed is a DOM diff library to make UI updates bearable. The rest can be completely handled with a basic MVC architecture.
It appears that there are similarities in Vue 3.0 with Aurelia, at least on the surface. Things like class based components, proxy-based observer mechanism* and the move towards typescript all remind me of Aurelia.
Been using Vue 2.0 for personal projects and Aurelia for a big work project over the past year and I have to say I am very happy with both. Personally I prefer the single file components in Vue but the class based style of writing them in Aurelia. Seeing these two things converge in Vue 3.0 together with the performance improvements looks very promising.
*Not sure that under the hood Vue 3.0 works the same way as Aurelia but the mentioned points in the slides lists array index / length mutation and later the observable function are familiar from Aurelia.
The Typescript support is by far the thing I'm most interested in. Lack of useful Typescript support is, for me, the only downside of Vue right now, and it's a big enough downside for me to use React instead of Vue in a lot of cases.
Do you reckon we'll ever see Typescript support in the non-jsx templates? I do really like vue templates for e.g. if-conditionals. I really don't like using ternary operators for template logic. And then the alternative being to hoist things out of the single JSX template breaks make code less linear to read which kinda sucks
to me the biggest downside was how vuex and typescript didn’t work well together by default. You had to rely to adding a few plumbing functions, and that felt really like dirty patching.
How about the ability to create multiple components in the same .vue file? for instance I need to define a sub-component that will be used only inside my component, this is easy in React but with Vue I have to create another file to define this sub-component, this makes the project management becomes harder as the project grows
This is totally possible. You can create a sub component, register and use it in the same file as the parent component.
Though not really recommended you can even do this:
> ... implementation re-written from the ground up
Rewriting a big project from scratch is often used as something to brag about: "Look at all the hard work we accomplished!". Except in software what matters is correctness and efficiency, not the age or the code or the size fo the rewrite. Rewriting "from the ground up" is throwing away years of bugfixes[1].
Maybe this new version is fine; I'm only suggesting that big re-implementations should be seen as an unknown risks, and that "carefully refactored problematic areas of the code" is something worth bragging about on a slide.
When your project is such a size that a single person can keep it all more or less in their head (in this case, Evan), clean slate rewrites end up being fairly efficient. It's a much different case than 20->200->2000 devs scale applications. It's vastly more easy to develop something from scratch if you'd put a lot of thought into it over time
Happy to see this project move forward, but I get surprised when I read 100% speed improvement, since it was already super fast. I wonder how they manage.
In case there are any newcomers, it's probably worth noting that just the core framework is written in Typescript, and compiled to normal JS - you are not forced to use Typescript in your own Vue code unless you want to.
FYI it takes 5.16 seconds to download the 5 megabytes of vendor JavaScript needed to view your landing page from a cold cache (and 2 for your app itself), not to mention the 6 seemingly needless Firebase API calls or the fact you're running the development version of the Firebase SDK.
No matter how awesome you think whatever framework is, this is a terrible, terrible experience.
A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it was so easy to switch to it.
Transition from vue1 to vue2 was really simple. I'm sure the same will be true for v3.