I joined a company with a Vue app just before the Vue 3 release. I don’t think anyone believes it was a soft launch. Then the tooling like nuxt did the same with a v3 release countdown timer which only then released it was in beta with no support in their ecosystem. You could pay 10k for a consultancy though. I only wanted webpack v5 to be able to use federated modules to give us more migration options. The whole experience reminds me of Angular.js to Angular so I was quick to jump ship and spend the migration effort for v3 in moving to react. We spoke to a contributor too that basically told us we should wait for v3 because currently it’s not really built for SPA. Vue 2 was a web application framework and I could see the benefits for php/python/ruby frameworks with losing JSX and being more understandable for fullstack engineers in smaller teams who might not know React. They have now made a direct competition with React though and badly implemented a lot of apis (simple things like grepability and codemods are lacking). They struggled with this release for a year and now they are still behind where React is focusing on server components, concurrent rendering and the tools we need for WASM to be implemented in the most performant ways now ie11 is officially leaving support this year. Some have said it here too that the whole ecosystem felt beta and now the largely community based ecosystem is either leading to vue3-* packages which just make an upgrade to Vue 3 a full on migration.
You are doing a full migration to React because of the update from Vue2 to Vue3? I read the Vue3 docs for the key differences and it looks a lot easier to migrate to Vue3 than React....
The question is what next? Our team had already started migration from vuex to solely using Apollo. Apollo then changed their own standards like depreciating local resolvers. Vue 3 release seemed to change regularly from will it or won't it support ie11 and various other additional packages. It is fairly easy to build React-in-Vue code to do a similar migration but the "experts" in Vue often just live in the short term without really committing too a level of support that an enterprise team needs with 20-30 developers. With React I'm sure any major changes will be a phased thing so I can continue to upgrade through the major releases for new features while updating code to new patterns. There is usually codemods to automate any changes because the coding patterns are highly developed to be testable and consistent to change. Similar support exists around the community of packages like Redux. Vue is stretched across multiple projects like state management, build tooling and DX while genuinely being behind the curve in best practices like testing and static code analysis. A Vue 2 to 3 migration is really a complete overhaul of every component to allow you to upgrade to v3. That is a huge liability of an inexperienced team who I expect to make similar mistakes with their community.
Dunno dude...your team changed from Vuex to Apollo and then from Vue to React...if I were to guess, next year you will be making other changes....is the constant variable here the framework/tech or your team!?
It is the way of these type of early projects and generally you have some organisational and technical debt either direction but receiving downstream features while supporting legacy code is the general way in React. It was going to be a Vue 2 to Vue 3 migration but moving to React should take us out of these higher frequency changes from Vue ecosystem. I don't see you rebutting or adding anything technically here. I wasn't responsible for the original stack and no we have a roadmap for the next year or two which is the same tooling give or take. Avoiding the high breaking change libs like apollo for URQL and using their cache for simple queries and Redux when we need more.
Yeh it is why I put Vue as a great web application framework for developers not specialised in frontend solutions. They've been fragmenting their community there by becoming an SPA framework to compete with React. Vite is a good tool but we have many others that are simple to use. This one is just has 1st class support for Vue because it comes from the core contributors. The general ecosystem for vue though is a third party package which integrates something like vue and apollo together. Which is not supported by the vendor and falls behind major releases or makes drastic changes to fit new major releases of the Vue framework. You will find a lot of vendors not supporting Vue directly and those unmaintained projects are leaving you behind in feature set or using new anti-patterns and creating tech debt.
vue3 is still much easier for newcomers to grasp comparing to react, biggest difference though is still js-in-html vs html-in-js.
vite is from vue3 originally, I consider it's one of the best 'by-product' from vue3, it's 10x simpler than webpack and 10x faster too, I use it for all javascript/typescript projects nowadays.
That isn't a thing from Vue3 though. It has come from esbuild and swc projects. Both are now looking to fully support typechecking in a lower level language rather than having JS tooling written solely in JS. You can use vite for React too but it does lack certain features for us. I could get reasonably the same gains using webpack with swc loader or esbuild loader too. It is really just a preference on type of projects. For small starter applications a tool like vite is cool. If you're looking for ways to distribute many common applications with shared vendor libraries and seamless transition between microfrontends then federated modules is a big feature of webpack.
I’m 32 and in a similar situation. I lost my mother and both brothers within last 6 months of last year and ended up questioning everything.
Even though I was in this moment of time where I was questioning everything I couldn’t actually move forward with any of the changes I wanted. The big mental changer for me was the gym. Not necessarily for health but because everyday I’m pushing myself to failure and also seeing improvement.
Even though I have hobbies like photography and being a drummer to be honest I would be frustrated at that type of failure and avoid it. Maybe the lack of feeling creative is too personal to face right now. Since the gym I feel like that’s improving and I am slowly reaching out to a social circle again and seeing new opportunity.
It has improved my mental clarity and personality too. I am lucky to have my girlfriend of nearly two years and I was preparing to propose before all this happened. I would question that too but I started to realise I didn’t want to be this person running from my problems in different countries again. I didn’t wait for the perfect time but did the best I could and that went well.
I suppose for me in the area of finding a partner was finding faith in myself again. At around 30 I was about the same and hadn’t been with anyone I could see marrying. I couldn’t seem to attract the type I saw myself settling with. I think that changed with the gym too and applying focus to my new interests at the time like photography.
After I stopped trying with my current fiancé, maybe a year and a half of our first meetup, she started to see who I am and what I could be because I was just applying myself to improve my own life. I think we all like to see that in each other no matter gender or preference. It can just be within your friendship circles after you grow out of drinking buddies.
I think you know it’s not your too old to go out a be that guy again but you don’t want too. Trust me I have old friends your age who are still acting like their 20 and reliving all the same mistakes. Right now you just need a physical parallel to what your mind needs to do. Fail early, learn and adapt, improve and grow
Integrated sensors really. Things like AF would work on different sensors in DSLR. Sony removed the mirror and put everything on the sensor. Fast AF tracking, shorter distance between sensor and lens so better low light capability.
This is the answer really. Wealth accumulation and powerful enterprises lobbying and dividing societies in their own interests. Whether its BP making you believe your own carbon footprint offsets there or social media giants playing to one-side in an election to keep favourable rules in place. You won't see this common sense in politics though as it would open more competition if they weren't able to using lobbying to support their own reelections.
> We think that Auth0, Firebase etc are great services but auth is complex.
Yep that tends to happen when you are supporting SSO and certifications like OpenID Connect. Using one SSO portal to handle mobile, spa, web apps and code auth with evolving techniques like PCRE. That's probably why some customisations are not available too because it breaks the standard. You will just end up with the same models once you've implemented all the same features. Okta, Auth0 and others are all really similar because of the standards behind them not because they thrive to be complex.
Agreed that the standards make things complex. However, some of them, like OpenID connect are not required for several apps that want just simple email password login (an example). This is where our idea of modules (or recipes) come from. If you choose a module which has nothing to do with OpenID connection (or similar spec), then you do not have to deal with it's complexity.
So essentially the way we hope to solve this problem is through our modular architecture. You can start off simple and then just keep adding the modules you need instead of it all rolled into one implementation
I built an app for major sports company in the UK several years ago now. The choice as actually the most cost effective. Most providers of the data, usually collated by people using an Xbox controller and relay device in the stadiums, are uploading static files to storage. We used a thin node.js layer to stitch these from a connected volume and expose them via an endpoint which would specify a time range. If a user never requested the results for the 36 min in a game then our solution wouldn't have to do any work. Once we did process a request for a user for a game at a given time range then all other users would then receive the same cached result. It was very cost effective when you compare millions of users requiring websockets and processing all the events regardless of whether someone is watching those results.
