>Another important thing is that I take long breaks (several weeks) whenever I feel I need to — which is probably harder to do if I’m a full time employee at a company.
A "Patreon-funded full-time job position" and the ability to take weeks off at a time? What an amazing career path Evan has taken. He sounds so passionate about Vue and he is fully funded to be able to do it. And what a good project to fund, always moving forward but at the same time pushing for the features that users want.
It sounds lucrative and leisurely, sure, but it's not a career path I'd personally be interested in, because (caveat: I don't know the guy, I'm not involved in Vue, etc; generalizations ahead) he's very much a community manager, possibly moreso than a developer. He's got huge responsibilities and accountability, whereas I prefer to be (proverbially) holed up in a basement with my work laid out for me.
I mean I basically have online social anxiety in that I don't tend to go read my old comments and possible responses to it. I rant without standing for and defending what I say. If you run a project like Vue, you can't avoid things like that.
This is what you'd expect, but he is very hands-on trying out technical ideas. I would look through his tweets to see the things he gets involved with.
Recently he built Vite to see if it'd be possible to have a dev setup with no bundling (just using ES modules). It's evolved since then, but he picks up work a lot on new ideas and seeing how it can drive the direction of Vue.
I experience similar anxiety. For too long I kept my profiles (GitHub/Twitter/..) pseudo-anonymous. So that If I mess up somewhere I don't have to face the consequences after I shut that account down. This is primarily due to social anxiety rather than having any malicious intent.
Accountability! It can be scary, but it's also important and a driver for positive change.
I deal with all of these things as well, but have pretty much decided to not go the anonymous route, because I would rather try to build that confidence in myself and embrace the accountability that comes along with it.
That said, I still don't comment or publish much online out of this same anxiety. /shrug. It's a work in progress :)
I had that too until I ramped up my own noise signal. With twitter I hooked up a couple of RSS feeds via IFTTT. I do tweet more but send out 20 RSS tweets also. Perfectionist is a creativity killer. Nobody fact checks and remembers what you tweeted a month ago.
I do keep my hn profile low profile because it is also nice to have an outlet for fresh idea's and opinions that need refinement. I actually change my mind the most about things I comment in on HN. On my work everything is within the Overton window.
It sounds pretty good until you realise that it is the peak of open source full time job. And survivorship bias is taking place here.
Evan took a huge leap of faith when he quit his job for working full time on vue. I am happy that it has worked out well for him.
But it does not mean this path will work for other open source developers, of course they can still get corporate backing(node.js) or paid to work on it (react/angular) or make a business offering around it (laravel/tailwind)
This is new and exciting but we must understand the use case. For solo developers on projects with a huge amount of github stars this might make sense. It enables you to work on the project full time.
The tailwind project model seems like it would pay better. The profit amount might make for sense for the pretty popular project vs the extremely popular project. It's a compromise because you stop working on the core project and start building these additional businesses that take time/effort away the project.
Corporate backing would make sense but enterprise has picked react. Vue lives because it's a great framework that is easily assessible not because it started as a corporate sponsored project with a popularity boost buildin.
>$16,000/mo, enough to cover his salary along with his new hire
That's $192k, pre-tax, between two people and likely infrastructure and tooling costs. Most developers of You's skill earn nearly double that at FAANG companies.
Yes. He would more than double that by joining at the E5/L5 level at Facebook/Google, which he's almost certainly qualified to do. But given the success of Vue.js and his status in the JS community, he'd probably be a marquee hire at the E6/L6 level.
However he would be sacrificing a lot of autonomy to do so, because Vue.js would effectively be developed under the same corporate stewardship model as React and Angular. He doesn't make as much money as he could given his accomplishments, but he maintains broad control and ownership over his work.
Likewise his Patreon sponsorships can increase over time as Vue.js increases in adoption. And if he wants more income, he can take on lucrative consulting contracts for Vue.js deployments with large tech companies. A few of those per year would likely meet or exceed everything he's bringing in through Patreon.
So that’s his Patreon earnings. Looks like he’s also making money from OpenCollective, and if I’m adding it all up correctly it’s about what an E6/L6 at Facebook/Google would make?
Isn't running a project more about the outcome than putting in as much time as possible? Also taking long breaks could potentially mean being AFK but still obsessing about next steps in the project. Maybe you're imagining him being on a tropical island drinking mochito's during the long breaks?
For me it's the opposite. I dread to see a Patron cancel so I can't take any time off since I'm imagining any "slacking" will lead to cancellations. It really feels like a race against the clock with every Patron is on a thin line.
So I recently had the opportunity to use the new composition API, which will come in V3, in a project and want to share my two cents. The project had some limitations tho: no webpack and no typescript (so basically inline x-templates and pure browser JS).
Starting of with the composition API was great. No "this", easy reuse of logic via react-like "useXYZ" hooks and a general fast development. But two things really bugged me:
* You need to be really careful when passing around values and how you handle them. Destructure a Proxy object? You instantly lose reactivity. Not using a reference to proxy object in computed? Changes won't trigger the computed function. There is a lot of magic involved and while it may seem that it takes a lot of "thinking" from you, once it doesn't work you will have to rethink and maybe even ditch some of the underlying language's features.
* "ref" vs "reactive", where "ref" is used for primitives which need a proxy object wrapper and "reactive" is used for objects/arrays. Now, my primary problem is that you again have to use specific operations based on whether your using ref or reactive. A "ref" array can be easily set to an empty array via `arr.value = []`. If you try this with a "reactive" array, you will lose reactivity; you would have to use `arr.length = 0`.
TypeScript detects a lot of those pitfalls and, IMO, it is essential when using the composition API. Without it, there is too much invisible magic happening.
I used to prefer (and by a lot) Vue more than React because of its simplicity and completeness (router + store + everything you need).
After trying to use v3 for a new project and trying out the composition API, I've gone back to React.
With v3, and the composition API, to me, it lost all of its appeal (being simple, easy and complete). Now to me it has the worst of both worlds... it's not as easy anymore, has a lot of gotchas and conceptual overhead.
The same thing happened to Meteor.js, another project with which Evan was involved. Meteor started out with an ethos of simplicity and friendly developer experience. It lost it's ethos and was picked apart in the name of "scalability". This has left people in a lurch who were drawn into Meteor for it's simplicity and now have projects to maintain in a largely abandoned framework.
I've primarily moved over to Django with server rendered content and sprinkles of JavaScript where needed.
This is the appeal of Phoenix LiveView for me. Server rendering was already incredibly fast with Phoenix, but the ability to forgo the majority of JS with LiveView bypasses all of these framework complications.
Oh well wait until you hear about Laravel. I appreciate that there is still such a large developer community committed to pushing traditional server-rendered web apps forward. Laravel has some amazing stuff for creating presentation layers within the framework, the most exciting (to me) is Livewire
Have you considered that this might be an issue on your end, and not the V3 Composition API's end?
4 year Vue dev here (right after 2.0 release). In Vue 2, you have a bunch of "magic" properties. Your state goes under the "data" key, computed properties go under "computed", methods go under... etc. Then you have the lifecycle hook magic methods: "created()", "destroyed()", etc.
In Vue 3, you have one function -- "setup()". This function returns the stuff you want to use inside of your component. This could be state/reactive data using "reactive()" or "ref()", derived data using "computed()", watchers, plain functions, whatever.
If you need to use lifecycle hooks, then you put an "onMounted(() => {})" or whatever in your "setup()".
The API was stripped down to essentially one initialization method where you set up everything you need.
Though to be fair, these days I write Vue like a weirdo and I use JSX with it.
This doesn't add up. None of the simplicity or completeness has changed, and the composition API is completely additive and optional. You can still use Vue exactly like you always have, with better performance and flexibility.
Do you use Hooks in React? Because in that framework, that actually is replacing the older methods, and if you use Hooks then the Composition API is the same (and better in many ways).
> will likely be the de facto standard if/when the majority of projects and tutorials use it.
Why would you think that? To me it sounds like a completely unbased opinion and goes agains everything that I read in the v3 documentation or in numerous discussions.
> Possibly the biggest change is our new Composition API, which is entirely additive- the previous Options API will continue to be supported, as the Composition API is an advanced feature.
Agreed. That's generally how these things are introduced.
It's a shame, because Vue as it currently stands, offers impressively simple answers, to many complicated UI development questions.
Yes I fully understand this. Also with vue2 you often get problems with the internal version of "array" that is wrapper around a normal array to detect changes.
At least a year or so ago, when I was still working on a Vue project, some external libraries didn't work with Vue reactivity due to the way it was implemented by overriding Array built in methods. I think we ran into this issue with some lodash functions.
Haven't looked @ v3, but I have a question: why would the Proxy object be available to destructure? Why not use a revocable proxy that is only a proxy when it's being modified through accessors? Why would any state management library author expose a Proxy? It should expose ubiquitous, useful, human-readable, undecorated save for maybe Symbols, JSON.
Vue is the one js framework that was really a breeze to learn. In most cases, your first attempt at doing something in Vue will just work the way you intuit it to work.
The Docs take Vue to a league of its own. I'd contend that no other JS ecosystem has docs that are as lucid, concise and beginner friendly as Vue's. This intro to VueX (Vue's state management library) is a good example: https://vuex.vuejs.org/
Are you guys all using ad blockers? I open Vue docs — and the right-hand column of the screen is a wall of ads. For comparison, I open React docs — and there are only docs there (unless you count the obligatory BLM header). With a larger font, too, because there, docs don't need to compete for page space with the ads.
You might want to check your browser/machine for something hijacking and inserting ads. The only ad I see is in the top-left and it is very non-intrusive and doesn't distract from the content at all.
Yes, there are ads. Top promo, 2 spaces for sponsors, and a small banner from Carbon ads. Depending on your resolution, it can take up significant space:
It's not noticeable on larger screens but they should consolidate these to a single location and definitely don't have a banner ad in the main page header.
For the reference, since the comments made me realise we might all be seeing Vue docs page differently, here's how it shows up for me (no ad blockers; ads in the top, top left and right corners of the screen):
I also have no ad blocker and see just the one small non intrusive ad. No PiHole or custom dns either. Might be worth looking deeper into what’s going on to see if something on your computer is injecting ads into webpages you view.
There is a small, simple ad in the top left, above the menu, but that's it. If all ads were like that and I had no privacy concerns, I would not even need an ad blocker.
I'd say that Svelte's are better, plus the tutorial teaches everything. The nice thing with Svelte is that there's not much to it and you can read the entire docs in a few hours.
The biggest good side of Evan I think is that he stands out as a non doctrinaire among webdev stars, not claiming that this, and that pattern/paradigms is the biggest thing since sliced bread.
Projects driven by "biggest things since sliced bread" tend to vane very quickly after the initial excitement, and agiotage about its buzzword feature is gone.
Can confirm. Vue was the first framework I learned and I remember it being super intuitive. The only thing I couldn't understand at first was Vuex because I couldn't work out what the point of it was. This was probably because I hadn't ever seen an app big enough to benefit from it.
I know there was a big meme about how js frameworks come and go every 2 years but it feels to me like react and vue are almost the end game frameworks. They work so well and have been so stable over the years that this might be what we end up with. It almost blows my mind how they manage to make such simple interfaces for things that are super cumbersome in plain JS
I've implemented Vuex on a Vue 2 project to reduce adding props all the way down in my sub-components. Looking back, I would only add Vuex to a project if it needed it. Hint: small projects do not need it. Just rely on "Events up, props down" for your data flow.
And if you want a component UI framework (not everyone does!) then checkout out Quasar [1]. It's amazing... fantastic docs, really well thought out defaults and customization, easy to theme, lots of Tailwind-style helper classes, just overall fantastic.
Interesting! I went the other way. For whatever it's worth, I found lots of things in Vuetify that weren't documented, and overall found things less polished and complete.
Quasar is great as long as you can work with the flow for Quasar. The moment you need to step out of it (such as having multiple entry points from a single codebase), it’s hard to work with.
Whenever people mention how awesome Vue is, there is always a comment that nothing beats vanilla JS.
I recently I learned that it not always true. As a matter of fact Vue (and many frameworks) does a lot of optimization under the hood to keep your apps breezy.
For example when you're dealing with lots of data, One of such concepts is re-using input fields and DOM elements via keying. So if you are trying to render lots of input fields, Vue can intelligently reuse(1) the components so as to make minimal changes to the DOM (implementing this vanilla JS is possible but might require lots of efffort).
Yes. No issues with Webpacker as Vue is officially supported. In fact my quite old project is now augmented with Vue to make several micro-SPAs in interactive parts. Layout HTMLs are served the standard way with Haml. To get things faster I sometimes render data JSON objects in HTML page script tags to get rid of initial fetch - works nicely.
We do the same. The page loads with a div containing something like: `<%= content_tag :div, data: { behavior: 'vue_app', 'initial-data': { some: 'json' } %> <html spinner> <% end %>`
Great stuff, waiting for Vue 3 release, then after a few weeks will start updating my current project.
As a former backend engineer, I'm really grateful to be working with Vue. I used Backbone, and a little React and Angular before. Vue was the simplest and the most fun so far.
I really love single file components. We are extending the syntax more by also adding <specification> and <requirements> tags to single file components. Great for automatically generating documentation and keeping it in the same place as the components. Was a bit afraid that the compiler would protest, but so far so good.
Vue (like with most of its features) let's you do that if you want. The <script> and <style> tags in the .vue file can reference other files so you can have a directory per component with separate code files. Sometimes that's helpful for better code completion and formatting too.
What’s to stop you using single file components in React?
Having everything in one file was the thing I didn’t like about Vue - constantly scrolling up and down the file between the methods and the template/styling got pretty annoying quickly.
What’s to stop you using single file components in React?
The only way I know of to make them is to use styled components. RedwoodJS seems to doing something like a template literal for styling but that's still not really the same. In my opinion Vue's <style scoped> approach is much more elegant.
constantly scrolling up and down the file between the methods and the template/styling got pretty annoying quickly
>The "Function-based Component API" proposal for Vue 3 received a massive pushback from community members.
I'm having a hard time getting on board with the Composition API. I'll admit I was one of those that pushed back against it. While it looks like a powerful API and I think it would be a great replacement for mixins for instance, I don't want to start writing all my components with it.
BTW, My main fear was not that they would deprecate the object-based syntax, like Evan points out in the interview. What I'm worried about is now walking into a Vue role where I don't know if they're using Object syntax, Class syntax, or the Composition API syntax, or a combination of all three.
My fear was partially confirmed when we had a meeting at work about the upgrade path to Vue 3 and almost all of the other engineers stand in support of writing everything with the Composition API.
Time will tell if the Composition API becomes like React Hooks in terms of popularity I guess. But I'm already using frameworks like Svelte, and a few others at home as a kind of backup plan. BTW, Some nice looking, Typescript-friendly frameworks I've also checked out are https://aurelia.io and https://stenciljs.com
How was Evan able to work on Vue while employed by Google? Didn't his contract have a clause in it (as I know most tech companies do) that more or less states: anything you make while working here is ours, regardless of wether you do it in your free time or not (especially an Angular competitor).
I was turned off of Vue when they put a big "Join BLM" banner on the top of their site.
In my vue, that is mixing politics and personal opinions into a public coding project. I believe this to be a non-no. It implies that those that don't share your [unrelated] views are not legitimate.
In this example, it implies that those who are pro-minority rights but anti-protests are in some way less committed than their pro-rights and pro-protest counterparts. Which is not correct - there are many, many people like myself who have dedicated their lives to helping minorities, but think it can better be done if we don't turn them into victims.
You can disagree, but don't make it part of the code.
I encourage all large public projects to please respect the opinions and efforts of all their users and possible contributors, even if their users are not woke, or try to do good in ways other than you would.
The banner is gone, so am hoping that other commenters will respond to this as an example, not as a specific. (In other, don't defend BLM, there are other venues for that.) Please, please keep politics for the media to exagerate, and keep large projects politics free.
edit - sigh For all those erstwhile readers that are righteously downvoting me into oblivion - that's fine. I respect your right to consider my verse worthy of ire. But a comment to explain why you disagree would be so much better! Angry destruction without reason is already plentiful, but it is neither constructive nor persuasive. It reinforces the feeling that you will happily cancel anyone with another point of view just because you don't care to hear it.
People are not obligated to tell you why they don't like what you say. It's nice when you do get a reason but to liken a downvote to "angry destruction without reason" is a major reach. You are not entitled to their time.
I didn't downvote you but I'll tell you what rubbed me the wrong way about your comment. I think people who did downvote you probably felt similar. In short, I think your comment is patronizing. You imply that the people protesting are doing so in part as a result of "media exaggeration" and being "turned into victims". I read this as you saying that things aren't actually that bad, and the people protesting are doing so based on false pretenses. Your comment has the paternalistic air of "I know how to help these people better than they know how to help themselves".
I guess the question is really - Is the site bringing politics into a non-political venue - or are you requesting that they suppress any views that make you uncomfortable on their site ? Would be analogous to going to someones house, eating their food for free and then regulating the dinner conversation.
That is a good point. I personally think that even when you invite a guest you don't know to lunch, you should steer clear of emotionally charged subjects, but that may be an extreme position.
But in the case of a project with over 50 branches, and hundreds of thousands of users, that advertises an active community and wants me to get involved, then it is entirely something else. There I think that great pains should be taken to keep out emotionally charged views, as there are bound to be lots of people that you actually want to be part of your community that will feel out of place. Hence my statement "large open source project".
> It implies that those that don't share your [unrelated] views are not legitimate.
Does it though? That seems highly sensitive. Also, their support of BLM does not necessarily mean they support violent protest. They could be using their platform to show support of the movement and peaceful protests, which are critical to a functioning democracy. So are you anti all protests, or do you make the distinction and oppose only those that use destructive methods?
I am anti protests of the type that BLM represents, even if they are not violent.
Creds: I moved into a low-income area and have spent the past ten years providing education, money, and support, trying to improve the lives, and championing the cause of those living in such areas. I adopted a kid with a police record longer than your arm, and worked with him getting detoxed. I spend most of my waking hours on this, all volunteer.
I grew up in the projects. There was a dude some ten years older than myself - a programmer (back before computers were a thing) - who convinced me that I can do something with my life, but I have to take the onus of responsibility upon myself - even when it is someone else's fault.
That's the message I now try to give over - you guys are awesome, and some day you can change this whole here community around. But you gotta take the whole responsibility upon yourselves - especially when it is not your fault.
That's a big message, and hard for me to write in a post like this, but it works. I have hundreds of students that have healthy lives, and we have grown to 30 volunteers who help me.
When there are riots like these it passes a huge message - it is all "their" fault, and "we" deserve everything because of it, and we don't need to take any responsibility.
So, protests have a place. But the way that BLM projects it is, IMO, destructive, even if there are no riots.
Edit: I am not dismissing the bad and uncaring attitude projected by the police or government. I am not dismissing the emotion, anger and sometimes guilt of the protestors. There are protests and other actions that can be extremely useful. Perhaps thought can be put into what objectives can be gained, and how to get them, and then think if supporting BLM is really the way to get them. (Also, I know a few people who have joined BLM protests as a way of protesting Trump. IMO, not the best way to do that, either.)
Thank you for taking the time to share your message and experiences. You seem like a very good person.
I agree with a lot of what you say, and also relate very much to your message about accepting the burden of personal responsibility - as difficult and unfair as that may feel at times.
> So, protests have a place. But the way that BLM projects it is, IMO, destructive, even if there are no riots.
This is a position that I also very much agree with, and something I think many people either do not understand, or will not admit. I've seen your other responses to replies on this thread and think you are right that there are many, many people that feel very similar to the way you (we) do.
If you wouldn't mind sharing more info on the (your?) organization you spoke of, helping students and coordinating volunteers, I'd love to learn more about your efforts to lift up people around you.
I disagree with you and I will explain my reasons why: BLM is not about politics or personal opinions, it is about human rights, so is the LGBT flag stuff, so is speaking out against the chinese governement for the Uyghurs genocide currently being carried out.
You know what has happened to Georges Floyd, Breonna Taylor and many others. People murdered routinely by the police without any consequences. Using whatever platform you have to speak out against it is morally right. Protests happens after decades of police violence against black communities, by being against those you are standing against an human rights issue (Whatever is your reason, even COVID). You need to be aware of that and think if that's a good use or your life. Plenty of people do, usually white nationalists, KKK members and neo-nazis, who are vocally againsts humans rights and equality between white people and people of colors.
I also am pro human rights. Very much so. And yet I think that BLM does it all wrong, and all that will come out of their protests are more police, more government, more bigotry against the blacks, and more slums.
I suspect that there are a lot of people like myself.
BLM is showing us uncomfortable reality, which is how poor black people are treated in the US. For anyone slightly better off, all this pain, anger and the violence which stems from it is difficult to process and can lead us to cognitive dissonance to avoid these feelings. "they're doing it wrong! BLM is violent thugs and terrorists, if they wanted results they would be 100% peaceful. They're working against these causes!" is that cognitive dissonance.
Turns out, human rights activists have been peaceful. For decades. It did nothing. Even filmed in broad daylight, with people begging him to stop and with the whole world watching it on the internet, a police officer can still murder a black man and get away with it. Which they would have without the protests. Now, each time that happens, there will be a wave of righteous anger through the country. Until that doesn't happens anymore I hope.
MLK's protests weren't peaceful. There was the same stuff happening, looting, violents elements, confrontations with white nationalists, and they've changed things, tremendously for the better. I hope the same happens with BLM.
It always gets a groan out of me. They come across as self-serving, like big corporations that run commercials to talk about how great they are ('we here at widget company X care about Y').
In comparison, the charity-ware of vim is fine to me. It does what it's supposed to without all the backpatting.
BLackMail. If you don't add the banner it's because you're a racist.
The equation is do you lose more patrons by having or not having the banner (and be accused of being a racist). Easiest, and most profitable, to just to add the banner...
Reminds me of the Silicon Valley episode about Tethics where Richard is forced to sign Gavin's pledge for exactly this reason even though he's in strong disagreement.
What backlash against Vue 3? I know that there were very passionate discussions about several different RFCs that eventually lead to the current Composition API. But as far as I can tell, the current Composition API is very well accepted in the community. Also, the Composition API is an addition and does not replace the API of Vue 2.
So do you refer to the controversies about older RFCs? Because I can't see any other backlash. BTW, having discussions in an RFC is a good thing as it helps getting to a better overall solution.
> creation of Svelte
How is Svelte related to Vue in general or Vue 3 specifically? Svelte 1.0 was released in 2016 and I can't really see any irony here at all.
I don't know much about Vue but the single file components used in Svelte was inspired by Vue.
I think they share more goals than they compete on, with Svelte being newer (compiler based) and Svelte taking an older style approach (Virtual DOM) to implement those goals.
No, I don’t see any irony here. Name one programming language/framework/tool that’s universally game-changing for every single developer. The reality is that technology doesn’t work that way.
The fact that detractors of Vue exist in no way means that Evan doesn’t care about users. It’s very clear that he spent years working on a problem hard enough to build a solid response to React, a project with so much more momentum and money initially.
There was a misunderstanding when documents outlining vue 3 were released. Users thought that advanced functions for component reuse were replacing easy to use existing features. Vue 3 is backwards compatible however, and it was a non-issue. The new features looked great for advanced component builders from what I remember.
A "Patreon-funded full-time job position" and the ability to take weeks off at a time? What an amazing career path Evan has taken. He sounds so passionate about Vue and he is fully funded to be able to do it. And what a good project to fund, always moving forward but at the same time pushing for the features that users want.