@Vue team if anyone should read this:
I'd recommend to rename vue in the process (for example vueNG or whatever) in order to reduce the amount of false/outdated information when searching for a topic.
This. I like that the Vue team thinks of ways to improve on the current state of the art and welcome new ideas, but please under a different name. It needs to be succinct enough so that search engines can distinguish the two. Otherwise, there is a big risk of things becoming confusing and frustrating quickly.
No rewriting needed. Hooks are just another way to do what was already possible in a more well-defined way. All the content written is still applicable. Now there is just a new way to do things too.
The developers and documentation even advises against rewriting old components with hooks unless you need to.
You're gonna have to learn it eventually to work with other code bases and so on. But the point was it doesn't change existing knowledge, just something new to learn.
Since the majority of the community will probably be using hooks from now on it will be assumed that is the default React methodology which will break books, talks, blog posts, SO answers, etc.
You can mix-and-match. If you want to write an individual component as a class you can, and if you want to later convert it to using hooks there's nothing stopping you.
So they should have renamed the whole framework when they added a single a new feature so people know they need to learn it before reading the examples?
That's quite hyperbolic. Functional components have existed in React for a long time, hooks are just adding existing concepts (state and lifecycle operations) to them.
The point is that you don't have to use it. If you can't be bothered to learn a simple new feature then just keep doing it the old way; your code will still work. I don't even understand the complaint; are they never supposed to change anything? It's totally optional; even if most of the community goes down that direction you don't have to.
Beyond that, hooks are super simple and the complainers are just making a big deal out of nothing. They are just callback functions that you implement outside of a class instead of overloading arbitrary method identifiers like "componentDidUpdate".
This is what I don't get about hooks. Remembering Markbages great talk on 'Minimal API Surface Area'? How is having multiple ways of doing the same thing minimal API surface area?
React is losing sight of what made it great when it came out. Do one thing, do it well, and do it the simplest way possible.
That sort of absolutist logic will never allow a framework to progress and become better. Sometimes good ideas come around (IMO like hooks) that are worth increasing the API surface area for.
I for one loathe using class components now and not being able to share logic compositionally via hooks when I work with them. I feel more productive and I feel like my components are smaller and more focused, and I don’t repeat myself as much. It’s been a net win for me, and I think it’s well worth having two supported APIs that do roughly the same thing.. because despite this, React is still a small and focused library API-wise.
I haven't done front end work for about one year. Looks like I'll be re-learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.
This change is large enough that’ll be looking at the alternatives after more than two years of defaulting to vue, I mean I may still pick vue but I’ll be looking now where before I wouldn’t have.
Change isn’t a bad thing but nor is change for changes sake.
> Change isn’t a bad thing but nor is change for changes sake.
I can understand that the changes here might not be worth it to some, but to call them "for change's sake" is disingenuous and unfair to the Vue team, I think. The linked page clearly motivates the changes. Whether those motivations weigh strong enough for you is a different matter.
I feel like I'm shilling a bit for React over here, but they are nearing two years without major breaking changes, and has been the de facto framework to go to for quite a while now.
Well, I mean, sure; if you're using something now, keep using that. I was mostly responding to the use case of coming to front-end after a year of not doing that. If you're going to "relearn everything", consider React; then that'll hopefully be the last time in the foreseeable future that you'll have to do that.
It seems inevitable that hooks will be the only API 3 years from now though, and its already the case that all the new literature and examples are only going to teach hooks. Vue might maintain compatibility just as long but they've totally hosed their messaging on this judging from all the comments in this thread.
The internal politics at Facebook seem really smart here - the React team have said they’re responsible for keeping all the React code there working and updated when things change with the library. So it’s basically infeasible to make breaking changes that can’t be fixed automatically.
I always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into.
Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.
This is completely true, but in my opinion there's no overlap of usecases where either one of these frameworks or vanilla js are both reasonable solutions. If you have a usecase that vanilla js is reasonable for, using a framework in the first place was just a plain bad choice, most likely.
I'm not sure everyone makes that consideration. I reckon many developers would chuck a JQuery or React dependency in without thinking about whether it is the right thing to do, because they are used to it.
Doing things in vanilla js just means I end up duplicating a lot of the framework code. Vue really was very simple and minimalist. Just pass it your object and it's reactive and very easy to get started. Fairly unobtrusive as well.
Scope creep. It's really hard to say "no" to feature requests, especially if hundreds of people give it thumbs up, but it's a necessity if you want to keep your project from bloating over time.
Yeah I'm not saying it's a positive or negative change. Just an observation. Personally, I'd rename the next version to something else and let Vue be Vue, where Vue was founded as a replacement for the bloated SPA frameworks and super easy to just drop in and use.
I've been following the Vue + TypeScript progress on and off for the past couple years (ever since I converted a React project to Vue and threw out TS in the process, since it was just so fundamentally incompatible with Vue's APIs). This is a pretty wild change compared to the now-abandoned class proposal, and I'm somewhat bummed by it, but I'll admit that's mostly due to my continued skepticism of hooks (as someone who hasn't yet adopted them in my React projects, either).
This will require one hell of a migration path to support and I imagine lots of people will be on that "Compatibility Build" for a long time. I'm very, very curious whether folks who have large-scale Vue apps have had a look at this proposal, and if they've had any input on it.
I’m curious what it means for people using single page components and how the default exported module would be structured with the new API. All the examples use the inline template strings.
The primary change seems to just be merging most of the keys/options (data, computed, watchers, etc) of the module into various functions within setup() which itself may require from coding best-practice guidelines since setup() is going to get pretty big.
I’d love to see a largish component converted to be able to compare the two instead of the small examples with one or two functions within it.
I really disliked the function API and felt the class API with decorators was much easier to read and work on.. I'm pretty sad they are doubling down on function API and, apparently, ditching the class API?
The class API will remain the current status of an add-on. The idea was that if we make the class API built in to the core, it will somehow be better than now and remove all the issues with it. More and more into the game it was turning out that's not that easy.
Even the decorator thing was problematic. Remember that the core Vue library is supposed to work both with and without build tools, but in case of TypeScript it's not possible. There is a decorator proposal for JavaScript but it works differently than the TypeScript one so there would be a clash.
In the meanwhile we found out a new solution that not only solves these but also some other problems (composability).
No one is forced to upgrade. An ecosystem with optional churn is better than an ecosystem that has no churn just because people aren't creating new things for it.
The page mentions providing a compatibility build:
> “The proposed APIs are all new additions and can theoretically be introduced in a completely backwards compatible way.”
One thing they want to avoid is the whole Python 2 vs 3 distinction that went on forever. I’m not entirely sure these differences are that significant but having to merge in all of the data/computed/watch etc options into a single setup() function would require quite a bit of refactoring.
I don’t see how changing the name helps over a version number.
This is changing the syntax for setting up components, somewhat similar to the class API difference, but it’s still fundamentally the same library. It’s largely just moving functions store on the root object into the setup() function while using a more function-y tree-shaking supporting style.
It’d probably cause as much confusion as it helps.
Because it's essentially a different project at that point. All stackoverflow answers become confusing instead of helpful for example.
Rust went through that around version 1 where a massive number of answers were updated to match new release and many got "this is not how it works anymore" comments.
Making it two separate project means the library authors have to write two separate libraries using two separate API - the more flexible and easier to maintain (written among others with library authors in mind) function API and the object API that they often have to fight against right now.
That would be a huge problem. Right now they can just use the API they want and it will work for all the users regardless if they use objects, functions or classes.
That was overplayed in my opinion by Python 3.2 or so a large percentage of Python 2 code could be made Python 3 code with the addition of: from __future__ import print_function at the top of the file (provided your libraries also went to 3 that is) most people didn't use any of the stuff that was removed.
> this would be a disaster similar to how Angular suddenly changed everything.
To be fair to Angular, if they'd stuck with what they had, it'd have faded into obscurity far more than the current version has. Angular.js was great for its time, but lost most of its advantages as the web caught up, and what used to be its advantages started to become kludges.
I don't know. I prototyped with Angular and it just seemed like one of those approaches that sorta made sense verbally but not at all on paper.
Like trying to take jQuery and make it a framework like React. But in their attempt to make it "simple" they made it useless. And then the next generation of frameworks like React came out and basically killed it.
Im still om angularjs. Cant bother to learn new frameworks every other month. Also using Angularjs in recent projects i never ever thought I was hobbled. Angularjs,jquery,vue - doesnt matter which tool one use. If you know any of these at advanced level you can create anything
Absolutely; I was a very satisfied user of Angular.js, and if you have a project in it currently, I'm sure it works just fine. But you're also missing out on a whole lot if you're restricted to their now-clumsy module system, their now-clumsy unit testing setup, their custom syntax with no editor support, its limited ability to work with type checking...
All those are fine not to have for an existing project, but they're what make people choose other frameworks (such as Angular 2+) for new projects. Angular.js wouldn't have been as big as regular Angular is today if they'd have kept focusing on that - let alone as big as React.
The initial release was 8 years ago. Surely, you've had at least an ounce of curiosity about how the front-end ecosystem has changed since then? Even if you didn't adopt it, just to maybe poke around and look at what React, Vue, et. al. are up to?
It's not be dismissive of what you currently do. But perhaps you might see new efficiencies that allow you to do more with less, with these newer solutions.
The problem with Angular 1 is that it was slow and bloated, relatively speaking. Google could have improved on that instead of starting from scratch, or ok, start from scratch but use a different name.
While I don't disagree about the fact it will likely cause a split similar to Angular, they seem quite explicit about the reasons (not to scratch the itch of the framework's designers).
For me, working in a large project with TypeScript vs one in vanilla JavaScript makes all the difference in terms of how maintainable it is. The number and the nature of the tests I need to write for such project changes, the IDE tooling available makes development much more pleasant, and I generally feel like it is harder to write code that is buggy, because a large amount of potential errors are avoided through use of the type system.
Whether or not they've made the right decision with this split is a different question that I can't answer.
My quip about scratching the designer’s itch is mostly about the following.
99% of people that got into Vue.js use it because it felt like an anti of the ever changing, dragon chasing JS world.
Changing the syntax will almost certainly yield zero benefits to the folks out in the field running apps for their businesses. They will end up with the same app, with the same functionality, just $100k lighter due to hours burnt on refactoring to the “function based” API.
Everyone roles their eyes and the bad wrap Javascript has continues.
> 99% of people that got into Vue.js use it because it felt like an anti of the ever changing, dragon chasing JS world.
Can't say I agree. Lots of people became aware of vue/seriously evaluated it around the time of the 1.0/2.0 breakage, myself included. Vue IME has caused more breakage than react has, though I would note that React best/common practices have evolved somewhat more radically; it's just that backwards compat has (mostly) been maintained.
I think a better/more common reason why people use it is that vue does a better job than react of forcing a separation of logic/styling/rendering, which react components have a tendency to intermix eventually.
If I remember correctly it wasn't just that angular broke stuff but also that they no longer supported older versions and the wanted to bump major versions multiple times a year. Breaks are one thing, promising constant instability is quite another.
A few months ago I had to decide between Vue and React/Redux for porting over a very large Angular 1.x app at work (I decided against Angular2+ - mostly because I feel pretty burned by Angular). Seeing this headline made me very glad that I picked React.
Edit: Because my comment will probably age poorly, the old headline used to be: "Vue 3 set to change in a big way – Current Syntax to be deprecated"
I think it cuts both ways. As a sole developer he can push Vue quickly into new directions. It has been part of Vue's success and will be the cause of its downfall.
Vue has a history of rough upgrades, version 1 to 2 wasn't fun.
I switched from React to Vue because I didn't like the direction they were going with hooks. Now it looks like Vue is heavily borrowing from the same approach. Slightly upset about that but I guess I'll have to learn the new style. Maybe it will be better in the long run.
Or just go with hooks.
Obviously there are quite a few pros and cons but for us the reduction in boilerplate led to a net increase in cognitive understandability of our code base so to say.
> Function-based APIs are exposed as named ES exports and imported on demand. This makes them tree-shakable, and leaves more room for future API additions. Code written with function-based APIs also compresses better than object-or-class-based code, since (with standard minification) function and variable names can be shortened while object/class methods and properties cannot.
I don’t yet have an opinion on the wider changes but this is great. Tree-shaking really helps bring down file sizes and I’m not in the camp of “it only loads once and caches” group that disregard file size these days. And not just because that’s no longer true with async component loading depending on the route/page.
I hope Vue.js gets some kind of automatic migration tool. Otherwise, I'm not sure how migration would be possible, given the amount of code certain projects have (sometimes without proper testing).
Vue already supports templates written in JSX/functional style. I very much doubt this goes away. Template syntax is not the topic of this RFC, and where it does touch rendering, it retains the option of render functions.
Why don't they just call it a new framework if its undergoing such a major overhaul. This only makes me feel better about picking react at my current company as now I view this framework as dangerous for building anything long lasting.
This is one of the things that made me dislike angular. If your are changing the entire API and syntax then it's a new framework. Don't steal the name of an existing framework just to steal the SEO. It's dishonest and makes it harder for users of both frameworks to search.
Welp, it's dead to me then. There's a lot of thought seems like it went into the redesign and he(they?) have my respect but I'll be damned if I spend more time learning another js framework, I've already gone through react, angular 1 -> ∞ and vue. This is tiring.
There is a theory which states that if ever anyone discovers exactly what a JavaScript framework is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.
Hopefully they recognise their niche and stick to it. I'm particularly interested in Svelte for compiling down to vanilla WebComponents to be used in P2P apps (eg Holochain) where you want the end users to be able to modify components themselves.
Sorry, but seems Rich is not too happy with WC', if you want to do use a compiler to vanilla WC's I think stenciljs might be your best option. LitElement is also good - but it is not a compiler. Svelte V3 doesn't even have custom element section documented at all at the time of the writing.
There is also, Custom element API section that is "TODO". Yes I saw those options the first time, but woulnd't you say the documentation is limited ;) if such is the case.
So far I see 2 sentences related to the subject, compare that to V2 docs.
I will try to see how svelte performs for this, but so far Vue wc-wrapper seems to be the most promising option out of "non-wc first" ecosystems.
Far, far less likely. Svelte has undergone some changes, and will continue to do so, but the latest round of change swung heavily in favor of USING THE LANGUAGE. Most of what you write in Svelte, with some notable exceptions, is vanilla JavaScript.
We in the Svelte world love it so much, it seems highly unlikely there will be any drastic switch from what we've all grown to love. (It's truly fantastic, give it a whirl: https://svelte.dev/repl/hello-world?version=3.5.3)
(Side note: I actually clicked on this link hoping Vue was learning a similar lesson, only to be disappointed.)
I've been meaning to start a project with Svelte 3, but I'm not sure what tools to use. Is Sapper ready for v3 or is it still mostly on v2?
I've also somewhat been hoping that Svelte 3 will get TypeScript support so I can have a typed interface between my Svelte frontend and my Rust backend...
It's amazing to me that after so many years of being the leading framework due to being the first to introduce a new paradigm (the virtual DOM), React is still "the framework to follow", i.e. again being the first to come up with an innovation (hooks) that spreads like wildfire. And even more amazing that they managed to do so in a backwards-compatible way.
(And also: with not that much pressure to adopt it. Having a "Standard" and a "Compatibility" build does result in that pressure.)
This. I've used React and to my surprise even liked it, but if you have to start all over every 3 years, you've got to ask whether pulling your model ... whatever over to the client is actually worth it in the vast majority of cases. What was wrong with SSR and a bit of jquery and Ajax again?
So if there's unrelated data on the page that one would want to preserve after getting more data, what are the options? Send it in as a "preservationObject" or something similar and it gets returned and re-interpolated on the new page render? LocalStore? Query Params?
I used to be a huge Vue proponent for about 3 years and stopped using it at the end of 2018.
I moved to Inferno + MobX because the cognitive overhead is practically nil. You can architecture your application and specially your state in any way you wish since your reactive data is made of objects, classes, or whatever you want to use.
MobX also makes your React/Inferno components much more enjoyable. No need to use setState() anymore since your component state is reactive much like Vue or Svelte do.
After using that for a while and coming back to an old Vue/Vuex project I realized how many conventions and ad-hoc abstractions it has which was quite oppressive.
A couple of weeks ago I discovered mobx-jsx[1] which is pretty interesting. It's a very thin rendering library that compiles JSX to imperative DOM instructions and relies on MobX for tracking state changes which makes the virtual dom irrelevant. It adds loops and conditionals which IMO are the biggest annoyances of using JSX. This is probably what I'll be moving on in future projects.
(Actually what converts JSX to DOM instructions is a babel plugin from the same author)
I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.
I just left frontend, and I’m the maintainer for express-vue. Vue is great in its current iteration. But the whole JS ecosystem is just horrible right now. Looking at these changes, it’s not for the better.
I can actually handle the churn and the random rewrites, a lot of them have been marked improvements, that doesn't bother me. What bothers me is when things change in ways that make them more complex than they were before, which also happens constantly.
Not only that but I'm sick and tired of tool developers pandering to noobs. Nobody should ever be learning to use a library like React before understanding the programming language they're working with. For the React team to come out and say something as stupid as 'classes are too hard', in the context of the sheer wall of accidental complexity around the front end space, is a joke.
All the problems with PHP back in the day are going to come back with a vengeance when our new generation of coders that don't understand basic language constructs all graduate to tool making.
I'm aware of that - hence the form of my previous comment.
"This time it's different" though.
The difference being: this here is radically less complex and unlikely to become much more.
All this complexity in frameworks was always added in a vicious cycle, namely:
1. Developer looks at a component - they see complexity.
2. They don't know how much of it is due to the business logic being complex and how much is introduced by the framework, which has to deal with the limitations of the platform, so they assume it's the latter.
3. To deal with this they create yet another abstraction and an associated convention, which makes one problem better and a good few others worse.
4. Other developers see the examples and figure that this new method indeed solves that one problem, so they adopt it.
5. The result is ever increasing complexity.
Enter Svelte(and similar technologies): it's not a framework, but a compiler - it doesn't have to play by the same rules, so it (eventually) avoids framework-related complexity.
It's noticeable in the way how Svelte 3 ditched setState() altogether and replaced it with simple variable assignment.
I don't think it's just because the devs get bored. It's because the users crack the shits if their specific use cases aren't handled, and when it comes to 'frameworks' nobody wants to switch or use anything that's not the most popular, so over time they just get more and more bloated trying to handle more use cases.
It's twice as bad if there's financial incentives for having a userbase (see all the tools not owned by FB/Google etc where the contributors sell training etc) because then it literally pays to add as much crap into your library as possible to try and get as many people using it as you can, regardless of the effect it has on quality. Even if something would make more sense as a fork or alternative, it's getting added in, whether it's good for the library and ecosystem or not.
If you don't hate front-end period now, mobile's a hell of a lot easier and I think it still pays better than front-end webdev for some reason. As long as you stay away from the web-tech-on-mobile crap and write actual native code. It's especially easier if you specialize in one of the Big Two, but even working on both isn't that bad. I mean, it's not JS "culture" bad.
iOS is far and away the saner of the two if you wanna pick just one, plus it's an easy gateway to the whole Apple family of devices (watch, TV) including, soon, macOS itself. Android's broadly less pleasant and any devices outside phones that happen to be running it are likely to be batshit insane to work on, but it's still way better than the web, and a ton better than it was back in the 4.x days (let alone the 2.x/3.x split days—oof, it was hot garbage back then)
I don't quite understand this. Since 2013 React has remained a JS framework and introduced 1 new concept(hooks). iOS programming on the other hand(since 2013) has introduced a new language(Swift) and a new paradigm (Swift UI) for writing interfaces. All to target around 25% of the mobile market.
Yeah. It's so annoying how developers open source so much of their work. It's as if they just throw things up on the internet and expect people to use it only if it solves their specific problems. What they fail to consider is how inconvenient it is for their fellow developers who are dazzled by everything that hits front page of HN.
252 comments
[ 2.5 ms ] story [ 249 ms ] threadIs everyone going to rewrite all React literature with hooks?
The developers and documentation even advises against rewriting old components with hooks unless you need to.
Technically yes, but what if someone only uses hooks and has never used classes?
And, viceversa, since there is now a lot of people moving to hooks and producing React literature for hooks what if you only have used classes?
So now, to be able to read all the React literature one has to understand both methodologies.
> The developers and documentation even advises against rewriting old components with hooks unless you need to.
It doesn't matter. A big chunk of the JS community is hype-based.
The point is that most of the React literature available today will become obsolete.
Beyond that, hooks are super simple and the complainers are just making a big deal out of nothing. They are just callback functions that you implement outside of a class instead of overloading arbitrary method identifiers like "componentDidUpdate".
You also don't have to use it.
React is losing sight of what made it great when it came out. Do one thing, do it well, and do it the simplest way possible.
I for one loathe using class components now and not being able to share logic compositionally via hooks when I work with them. I feel more productive and I feel like my components are smaller and more focused, and I don’t repeat myself as much. It’s been a net win for me, and I think it’s well worth having two supported APIs that do roughly the same thing.. because despite this, React is still a small and focused library API-wise.
I still get answers for Vuejs 1.0, with suggestions to use 'partials' for example, only to find out that there exists no such thing in Vue 2.0.
This would be very bad for developers if they still call it Vue with another version number.
Even if they call it VueThree, VueNext or similar then the problem can be easily mitigated I think.
Being able to find answers quickly is a big win for beginners.
Change isn’t a bad thing but nor is change for changes sake.
I can understand that the changes here might not be worth it to some, but to call them "for change's sake" is disingenuous and unfair to the Vue team, I think. The linked page clearly motivates the changes. Whether those motivations weigh strong enough for you is a different matter.
But yeah, for now it appears they'll maintain compatibility well enough.
Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.
This is not engineering, its marketing
Doing things in vanilla js just means I end up duplicating a lot of the framework code. Vue really was very simple and minimalist. Just pass it your object and it's reactive and very easy to get started. Fairly unobtrusive as well.
This will require one hell of a migration path to support and I imagine lots of people will be on that "Compatibility Build" for a long time. I'm very, very curious whether folks who have large-scale Vue apps have had a look at this proposal, and if they've had any input on it.
The primary change seems to just be merging most of the keys/options (data, computed, watchers, etc) of the module into various functions within setup() which itself may require from coding best-practice guidelines since setup() is going to get pretty big.
I’d love to see a largish component converted to be able to compare the two instead of the small examples with one or two functions within it.
Even the decorator thing was problematic. Remember that the core Vue library is supposed to work both with and without build tools, but in case of TypeScript it's not possible. There is a decorator proposal for JavaScript but it works differently than the TypeScript one so there would be a clash.
In the meanwhile we found out a new solution that not only solves these but also some other problems (composability).
I'm pretty sure this is all with the best intentions, but this would be a disaster similar to how Angular suddenly changed everything.
Not against change, but the API is fine. Just iterate and evolve it.
disclaimer: Big fan of Vue, early user and conference attender..
> “The proposed APIs are all new additions and can theoretically be introduced in a completely backwards compatible way.”
One thing they want to avoid is the whole Python 2 vs 3 distinction that went on forever. I’m not entirely sure these differences are that significant but having to merge in all of the data/computed/watch etc options into a single setup() function would require quite a bit of refactoring.
This is changing the syntax for setting up components, somewhat similar to the class API difference, but it’s still fundamentally the same library. It’s largely just moving functions store on the root object into the setup() function while using a more function-y tree-shaking supporting style.
It’d probably cause as much confusion as it helps.
Rust went through that around version 1 where a massive number of answers were updated to match new release and many got "this is not how it works anymore" comments.
That would be a huge problem. Right now they can just use the API they want and it will work for all the users regardless if they use objects, functions or classes.
That was overplayed in my opinion by Python 3.2 or so a large percentage of Python 2 code could be made Python 3 code with the addition of: from __future__ import print_function at the top of the file (provided your libraries also went to 3 that is) most people didn't use any of the stuff that was removed.
To be fair to Angular, if they'd stuck with what they had, it'd have faded into obscurity far more than the current version has. Angular.js was great for its time, but lost most of its advantages as the web caught up, and what used to be its advantages started to become kludges.
Like trying to take jQuery and make it a framework like React. But in their attempt to make it "simple" they made it useless. And then the next generation of frameworks like React came out and basically killed it.
All those are fine not to have for an existing project, but they're what make people choose other frameworks (such as Angular 2+) for new projects. Angular.js wouldn't have been as big as regular Angular is today if they'd have kept focusing on that - let alone as big as React.
It's not be dismissive of what you currently do. But perhaps you might see new efficiencies that allow you to do more with less, with these newer solutions.
logo win32 tk latex opengl mfc html wxwidgets awt swing fltk glut android ios tapestry play templates hugo static site generator vue.js scratch
I'm sure I've forgotten a few.
For me, working in a large project with TypeScript vs one in vanilla JavaScript makes all the difference in terms of how maintainable it is. The number and the nature of the tests I need to write for such project changes, the IDE tooling available makes development much more pleasant, and I generally feel like it is harder to write code that is buggy, because a large amount of potential errors are avoided through use of the type system.
Whether or not they've made the right decision with this split is a different question that I can't answer.
99% of people that got into Vue.js use it because it felt like an anti of the ever changing, dragon chasing JS world.
Changing the syntax will almost certainly yield zero benefits to the folks out in the field running apps for their businesses. They will end up with the same app, with the same functionality, just $100k lighter due to hours burnt on refactoring to the “function based” API.
Everyone roles their eyes and the bad wrap Javascript has continues.
Can't say I agree. Lots of people became aware of vue/seriously evaluated it around the time of the 1.0/2.0 breakage, myself included. Vue IME has caused more breakage than react has, though I would note that React best/common practices have evolved somewhat more radically; it's just that backwards compat has (mostly) been maintained.
I think a better/more common reason why people use it is that vue does a better job than react of forcing a separation of logic/styling/rendering, which react components have a tendency to intermix eventually.
What the hell.
jQuery did it right. They decided on a methodology and stick with it changing the internals and gradually adding features.
Edit: Because my comment will probably age poorly, the old headline used to be: "Vue 3 set to change in a big way – Current Syntax to be deprecated"
Anyway, when it comes to programming, I've found that a single person can often (not always) do a better job than committee rule.
I think it cuts both ways. As a sole developer he can push Vue quickly into new directions. It has been part of Vue's success and will be the cause of its downfall.
Vue has a history of rough upgrades, version 1 to 2 wasn't fun.
Edit: Might as well give it a completely new name.
I'd be really interested in your thoughts on this. What about hooks don't you like so much that it made you abandon React?
I don’t yet have an opinion on the wider changes but this is great. Tree-shaking really helps bring down file sizes and I’m not in the camp of “it only loads once and caches” group that disregard file size these days. And not just because that’s no longer true with async component loading depending on the route/page.
To give a timeframe, this is the first major rework of this web based UI in nearly a decade. I wish these JS libraries had longer support timelines.
I should have never left C.
Did you read the linked motivations?
I want a JS framework simple enough that even hobbyist devs can understand in an afternoon.
React syntax is an overly complicated mess; like reactivity forcing itself onto HTML.
Current Vue syntax is neat, simple and clear; like HTML with added reactivity.
Here are the docs from v2 https://v2.svelte.dev/guide#custom-elements
So far I see 2 sentences related to the subject, compare that to V2 docs.
I will try to see how svelte performs for this, but so far Vue wc-wrapper seems to be the most promising option out of "non-wc first" ecosystems.
We in the Svelte world love it so much, it seems highly unlikely there will be any drastic switch from what we've all grown to love. (It's truly fantastic, give it a whirl: https://svelte.dev/repl/hello-world?version=3.5.3)
(Side note: I actually clicked on this link hoping Vue was learning a similar lesson, only to be disappointed.)
I support all the choices you make, but there are those of us who have good reason to value useful complexity. <3
What now? Are you talking about JSX? If so, it's pretty straightforward (and optional).
I've been meaning to start a project with Svelte 3, but I'm not sure what tools to use. Is Sapper ready for v3 or is it still mostly on v2?
I've also somewhat been hoping that Svelte 3 will get TypeScript support so I can have a typed interface between my Svelte frontend and my Rust backend...
Svelte 3 was released 2 months ago, but TypeScript support is still in the works: https://github.com/sveltejs/svelte/issues/1639#issuecomment-...
(And also: with not that much pressure to adopt it. Having a "Standard" and a "Compatibility" build does result in that pressure.)
I moved to Inferno + MobX because the cognitive overhead is practically nil. You can architecture your application and specially your state in any way you wish since your reactive data is made of objects, classes, or whatever you want to use.
MobX also makes your React/Inferno components much more enjoyable. No need to use setState() anymore since your component state is reactive much like Vue or Svelte do.
After using that for a while and coming back to an old Vue/Vuex project I realized how many conventions and ad-hoc abstractions it has which was quite oppressive.
A couple of weeks ago I discovered mobx-jsx[1] which is pretty interesting. It's a very thin rendering library that compiles JSX to imperative DOM instructions and relies on MobX for tracking state changes which makes the virtual dom irrelevant. It adds loops and conditionals which IMO are the biggest annoyances of using JSX. This is probably what I'll be moving on in future projects.
(Actually what converts JSX to DOM instructions is a babel plugin from the same author)
[1] https://github.com/ryansolid/mobx-jsx
I can actually handle the churn and the random rewrites, a lot of them have been marked improvements, that doesn't bother me. What bothers me is when things change in ways that make them more complex than they were before, which also happens constantly.
Not only that but I'm sick and tired of tool developers pandering to noobs. Nobody should ever be learning to use a library like React before understanding the programming language they're working with. For the React team to come out and say something as stupid as 'classes are too hard', in the context of the sheer wall of accidental complexity around the front end space, is a joke.
All the problems with PHP back in the day are going to come back with a vengeance when our new generation of coders that don't understand basic language constructs all graduate to tool making.
Anyway do you have a minute to talk about our lord and saviour Rich Harris?
https://svelte.dev/
"This time it's different" though.
The difference being: this here is radically less complex and unlikely to become much more.
All this complexity in frameworks was always added in a vicious cycle, namely:
1. Developer looks at a component - they see complexity.
2. They don't know how much of it is due to the business logic being complex and how much is introduced by the framework, which has to deal with the limitations of the platform, so they assume it's the latter.
3. To deal with this they create yet another abstraction and an associated convention, which makes one problem better and a good few others worse.
4. Other developers see the examples and figure that this new method indeed solves that one problem, so they adopt it.
5. The result is ever increasing complexity.
Enter Svelte(and similar technologies): it's not a framework, but a compiler - it doesn't have to play by the same rules, so it (eventually) avoids framework-related complexity.
It's noticeable in the way how Svelte 3 ditched setState() altogether and replaced it with simple variable assignment.
Anyway Rich Harris' presentation is a good starting point:
https://youtu.be/AdNJ3fydeao
It's twice as bad if there's financial incentives for having a userbase (see all the tools not owned by FB/Google etc where the contributors sell training etc) because then it literally pays to add as much crap into your library as possible to try and get as many people using it as you can, regardless of the effect it has on quality. Even if something would make more sense as a fork or alternative, it's getting added in, whether it's good for the library and ecosystem or not.
iOS is far and away the saner of the two if you wanna pick just one, plus it's an easy gateway to the whole Apple family of devices (watch, TV) including, soon, macOS itself. Android's broadly less pleasant and any devices outside phones that happen to be running it are likely to be batshit insane to work on, but it's still way better than the web, and a ton better than it was back in the 4.x days (let alone the 2.x/3.x split days—oof, it was hot garbage back then)