8 ms·
Vue 3 Beta
- ehsankia 6y agoUseful link with more info about what's in Vue 3 https://madewithvuejs.com/blog/vue-3-roundup https://madewithvuejs.com/blog/vue-3-roundup
- ccktlmazeltov 6y agomods you know what to do
- dang 6y agoHow is this topic different from https://news.ycombinator.com/item?id=21391381 https://news.ycombinator.com/item?id=21391381?
- third_I 6y agoEaster egg for us: > “Build a Hacker News Client with the Vue 3 Function-based component API, Vuex and vue-hooks by Coding Garden with CJ on Youtube (video)” [1] No idea if that video is good but 146:0 liked it. Edit: comment mentions that “Building of Hacker News Client starts at 33:18” [1]: https://youtu.be/g9bSmxnx-O0?t=318 https://youtu.be/g9bSmxnx-O0?t=318 (starts at 5:18)
- mikece 6y agoHow significant is the adoption of TypeScript? Angular was built with it; React now recommends it too. Is this really the ratification of TypeScript as THE front-end language?
- jfkebwjsbx 6y agoI think TypeScript already won around a year ago.
- runawaybottle 6y agoPlease be careful with anointing winners, that stops people from exploring and evaluating all the options, and encourages force feeding whatever is “in” into their projects.
- hombre_fatal 6y agoWell, it's pretty clear in this case. Typescript has even more traction and better integration (like VSCode's magical definition fetching) than I think anyone could have imagined. It dominated its reasonable competitor, Flow. It's kind of a freak win. I think we can say confidently that nothing is going to usurp it. Not like any compile-to-JS language has come close even when JS was at its worse. Now JS is so good I don't even know why I'd use another dynamically typed language. We rarely get blindsided by what actually gets traction because almost nothing does. Something that looks like Typescript isn't going to beat Typescript. Something that's more foreign looking certainly isn't either.
- JMTQp8lwXL 6y agoWhat other options are there? All I can think of is Flow.
- toastal 6y agoI mean there's the typed functional set, PureScript, Elm, BuckleScript, Reason, etc., that compete with TypeScript on type systems why compiling to JS while offering better ergonomics for FP-style code.
- JMTQp8lwXL 6y agoThey could be serious contenders only if they coexist gracefully with the rest of the JavaScript ecosystem: e.g., here's this new awesome type system, but oh... You can't use React + Redux + Material UI with it, it's might be D.O.A to a certain segment of engineers since it has no real practical application for solving today's front end engineering problems with them.
- james-mcelwain 6y agoIt's important to remember that there are still a lot of front-end folks who aren't interested in application engineering, but still might find these frameworks useful. For those kinds of people, static typing is a harder sell. For anyone else, yeah, they should probably be using TypeScript in 2020.
- deleted 6y ago[deleted]
- ct520 6y agoI adopted typescript shortly after it’s release and went through growing pains in the first couple years. I don’t use it often now. And it ALWAYS comes back to bite me in the butt when doing any decent sized project. If I had to guess time spent fixing things that would have been caught out weights the cons of using typescript
- tnorthcutt 6y agoForgive me, but I’m having trouble parsing this. Are you saying you recommend using Typescript, or not? If yes, why do you not use it often now?
- sk0g 6y agoSounds like they think time spent fighting the language outweighs any pros TS might have, and thus aren't recommending it. Edit: read it wrong, nevermind.
- deleted 6y ago[deleted]
- CreepGin 6y agoNo, he's saying the opposite (as in TS scales better with project size). > time spent fixing things that would have been caught [by Typescript] out weights the cons of using typescript
- irrational 6y agoProbably not. The numbers I’ve seen suggest that far less than 5% (I think it was 2%) of websites use a library like react, Vue, or angular. Of course, you can use Typescript on its own, but if you are using Typescript, chances are you are also using one of the big 3.
- Bahamut 6y agoAren't an absurd number of websites made with WordPress still?
- thanksforfish 6y agoIt's popular. 26%, 33%, or 36% are some estimates. 1. https://managewp.com/blog/statistics-about-wordpress-usage https://managewp.com/blog/statistics-about-wordpress-usage 2. https://trends.builtwith.com/cms/WordPress https://trends.builtwith.com/cms/WordPress 3. https://w3techs.com/technologies/details/cm-wordpress https://w3techs.com/technologies/details/cm-wordpress
- waheoo 6y agoWordPress uses React for its new editor, Gutenberg. Blocks are essentially react components with a bunch of wordpress apis hooked in / around it.
- tmpz22 6y agoThe tooling for Typescript still isn't good enough to claim that accolade. There are still combinations of libraries, linters, editors, and frameworks, that throw opaque errors that will roadblock students and junior developers significantly. Ultimately until browsers can accept Typescript directly without a compilation step it will remain a second-class citizen. Until then, all of Webpack, gulp, parcelJS, problems and inefficiencies are Typescript's problems and inefficiencies. It's not fair - Microsoft and co. have done a tremendous job with the implementation and documentation of Typescript. But the reality exists nonetheless.
- jdxcode 6y agoYou're right the tooling could be better and that TS trips up beginners. Promises trip up beginners as well though but that doesn't mean they're not standard. TS is very, very close to being standard practice. It's already being used by over 50% of JS developers [0]. It doesn't have to be beginner/tooling friendly to be widespread. [0]: https://2019.stateofjs.com/javascript-flavors/typescript/ https://2019.stateofjs.com/javascript-flavors/typescript/
- waheoo 6y agoThis isnt a democracy. 50% isnt the bar for a standard. Thats like saying only 50% browsers can render html so its standard.
- jdxcode 6y agoI never said it was standard. I said it's very, very close. 50% (actually 58.5% of just those that would use it again) is certainly within the realm of critical mass.
- DanRosenwasser 6y agoAny specific examples where you feel the surrounding tooling is falling short?
- 6y ago
- acemarke 6y agoReact itself is written in Flow, but the React team doesn't make any official recommendations as for language or static type syntax to use. That said, a recent survey of /r/reactjs readers [0] showed 50% using plain JS, 48% TS, and only 2% using Flow . Given that the React ecosystem probably has the most Flow users, I'd say it's safe to describe Flow as dead. From my viewpoint, TS has more than hit enough critical mass to survive for the long term: - Microsoft is heavily invested in its ongoing development - The Angular community requires use of TS - Per that stat, it's reached solid adoption in the React community (see guides like the React+TS Cheatsheet [1]) - Where CoffeeScript introduced new syntax entirely, TS's focus on being a superset of standardized JS means that there's both less to worry about compat-wise _and_ it can be seen as a way to use new language features instead of Babel. So, seems like it's going to be around for a while. I wrote up my thoughts last year on my own experience learning and using TS from both an app dev and library maintainer's perspective [2]. [0] https://www.swyx.io/writing/react-survey-2019/ https://www.swyx.io/writing/react-survey-2019/ [1] https://github.com/typescript-cheatsheets/react-typescript-cheatsheet https://github.com/typescript-cheatsheets/react-typescript-c... [2] https://blog.isquaredsoftware.com/2019/11/blogged-answers-learning-and-using-typescript/ https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...
- girvo 6y agoWhich makes me sad: I've built two production systems in Flow, and I found it absolutely delightful, with the caveat that I specifically chose all third party libraries that supported Flow as well. It's type system (and `import type` instead of Typescript's overloading of `import`) was ridiculously powerful, and back then significantly more-so than Typescript. That's no longer the case, of course, Typescript has smartly stolen most of the advantages Flow had, and it has so much more support from the outside world that it'd be silly to use Flow today. On top of that, I think a lot of the momentum of a powerful type system for front-end development has moved (in the React world) towards Reason anyway. Between Typescript and Reason, we're spoiled for choice in building robust front-ends that stomp bugs early and often!
- beart 6y agoTypescript is introducing 'import type', not sure if it works the same way as flow as I've never used that.
- datasage 6y agoFor those interested in static tying for SPA's and Web applications it seems to have won. That doesn't mean everyone needs to use it.
- DanRosenwasser 6y agoI think it's worth clarifying that Vue 3.0 won't require you to use TypeScript. I think the way to think about this is that tooling will ideally improve for a lot of JS devs regardless of whether they decide to use types or not.
- sergiotapia 6y agoI don't get the hype. We wasted a lot of time fighting the compiler and warnings and errors, and then falling back to `any` and by then, why not just use Javascript the way God Himself intended.
- friedman23 6y agoJust wait until you need to do a significant refactor
- sergiotapia 6y agoRefactor? Is that a new microframework?
- pedrocx486 6y agoBecause even "God Himself"* regrets some of his choices in JS. *Depending on who you define as God, the creator of JS?
- deleted 6y ago[deleted]
- csytan 6y agoFor folks interested in the new Composition API, the RFC is a good read: https://vue-composition-api-rfc.netlify.app/ https://vue-composition-api-rfc.netlify.app/
- keithnz 6y agoI'd also suggest https://www.youtube.com/watch?v=V-xK3sbc7xI&t=2319s https://www.youtube.com/watch?v=V-xK3sbc7xI&t=2319s
- montroser 6y agoThe new Composition API definitely looks interesting. But it's also kind of a shame that there are now two very different ways to write the same functionality, both blessed by the framework.
- RobertRoberts 6y agoI don't think so. This is the nature of software. The first version jumped right in and solved an immediate problem. Even with the best foresight possible the designers simply could not see all the problems they would run into. Or even if they did, sometimes pragmatism forced fixing issues down the road. After doing this for over 20 years (I build software coders/designers/laymen use) I am really impressed with how well Vue was designed to start with, and the migration path (at a glance) looks nearly painless from v2 to v3.
- neovive 6y agoI think the original plan was to eventually phase out the Options API, but the community pushed back during the first RFC phase resulting in the dual API solution. Although the benefits of the Composition API are clear-cut, the Options API is beloved by the community for its ease of use and clarity. For me personally, it will be hard to switch since I'm not a heavy user of mixins and I don't venture too far beyond simple components. However, I still need to learn the Composition API in more detail so I can make a more informed decision. Evan and the Vue team worked very hard on v3 and I trust them to make the right decisions.
- keithnz 6y agoI liked the options API... what I found is the composition API is actually nicer to deal with not even considering mixins. Because things are grouped together you don't end up moving around your files so much so it ends up being quicker.
- mmis1000 6y agoIt actually not very different in its core(except the transition to Proxy). In fact, you can already do that on vue 2, just you are unlikely to. Put method in data or prop? It actually works, but why would you do that when there is a field called `methods`? The setup method seems like a slightly enhanced data() that allow you to place things in a more free way.
- bratao 6y agoI´m interested in benchmarks, but could not find any. During the development they promised some serious optimizations.
- leeoniya 6y agoyes, it should be a lot faster: https://github.com/krausest/js-framework-benchmark/pull/697 https://github.com/krausest/js-framework-benchmark/pull/697
- pier25 6y agoYou can see the results here: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht... Yeah it's significantly faster and smaller than Vue 2.
- buremba 6y agoI really wish that they make the transition from 2.0 as seamless as possible.
- habosa 6y agoThe link is to a GitHub release page with no release notes. Can someone point me to an authoritative 3 vs 2 comparison?
- aembleton 6y agohttps://madewithvuejs.com/blog/vue-3-roundup https://madewithvuejs.com/blog/vue-3-roundup
- natch 6y agoThis repo needs a readme that says what Vue is.
- thrwn_frthr_awy 6y agoFor someone with little experience with the modern front-end development, what are the reasons to choose Vue over React or vice-versa? Are they both just different flavors of the same patterns or is there a philosophical difference in the two?
- alharith 6y agoI've worked extensively in both. In my opinion: Vue embraces web technologies. JS is to enhance your HTML. React is a javascript-first, FP-first mentality. Minor point: vue benchmarks slightly faster these days. The react runtime has gotten pretty thick.
- eberkund 6y agoSuperficially the first thing that most developers I've spoken to notice is JSX vs HTML-based templating. But both frameworks are very similar. I started with Vue and when I took a job which used React I found that I already knew how things worked. Beyond that, I would say the biggest difference between the two is that Vue is the scope of the framework. Vue includes much more in the framework itself and as first-party helper libraries whereas React relies heavily on third-party packages of which there often many competing options and which one is used varies from company to company and project to project.
- lobo_tuerto 6y agoI think it's just easier to ramp up in Vue.js than in React. The Single File Component approach is easy to grasp for beginners since it just looks like an HTML file with three main tags: template, script, style. You might find useful information here: https://phabricator.wikimedia.org/T241180 https://phabricator.wikimedia.org/T241180 (The Wikimedia Foundation describes why they went with Vue.js instead of React or other competing libraries)
- jdxcode 6y agoIMO it's a huge difference in learning curve too. In Vue I was up and running in a day or two but React took me weeks to really feel like I knew what I was doing—and I learned React after I learned Vue. Single File Component tells you where you need to put things. You don't need to figure it out yourself and build up your own organization and patterns on top of Vue. You just start building the application. It's not a completely apt comparison: but Vue shares more in common with Rails than with Node development—at least in terms of grokking. My understanding is their performance is virtually the same. Some applications perform better on one vs the other.
- kohtatsu 6y agoRecently did some framework shipping and wanted to plug Svelte despite not having deployed it yet. The approach of using a compiler instead of a framework makes a lot of sense and I personally believe it's the best way forward. I recommend watching the talk here; https://svelte.dev/blog/svelte-3-rethinking-reactivity https://svelte.dev/blog/svelte-3-rethinking-reactivity
- thinkloop 6y ago> The approach of using a compiler instead of a framework makes a lot of sense I agree, I wish it wasn't an entire framework though and more of a front-end library like react. I've learnt long ago not to invest too much into a single tool.
- buzzerbetrayed 6y agoI feel like you just agreed with him and disagreed with him. How can a compiler be a front end library? Svelte can target web components, which allows you to use it in just a portion of a web page, just like react.
- thinkloop 6y agoI should've said "rendering engine" rather than "front-end library", to still be able to use things like redux, css processors, etc. But your comment made me realize that may not actually make sense. I'm still generally hesitant when a single framework takes over the entire chain.
- noway421 6y agoApparently scheduling/skipping renders is hard with this approach, since render function gets compiled away and becomes hardcoded DOM calls in the result bundle. React with Suspense takes a different approach here and allows to suspend renders, skip slow renders (I think) till they're ready, prioritise keyboard input, etc. It's essentially a similar tradeoff as in AOT vs JIT. Even though AOT brings the compilation step forward, JIT would have much more runtime context for better performance.
- Townley 6y agoAnyone have details on what it means that Vur 3 can “more easily target native?” Is there something about Vue that’s been keeping Vue-powered Nativescript, Ionic, or Quazar from having feature parity with React Native?
- spartanatreyu 6y agoI have a feeling it's about the renderer being compartmentalised and the potential for a native renderer to be used with vue 3 instead.
- dang 6y agoThere was a big thread a few months ago about these features: https://news.ycombinator.com/item?id=21391381 https://news.ycombinator.com/item?id=21391381. Is there significant new information [1] since then? If not, this is substantially the same story and we should wait for the actual release [2], since there will certainly be another big thread then. [1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=by%3Adang%20%22significant%20new%20information%22&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... [2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20incremental&sort=byDate&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
- deleted 6y ago[deleted]
- IgorPartola 6y agoIs the Composition API going to be the only way to do things in some future version of Vue? I see why you’d want the elegance of it but also it seems to trade having to know which properties this has for having to strictly order property and method declarations. It’s like we went from declarative to procedural components and I am not sure I like it.