[HN Gopher] Vue.js 3
___________________________________________________________________
Vue.js 3
Author : simulo
Score : 534 points
Date : 2020-09-18 15:50 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nikkwong wrote:
| The announcement talk was nice to watch, however, it was
| technically void of any of the implementation details.
|
| It's interesting to me that they did not consider the approach of
| pushing more work to the compiler and less to the runtime in the
| manner popularized by Svelte. I wonder what the trade-off between
| their current rendering approach and the Svelte-based approach
| are?
| filipsch wrote:
| I was surprised to see an update to a contemporary JavaScript
| framework to be welcomed rather than boo'd by the average HN
| reader. That in itself is an accomplishment.
| swyx wrote:
| the appetite for a credible alternative to a Facebook project
| is _strong_. also the vue team has done a great job dripping
| out information over the past 2 years and building
| anticipation. very little surprises in this release, hence
| mostly celebration left. you need to go back a bit further in
| time to find the critical HN comments.
| superasn wrote:
| One thing I'm really excited about with this version is Vite (the
| snowpack type version of Vue that doesn't require webpack). It
| should make development so much easier.
| Exuma wrote:
| I just started vue 3 and its incredible compared to my experience
| with react. Way to go Vue team!!!
| azangru wrote:
| > and its incredible compared to my experience with react
|
| Could you expand on this a little more? What is it specifically
| that makes it incredible compared to React, in your opinion?
| Exuma wrote:
| I like that vue manages dependencies so you dont worry about
| pure components anymore, but I believe that was fixed
| recently in react? The biggest thing is I despise writing
| JSX. To me it just feels absolutely miserable. The upside is
| that you have incredible fine grained control over the
| dynamic rendering of components, but so far even in my
| complex app there's been no need to write a render function
| yet (similar equivalent in vue to get that same level of
| control as react).
|
| Also, I really like the data binding which vue took from
| angular. That was always by far my favorite part of angular,
| rather than having the binding be written in JS which feels
| too mechanic to me. I dont feel like I'm writing HTML / front
| end code, I feel like I'm writing a hybrid mecha mutant of JS
| + HTML + weird syntax.
| duhi88 wrote:
| For me and my team, it hits the right balance between
| Angular's structure and React's no-structure. We can use it
| for small apps within a server-rendered website, or larger
| SPAs.
|
| I can hand a project to a junior dev and not have to explain
| project structure or patterns, nor worry about things going
| off the rails. Generally, after getting a feature working,
| most of the feedback I'll need to give is "break this 300
| line file up into 3-4 smaller ones". Great ESLint rules
| provided by the Vue team really help with this.
|
| With Vue 3, with the two APIs, I know that I'll be able to
| hand a feature off to a developer of any level and know they
| can accomplish it however it makes the most sense.
|
| I can also jump into a legacy Vue app built by another team
| and have no issues getting oriented. In my experience with
| React, I haven't seen the same router configuration twice.
| Most React projects I've inherited feel over engineered
|
| On a more meta level, I think the single-file API its a much
| better mental model than React's. Your HTML is still just
| HTML, and your styles are CSS or Sass, or whatever you
| choose.It's why I preferred AngularJS over the others at the
| time.
| jiofih wrote:
| > allows end users to shave off up to half of the runtime size
| via tree-shaking
|
| Doesn't webpack support _actual_ tree-shaking (not just modules)
| or is that still a Rollup-only feature? There should be little
| difference in size in importing packages vs files if tree-shaking
| is on.
| wishinghand wrote:
| It will on or after October 10th, which is when the next
| version of Webpack is slated to release.
| httgp wrote:
| Wait they've announced a date? The Webpack 5 project board on
| GitHub still has a bunch of items not done yet.
| j-krieger wrote:
| Webpack doesn't support actual, statically checked tree shaking
| for now. There is a parameter called ''sideEffects'' you can
| employ in your package.json, which if switched to off gives
| hints to the compiler that your code is side-effect free and
| can thus be eliminated if not used.
| TekMol wrote:
| I still don't see a reason why one would use Vue or React.
|
| I agree that templating of data is something you should use a
| library for. But there are great templating libraries. Handlebars
| for example.
|
| Can someone give a short example of code that would be more
| elegant using Vue then just a simple template engine?
| [deleted]
| mmcnl wrote:
| Vue and React are more than templating engines. They decouple
| the state and view of your application. This means your view
| becomes a function of state, and you only need to worry about
| state. This solves the problem of trying to keep your view in
| sync with the application state, which probably everyone who
| has done some webdev for more than 5 years still has nightmares
| about.
| serial_dev wrote:
| Which template engine? Then what if you realize you need a
| router? Then the developer who glued those together leaves, and
| all you can hire is juniors.
|
| There are benefits to using the industry standard (which today
| I consider Vue, React, Angular and slowly Svelte), you can
| learn it quickly, as it has ton of resources and you can hire
| easily, as you aren't forcing someone to use some obscure, home
| baked js framework.
|
| That's my take at least.
| azangru wrote:
| > all you can hire is juniors
|
| Then you are in trouble regardless of what you use :-)
| cjohnson318 wrote:
| One example is building an application like minesweeper. Would
| you really want to tackle that with jQuery and templating
| engine? I'd rather break everything into components, have them
| talk to each other through a state manger like vuex or redux,
| and only phone home to my API for important things, like the
| final game score.
| TekMol wrote:
| I would neither need jQuery nor a templating engine to write
| Minesweeper.
| j-krieger wrote:
| It's great you applied your vanilla JS skills to his
| totally metaphorical example.
|
| I still don't get why it's okay for every other programming
| language to use the STL or huge dependencies, but doing so
| with javascript is frowned upon for some people. You
| wouldn't write a JSON parser yourself in CPP, you'd install
| something from conan or use the STL or boost for that. Why
| is it so bad to do the same with js?
| TekMol wrote:
| The browser _does_ supply a huge number of APIs.
|
| To set one of the Minesweeper tiles to bomb, you could
| do:
|
| tiles[x][y].className='bomb';
|
| And you are done. The rendering will nicely take place
| according to what you defined in the CSS.
| Exuma wrote:
| What are you talking about? You're just talking about
| simple class manipulation which has nothing to do with
| actual reactivity, especially 2-way data binding.
|
| How would you support that with your "templating engines"
| you keep mentioning, which to me doesn't mean anything at
| all, in my understanding of what a templating engine is
| like handlebars.
| TekMol wrote:
| As I said, I would not use a template engine to write
| Minesweeper.
| ric2b wrote:
| So when I click a tile you have some code on the onclick
| handler to go update the counter at the top? Sounds messy
| if there are multiple things you need to update when some
| data changes.
| mixmastamyk wrote:
| Not the end of the world, but the client will have to
| download it.
| Exuma wrote:
| It's almost a necessity for complicated apps. Right now I'm
| building an app which involves a reporting screen with all the
| following features on a single page:
|
| - 10+ breakdowns for report - 10+ filters for report - Each
| filter has an include/exclude dropdown list which then has
| multiple features within even a single filter (so some filters
| are EQUALS/NOT EQUALS) others are INCLUDES/DOESNT
| INCLUDE/EMPTY/NOT EMPTY and all the appropriate options for
| each filter, not to mention clearing filters, etc - column
| sorting - column hiding - filtering with search - pagination on
| both client and server side (50K rows batching into sub
| pagination groups which client side takes over on server
| batches) - a dropdown at the top which re-initializes EVERY
| piece of data with a different account and changes quite
| literally re-initializes 50+ "states" of the UI on the page
|
| Thinks of google analytics
|
| First of all, we can assume doing this on the front end is 100%
| required. Imagine using google analytics where every single
| option you change is a backend request. Impossible, so now that
| weve gotten past that...
|
| Imagine using something like jquery or custom JS where you try
| to manage the incredibly complicated input/output nature of
| each component of the page.
|
| Component based design is required because you can keep all
| your logic for the entire app for a single TINY piece of the
| app in its own file. So something like a dropdown menu can get
| its own component called `<DropdownMenu>`, and within that you
| define all "outer state" that component can use as a prop, or
| input state (so for example, you want the items that appear in
| the list to be defined OUTSIDE the component so the component
| can be re-used). However, that component also has its own
| internal state, such as whether its open or not, whether its
| animating or not, what item is selected etc, so if a component
| has internal state, then you store it IN the component itself.
| So now the 'state' of EVERY component on the page is defined in
| 2 places... the originator of the state (such as the component
| which holds your API calls), or in the component itself. When
| any change takes place in ANY of those states, all components
| related to that state "update" automatically to use that new
| state. This means by simply making a new API call, the outer
| component state changes, and every single component that relies
| on that state updates accordingly, even for the most complex UI
| imaginable its trivial to think about 95% of the logic because
| all the state is exactly where you expect it to be, and when
| there are infinite numbers of nuanced side effects, you usually
| program them IN the component and you dont have to clutter your
| actual logic (say for instance the api updates your base state,
| you want the dropdown to reset to zero, so you would code this
| into the component itself, so that everywhere on the page that
| uses this component it would all follow suit).
| TekMol wrote:
| Nothing you describe is easier solved with Vue then with a
| templating engine.
|
| You can have a "DropdownMenu" template, feed it the data
| (which you call "state") and update the according element on
| screen just fine.
| Exuma wrote:
| What do you mean by 'templating engine'. Give me a specific
| example. Templating engines to me are like handlebars... do
| you have a sample code example?
| TekMol wrote:
| Say a function changes the cars array. All it has to do
| to update the DOM is:
|
| document.querySelector('#carsDropdown').innerHTML=droppy(
| cars);
|
| Where droppy is a HandleBars template that on page load
| has been initialized with the html that makes your fancy
| dropdown menu.
| Exuma wrote:
| Yes, you are definitely missing the point of component
| based frameworks. That strategy is not even remotely
| scalable when you have nested complex state chains that
| vary slightly across multiple implementations of the same
| component, as well as 2-way communication with the
| original source of the state (from form inputs, and other
| parts of the UI).
|
| Each UI action in google analytics affects some other
| part of the UI. If you change a filter in one area, it
| might disable sorting in another, and simultaneously
| change the calendar to be only < 1 year. It might also
| disable some setting portion of the UI, reset the chart,
| change the input option on the chart axis, and then show
| a text input you can type in, and when you type in it,
| ALL THE previously mentioned states now react to the
| input box that appears.
|
| You want the logic for those components to be IN THE
| COMPONENT. With your strategy youre putting all NON
| business logic and trying to account for "every possible
| scenario" which is the exact purpose of what reactivity
| does. You're not writing 1000 extra lines of code to
| account for every single possible combination (which can
| be hundreds in complex apps). Instead you quite literally
| write 0 lines of code, because the reactivity is handled
| (both ways)
| pier25 wrote:
| Sure, you can use HBS (or even vanilla) to render a piece of
| dynamic HTML. That's not really the problem these libraries are
| solving.
|
| You could also create your own components with HBS templates
| and figure out how compose them to render a tree of components.
| That's not too hard to figure out either.
|
| The problem is really in updating the DOM when state changes
| somewhere in your application. In the jQuery days we had tons
| of micro DOM managing code so that when some variable changed
| then we would update some piece of the DOM by "hand". But as
| your project grows this becomes a mess pretty quickly.
|
| Another solution could be to simply re-render everything and
| update all the DOM on every frame with a state change. That
| would simplify your code but it would probably be extremely
| inefficient.
|
| The point of libraries like Vue, React, Svelte, etc, is about
| simplifying the production of sophisticated UIs, as efficiently
| as possible, so you can focus on the right abstraction instead
| of the implementation details (eg: managing the DOM).
|
| Every library takes a very different approach. If you're coming
| from the vanilla/jQuery world the learning curve can be pretty
| steep. But, as someone who has been doing web frontend for 20
| years, I think the price of admission is worth it.
|
| IMO Vue is probably the easiest one to get into. You can get
| started by simply including it in a script tag as if you were
| using jQuery.
| TekMol wrote:
| You say updating the DOM becomes messy but give no arguments
| why that would be the case.
|
| Say a function changes the cars array. All it has to do to
| update the DOM is:
|
| document.querySelector('#cars').innerHTML=carsTemplate(cars);
|
| Where carsTemplate is a HandleBars template that on page load
| has been initialized with the html to render the list of
| cars.
| orthecreedence wrote:
| Ok, now show the cars list in three places, and one of them
| is a subset of only BLUE cars.
|
| Now you have to update the DOM 3x and remember that the
| filter you set in that one place over there means you need
| to only show BLUE cars in this one place over here.
|
| When you start to build things where one piece of data is
| not just shown in multiple places, but is dependent on
| _other_ pieces of data, managing your state starts to
| become more difficult than the methodology you 're
| describing.
| exogen wrote:
| Now let's say your data (cars) changes. Due to some
| interaction, a car gets added to the list.
|
| What the above code will do is completely replace the HTML
| for the entire list of cars, when really all that needs to
| happen is appending one to the end. If the list is big,
| your app is now slow.
|
| If the user has something focused or edited in that list of
| cars (let's say they're editing the description of one),
| not only is focus lost on that field now (its DOM node was
| completely wiped out and replaced), but the user's text
| they were editing is also lost.
| pier25 wrote:
| Honestly, if manually replacing pieces of DOM works for
| you, then by all means, keep doing that. I have no horse in
| the race.
|
| In my experience, the approach you're describing doesn't
| really scale and only works for the most simplistic use
| cases. In a real world scenario you would have dozens if
| not hundreds or thousands of arrays/vars that are related
| to the view.
|
| Even only considering we're talking about rendering blocks
| of dynamic HTML: How are you going to keep track which
| state changes affect which parts of the DOM? Are you going
| to have hundreds/thousands of innerHTML code all over the
| place? What is going to happen when (not if) you change
| your template?
|
| Then you need to start considering, event handlers,
| initialization code for every car view, etc. Imagine those
| event handlers modify the state of a single car in your
| array. Are you going to repaint and re-initialize the
| events of all your cars on every mouse event? Again, that
| would probably work on very simplistic use cases.
|
| I'm not describing anything new. These problems are what
| motivated people to create Ember, Backbone, Angular 1 and
| other frameworks some 10 years ago. But the JS world has
| moved on from that paradigm into the reactivity+components
| thing which is a much better abstraction in terms of
| developer experience, performance, memory consumption, etc
| [1].
|
| [1] https://medium.com/dailyjs/a-realworld-comparison-of-
| front-e...
| cercatrova wrote:
| That's an imperative approach, rather than a declarative
| one. You can't track where the state is being changed if
| #cars is being changed in many places. Templates are fine
| for smaller apps but in larger apps it's more difficult,
| and there'll be more spaghetti code and bugs due to that.
| amitp wrote:
| I use this approach too but it fails whenever there's any
| state in the elements. An example is input elements:
| function update() { let value =
| document.querySelector("input")?.valueAsNumber;
| document.querySelector("main").innerHTML = ` Enter
| a price: <input type="number" oninput="update()">
| <br> Discounted price is ${value * 0.8} `;
| } update();
|
| What will happen is each time you enter a character, it
| will create a _new_ input element, which loses the focus
| and cursor position.
|
| To solve this we can split it up so that the inputs are
| created once and the output is updated with innerHTML. No
| problem, right? But it's hard to scale up because now you
| have to split the html up into small segments based on
| whether there's internal state or not. If you want to
| update the 'max' of an input type=range, you aren't doing
| it with handlebars anymore but you have to use setAttribute
| instead.
|
| What react, vue, etc. do for you is handle the _updates_ in
| a way that reuses the existing elements. If you changed any
| attributes of the <input type=number>, it will not lose
| the focus and cursor and any other state. If you change the
| max of an <input type=range>, it will update the existing
| element (using setAttribute) without losing any other
| state. If you change some text, it will update the existing
| text node using innerText/textContent.
|
| You may not need this type of system. I think React, Vue,
| etc. are overused. But in some projects it's much cleaner
| to use a React/Vue/etc. style system rather than splitting
| it up where some segments use setAttribute, some use
| innerHtml, etc.
| mattwad wrote:
| If you use Typescript, it means type-safe templates. That's a
| game-changer right there.
| mmczaplinski wrote:
| A short example, no, because if all you need is a simple
| website, then you don't need Vue either :)
|
| If you're building complex user interfaces or a large-scale web
| app, then hell yeah, you want to use React or Vue.
| j-krieger wrote:
| You _can_ use vue, because for most web-applications with
| vue3 you will only add an additional 15kb to it. I 'd wager
| kilobyte counts that low are worth it when you consider how
| much easier it is to add on additional functionality when you
| need it. A well-built build system can do so much
| automatically for you, including but not limited to
| automatically minifying your code, cleaning up dead code,
| html and styles or compressing your images in the build step.
|
| For reference: I recently built a really large scale website
| with react, including a content-management-system, custom
| fonts, around 50 pictures and a ton of tracking. It weighs
| 1,1MB _total_. The first request without lazy-loaded
| resources only uses around 200KB. Can 't really argue against
| that.
| j-krieger wrote:
| Any code involving a mid- to large sized web application that
| needs _reactivity_. Templating engines like handlebars are used
| on the server side, react and vue belong on the frontend (most
| of the time, but not exclusively). That 's the reason people
| use them: If you want to, you can have your logic executed on
| the client-side only, and host whatever else you need on a
| cloud-provider. Client-Side computing doesn't scale particulary
| well when your userbase grows fast enough.
| TekMol wrote:
| Handlebars works nicely clientside.
| mariushn wrote:
| Why is IE11 support still important now? I can't find exact stats
| on it, but it seems <2%. Surely projects which still want to
| support IE11 could still stick for a while with Vue2.
| reaperducer wrote:
| IE11 is still heavily used in some industries, such as
| healthcare. Browser statistics services usually don't pick up
| on a lot of IE11 use because it's on internal networks.
|
| I wish I could ignore IE11, but the reality is that I can't.
| ramses0 wrote:
| IE11 is also frequently represented as `mshtml.dll` in
| windows programs that embed a browser (eg:
| https://en.wikipedia.org/wiki/Trident_(software)#Use_cases )
| valueprop wrote:
| Thanks for sharing
| duhi88 wrote:
| I was surprised that became a feature of Vue 3, as well. I was
| hoping they would drop it, assuming you could just use Babel +
| Polyfills to get it to work if you really needed it.
| bewareandaware wrote:
| I don't really understand the composition API. Doesn't passing
| values by reference which can be modified anywhere downward the
| tree make your app difficult to reason and debug it?
| gavinray wrote:
| I have a fairly large/complex SaaS platform built with Vue 3
| composition API. Can maybe shed some light.
|
| A while ago I wrote the same component in Vue 2 and Vue 3 as an
| example of one versus the other:
|
| https://codesandbox.io/s/bold-shamir-uqm0b?file=/src/compone...
|
| https://codesandbox.io/s/bold-shamir-uqm0b?file=/src/compone...
|
| If you meant more from a conceptual standpoint -- the usage
| patterns with Vue 3 is pretty nearly identical for most people.
| You just replace "data()" property with some "reactive()" state
| value in setup (or "ref()" for single values).
|
| You CAN write things like generic hooks/"useXXX()" helpers, but
| you likely won't wind up with a ton of those.
|
| Also, about the reference passing: it doesn't actually really
| work like that. If you pass a "ref()" or "reactive()" value as
| a prop to a child component, and you mutate it there, it
| doesn't propagate to the parent.
|
| Vue will throw this warning: [Vue warn]:
| Avoid mutating a prop directly since the value will be
| overwritten whenever the parent component re-renders. Instead,
| use a data or computed property based on the prop's value. Prop
| being mutated: "someRef"
| rektide wrote:
| > I don't really understand [X]. Doesn't [Y] make your app
| difficult to reason and debug it?
|
| It (passing mutable values around) does make it harder to
| understand the data-flow, yes.
|
| But we programmers keep assuming our rules & protection &
| orderliness are helpful & necessary. And those patterns we opt
| in to keep getting codified, embraced. But along comes someone
| who breaks those rules, & it keeps turning out, a lot of the
| things we think we do to be orderly & safe & sensible are
| actually not that helpful at all, or have impeded really
| wonderful progress elsewhere.
|
| I think of React. Until React came along, everyone doing web
| development knew, it was obviously correct, that we needed
| templating languages. We knew we needed content & code
| separate. We knew content was obviously a different beast than
| code & that content should have tools designed for content. As
| it turns out, mixing code & content actually works really well
| & that we had ruled out a wide space of possibilities that were
| really simple, powerful, & direct.
|
| Relatedly, here, with shared-mutable-variables, I'd pitch that
| hopefully tools compensate for a lot. Hopefully it's possible
| to run the app & see who is modifying values, see who is being
| updated when values change. It's nice being able to have the
| code tell you, up front, easily, but also hopefully watching at
| runtime is possible, makes it easy to suss out what the
| connections & causalities are within a system.
| manigandham wrote:
| Modifications in all JS frameworks are the same. Some
| interaction causes an event, that event is caught and changes
| some data, that data then triggers the render functions which
| show the new UI. This is often coded with event handlers linked
| to actions/mutations/reducers in some kind of state management
| library.
|
| Vue (and some other frameworks) use a reactivity approach where
| the data is wrapped with a proxy that basically automates all
| this code. I find it much easier to reason about since it
| greatly reduces the complexity and you can focus on the actual
| data changes rather than all the plumbing to change the data.
| Exuma wrote:
| No, because they all happen in the setup function, and when you
| export them at the bottom of setup you use them 100%
| identically as you would within mounted() etc,
| quabity wrote:
| I had a similar misunderstanding when I first saw it, but
| globally declaring reactive variables and passing them around
| isn't really what it's about. Take, for example: https://github
| .com/antfu/vueuse/blob/master/packages/core/us.... Any
| component that wants to use a reactive reference to mouse
| coordinates can `const { x, y } = useMouse()` in `setup`, but
| `x` and `y` will refer to different objects in each of those
| components (since the `ref()` is instantiated inside the call
| to `useMouse()`). The _functionality_ is what 's shared between
| components, not the state/references.
|
| That said, if you want to use the composition api to share
| state you can, and you can pretty easily set up some structure
| to restrict mutability: // useStore.ts
| import { reactive, readonly } from 'vue' export
| const useStore = () => { const state = reactive({
| count: 0 }) const increment = (val = 1) =>
| state.count += val return { state:
| readonly(state), // Readonly so state can't be mutated
| directly... increment, // ...only through the
| mutations provided, like Vuex } }
| // store.ts import { useStore } from './useStore'
| export const store = useStore() // Now components can share
| this instance // MyCounter.vue import {
| store } from './store' export default {
| setup: () => ({ count: store.state.count,
| onClick: () => store.increment(5), }), }
|
| Or you can just keep using Vuex for sharing state and use the
| composition API for sharing self-contained bits of
| functionality. Or, if nothing else, using the `setup` method
| instead of the Options API just gives you much more control
| over how you organize your own code within a component.
| umvi wrote:
| So it looks like Vue releases are all named after anime?
|
| For anyone curious, here's the full list:
|
| https://en.wikipedia.org/wiki/Vue.js#Versions
| dane-pgp wrote:
| Is that a JoJo reference?
| fyrmio wrote:
| > Vue 3 has demonstrated significant performance improvements
| over Vue 2 in terms of bundle size (up to 41% lighter with tree-
| shaking), initial render (up to 55% faster), updates (up to 133%
| faster), and memory usage (up to 120% less).
|
| What does 120% less memory usage mean, really?
| JMTQp8lwXL wrote:
| I can only suppose it means 100% less memory consumption by
| Vue, and then Vue somehow frees 20% of memory from other
| running processes, which would lead to some pretty interesting
| results.
| paulsmal wrote:
| also being 130% faster it's rendering results before
| computations
| pier25 wrote:
| In the latest JS benchmarks[1], Vue 3 RC4 is not doing so great
| in the startup metrics or memory usage.
|
| Perf is on par with Preact.
|
| RC4 is not the final release though, we'll see how it goes with
| 3.0.0
|
| [1] https://krausest.github.io/js-framework-
| benchmark/current.ht...
| dboreham wrote:
| Means writer isn't mathematically literate?
| enraged_camel wrote:
| What's with the harsh attitude? It may have been a simple
| typo.
| hugi wrote:
| 120% less mathematically literate than the last writer.
| addicted wrote:
| It means the writer isnt great at English.
|
| There are other languages which would use similar constructs
| where it wouldn't be wrong.
| azangru wrote:
| Do other languages math differently?
| wenc wrote:
| I see the confusion.
|
| 100% more of something = 2x more
|
| 120% more of something = 2.2x more
|
| 120% less of something (problem here!) = 2.2x less = 1 / 2.2 of
| something = 45% of something
|
| I think the writer meant 2.2x improvement in memory usage
| rather than 120% less memory usage -- the word "less" used in
| conjunction with a percentage is confusing.
| ru552 wrote:
| It doesn't need memory anymore. Writes raw to spinning disk. 2%
| faster -50% of the time
| ric2b wrote:
| It also goes ahead and downloads some extra RAM for you.
| tyingq wrote:
| It's definitely not how to show that, but if you follow their
| link (https://docs.google.com/spreadsheets/d/1VJFx-
| kQ4KjJmnpDXIEai...), you'll see the numbers.
|
| The math is like, if it did use 100mb, and now it uses 25mb,
| that's 300% less, because 25mb is the "100%", and you reduced
| by that amount 3 times. Odd.
| infogulch wrote:
| These "75%"/"300%" numbers are ridiculous, the two numbers
| are calculated completely differently. At least be
| consistent.
|
| 100/25-1 = +3 = 300% increase
|
| 25/100-1 = -0.92 = 92% decrease
| holtalanm wrote:
| i think your math is wrong, bud.
|
| 100/25-1 = 3 (300% increase)
|
| 25/100-1 = -0.75 (75% decrease).
| spurgu wrote:
| Correct. :)
|
| Source: https://www.google.com/search?q=25%2F100-1
| spurgu wrote:
| Yeah.
|
| 25 to 100 would be a 300% increase.
|
| 100 to 25 would be a 75% reduction.
| tln wrote:
| Thanks for the link. Someone just started fixing the
| spreadsheet right now!
| gonzus wrote:
| This kind of arithmetic is always very unclear and causes all
| kinds of confusion / miscommunication. This is why I always
| prefer to be explicit about the absolute numbers (maybe in
| addition to the relative percentages): "it used 100 mb and
| now it uses 25 mb (which is a 300% reduction when looking at
| the final result / which is a 75% reduction based on the
| initial result)".
| lioeters wrote:
| Thank you for the link to the spreadsheet. Exact numbers they
| show are:
|
| - "120% less memory usage" - From 9.9 Mb to 4.5 Mb
|
| - "Up to 133% faster updates" - 13.18 (ms?) to 5.64
|
| In both cases, the formula to calculate the percentage is:
| = ( PREVIOUS - CURRENT ) / CURRENT
|
| Oh, actually they just changed it. For the memory usage, it's
| now: = ( PREVIOUS - CURRENT ) / PREVIOUS
|
| ..which shows a more intuitive result: -54.55%.
| huseyinkeles wrote:
| Is this the lingo that statisticians/mathematicians use?
|
| I'd just say 75% drop for 100mb to 25mb.
| tyingq wrote:
| No, I think it's just weird :)
| pletnes wrote:
| No, it's plain wrong. You could say <<vue 2 uses 120% more
| memory than vue3>>, but vice versa is thus a different
| percentage (yes, 75%).
| sedatk wrote:
| I guess it means 20% memory usage relative to the previous
| version?
| x87678r wrote:
| I'm seeing this more often, esp like 3x cheaper it hurts my
| head. For 120% less I'm thinking 100/220= it uses 45% of the
| memory it used to.
| EForEndeavour wrote:
| The only way this makes sense to me is if memory usage was
| reduced by a factor of 1.2, but that sounds so much more modest
| than "120% less" that I'm doubting myself.
|
| On a related note, I tend to avoid expressing changes as
| percentages entirely, in large part because increasing by X%
| and then decreasing by that same X% doesn't get you back to
| where you started.
| zwieback wrote:
| good timing. I'm about to start learning vue.js so I'll start
| with this. We'll see how long it takes to "unlearn" 40 years of
| traditional programming and jump into the world of web apps.
| NanoWar wrote:
| Nice, but does it have material?
| uncle_iroh wrote:
| https://vuetifyjs.com/en/
| NanoWar wrote:
| I dont think this is available for vue 3. Sadly.
| gavinray wrote:
| My only wish now is for the TSX experience to be rounded out.
|
| From a reactivity standpoint, Vue has a much more ergonomic/easy
| to use API for handling component state, effects, and computed
| values (in my opinion) than React.
|
| But in the last 6-8 months, I've leaned away from Single-File
| Components because when you want to do something like define a
| bunch of small components, it's a lot more difficult to do than
| with multiple TSX functions you can chuck in one file.
|
| So I've been using Vue with TSX, and the experience (in the last
| few months only, before that was pretty bad) is _okay_ , but not
| as solid as you'd get with React.
|
| I'm not the only one who must feel this way, because this exists
| and has a lot of stars:
|
| _" Reactivue: Use Vue Composition API in React components"_
|
| https://github.com/antfu/reactivue
|
| Unfortunately, this is a weird stance to take in the Vue
| community, almost nobody uses JSX/TSX. Because of this, the
| development efforts towards it aren't as much a priority.
|
| Overall, I'd rate the experience as "decent" and "totally
| usable", but I hope to see the DX for Vue's TSX community improve
| over the coming months.
|
| ---
|
| Edit 2: Disregard the below, this already exists apparently
|
| Edit 1: Having to write two type definitions for Component Props:
| one TS interface/type, and one as the JS object sucks. That's my
| one big complaint.
|
| I know it's impossible because props need a runtime value but
| someone should make a plugin/babel transform to decorate the
| "props" key from the generic argument here:
| const MyComponent = defineComponent<MyComponentProps>
|
| Use reflection on "MyComponentProps" to set "props" key.
|
| There's another comment below discussing this drawback too.
| lloydatkinson wrote:
| They have improved TSX support in Vue 3. Did you try it? What
| does or does not work? I'm planning on switching to TSX.
| gavinray wrote:
| No it totally works, it's not bad. The one big broken thing
| in August was that the type for components (RenderContext)
| thought component props should be passed as "props={ myprop:
| 1 }" instead of "myprop={1}".
|
| See:
|
| https://cdn.discordapp.com/attachments/568037134968160256/73.
| ..
|
| Comment I made about this I dug up:
|
| _" The issue seems to be that the definition for
| RenderContext<Props> puts the props under the key "props", so
| when trying to define them on your JSX/TSX element, it
| expects you to put them under <MyComponent props={ } />. If
| you do this though, it breaks in another way because it's
| missing the other properties of RenderContext and it's not a
| great API =/"_
|
| This is fixed now though I am pretty sure.
| EvanYou wrote:
| > Having to write two type definitions for Component Props: one
| TS interface/type, and one as the JS object sucks.
|
| Uh, you don't have to? TS inference works with the JS objects.
| There's no need to provide the generic argument here.
|
| Also check out this: https://github.com/vuejs/rfcs/blob/sfc-
| improvements/active-r... (auto-generating runtime types from TS
| interface)
| nikeee wrote:
| I just looked at the sample code you provided. Having no
| experience with Vue (only React and Angular), but heavy TS
| user, something came to my eye:
|
| Is it correct that `declare const props` will not only get
| used to type-check stuff but also emit code based on that?
|
| I think thats unintuitive. TS basically means "take away all
| the static types and you get what the compiler emits". A lot
| of developers won't be able to distinguish between TS and the
| magic that some framework does. I've made similar
| observations when working with Angular devs.
|
| Correct my if I've mistaken something. /2c
| gavinray wrote:
| Holy shit, Evan You replied to my comment.
|
| Happy Vue user since 2016.
|
| > TS inference works with the JS objects. There's no need to
| provide the generic argument here.
|
| That's totally valid -- I am just being nitpicky and
| complaining because if possible I'd prefer to do it the other
| way: TS type -> JS object
|
| > auto-generating runtime types from TS interface
|
| Whoa. Well, that solves that then.
| JMTQp8lwXL wrote:
| > Unfortunately, this is a weird stance to take in the Vue
| community, almost nobody uses JSX/TSX.
|
| Typed components is 200% of why I'm writing React these days.
| Angular has typed components too (they went in on TypeScript
| early), but the Angular Language Service / IDE integration
| didn't come to later-- so for a period, no intellisense.
|
| But having intellisense while writing TSX is so wonderful,
| especially when you're working with complex or deeply nested
| object structures.
| gavinray wrote:
| Do you write Vue as well?
|
| I have to hop back and forth between Vue and React frequently
| and the experience of writing a TSX component is pretty
| nearly identical.
|
| For stateless components -- it's literally the same syntax as
| React.
|
| For stateful components, you just need to wrap your component
| in "defineComponent()" and your TSX elements get returned
| from a closure in "setup()".
| hugi wrote:
| Live release announcement with Evan You going on right now:
|
| https://www.youtube.com/watch?v=Vp5ANvd88x0
| agumonkey wrote:
| in case people wonder, still live as I type
|
| ps: 5min later it's over
| x87678r wrote:
| I didn't expect him to say "Enjoy the Vue" ha.
| hugi wrote:
| Programmer _and_ dad-level humor can be a pretty deadly
| combination.
| kbenson wrote:
| The combination of the two is so dangerous you could say
| it's dadly.
| awinter-py wrote:
| hooray <Suspense>
| RNCTX wrote:
| Vue is the only one of the most popular 3 frameworks that can
| easily be used on a minimal basis to sort of "spruce up" old
| applications by selectively adding it here and there in the
| templates.
|
| Seems like they should try more marketing and community outreach
| toward that end.
|
| Gradual adoption is a feature / selling point not many web
| development frameworks can claim.
| brlewis wrote:
| > Vue is the only one of the most popular 3 frameworks that can
|
| I don't know if you intended it this way, but the start of this
| comment makes it automatically flamebait.
|
| Discussion around release announcements can quickly turn into a
| flame war. Please use caution.
| hobby-coder-guy wrote:
| What do you mean?
| hombre_fatal wrote:
| For one, it's not the only one. And instead of just talking
| earnestly about a cool feature of Vue in a Vue thread, to
| say nothing of other frameworks, you've now anchored the
| convo to framework comparison with your incorrect premise.
| punnerud wrote:
| And a flame war, aka lot of comments compared to votes on HN,
| result in less time on the front page. So there is not the
| biggest benefit to oversell.
| goodoldneon wrote:
| Why can't React do the same?
| manigandham wrote:
| React and Vue can both be used directly with script tags,
| however the biggest difference is that React uses JSX while
| Vue uses HTML templates (but also supports JSX).
|
| 99% of the time, HTML is easier and faster to write, with the
| built-in directives providing all the functionality you need.
| More importantly though, HTML can be generated by every
| single server-side framework, and this makes it very easy to
| have server-side code from any language stack that becomes
| interactive using a Vue client-side layer.
| mythrwy wrote:
| That's exactly right and this is a much underrated
| capability and I think it's the point being missed by those
| saying "well if you do XXX you can include React with a
| script tag too!"
| pricecomstock wrote:
| I'm not sure about React's capability with this, but Vue can
| very easily run with no build stage. You can load Vue from a
| CDN and use a couple lines of JS to point it at a DOM element
| in your app. Then you can write a plain JS Vue object (what
| goes inside the <script> tags in a .vue file), and all this
| logic will apply inside the element you pointed it at. You
| can also write components, although that gets a little clunky
| without a build stage.
|
| This has allowed me to do things like create Vue-based tools
| in a locked-down corporate environment where I was not able
| to install Nodejs on my machine.
| shados wrote:
| React can be run from a single file from a CDN, and used
| without a build stage. Only catch is you don't get JSX.
| While by today's standard some people might consider that
| unacceptable, it was a fairly common way to use it when it
| was new (because relatively fewer teams used builds for JS
| back then, and JSX was far from being widely accepted).
|
| My first year of React development was without JSX even
| though we DID have a build step (I was categorically
| against it at the time. Things changed, haha).
| ht85 wrote:
| React has been able to use jsx without build forever,
| here is a modern take: [1]
|
| The babel script is huge but it might be an option to get
| the ball rolling on a big upgrade.
|
| 1. https://medium.com/@to_pe/how-to-add-react-to-a-
| simple-html-...
| bdcravens wrote:
| React can, but less ergonomically than most developers are
| used to.
| HonshinM wrote:
| Could you comment more on how it's done?
| pier25 wrote:
| Modern React uses JSX which is then transformed at build
| time into function calls.
|
| You can write those function calls yourself, but it would
| be a tremendous PITA.
| lhnz wrote:
| In this case, you could use `htm`:
| https://github.com/developit/htm#usage
| pier25 wrote:
| Yeah totally. Or even use Preact by the same author which
| is smaller and faster than React.
| yandie wrote:
| I find it amusing that you are allowed to run arbitrary
| Javascript but can't run NodeJS on your machine. Sometimes
| corporate security can be a theatre.
| RNCTX wrote:
| I mean, you gotta trust someone at some point.
|
| If they don't trust Google, Microsoft, and Apple to keep
| Javascript in the browser sandbox-jail then they're gonna
| be re-inventing an awful lot of wheels ;).
| The_Colonel wrote:
| Frontend JavaScript is sandboxed and you can't really
| disable it without crippling 90% of websites.
|
| node.js code can cripple your system way more. So this
| does not really seem surprising.
| _jjkk wrote:
| Please someone correct me if I'm wrong. It seems like you can
| only implement React using the full "modern JS stack", i.e.
| Node/Webpack/...
|
| So if you want to use it on one page, it's a hard sell to set
| up all that infrastructure (and document it for the team)
|
| On some sites I've used Vue.js by simply adding a <script>
| tag with vue.min.js.
|
| On sites already using Gulp or similar, it's pretty simple to
| incorporate the Vue bundle and use it on one or a few pages.
| RNCTX wrote:
| Apparently this is possible:
|
| https://shinglyu.com/web/2018/02/08/minimal-react-js-
| without...
| acemarke wrote:
| React can be added to a page with just a script tag in the
| same way as Vue:
|
| https://reactjs.org/docs/add-react-to-a-website.html
|
| Having said that, React is normally used with JSX syntax,
| which requires a compile step.
|
| You _can_ use it with "raw" `React.createElement()` calls,
| but that's generally unwieldy and almost no one does that.
|
| However, there's a very neat library called
| https://github.com/developit/htm , which is an almost-JSX-
| compatible syntax that uses JS template literal strings,
| and requires no compile step.
| rhengles wrote:
| This looks like the perfect place to mention my project
| template used to create Vue 3 apps without the need for
| Webpack or any other build tool:
|
| https://github.com/arijs/vue-next-example
|
| I already integrated vue-router, and am currently on the
| process of fully integrating Vue server renderer. I already
| have a basic usage implemented, where the home page is
| compiled to a html string, but I still need to make it easy
| to compile all pages and to implement client-side component
| hydration.
| jdavis703 wrote:
| There is no need to run NodeJS in production with React. In
| fact, React doesn't even require a fancy build system
| (though for anything more than a toy app you're tempting
| fate.)
| manigandham wrote:
| React can also be used with just script tags. It uses a
| compiler to turn JSX into a render function (the same as
| Vue which accepts JSX or HTML) and these compilers are
| written in JS and can run in the browser. Also modern
| browsers are much better at supporting JS modules which
| makes it easier to include other libraries.
| RNCTX wrote:
| I suppose it could, but there are annoyances with JSX
| defaults.
|
| For instance, Vue provides a method to explicitly declare
| your template variable delimiter syntax. Last time I looked
| this was requested of React, but not implemented, someone
| correct me if I'm wrong on that and it has come along in the
| last year or two. So.. lets say you wanna put some modern
| Javascript in some Django templates to make them look spiffy.
| With Vue you can just declare your delimiter to be `[[`
| instead of `{{`, (because `{{` conflicts with Django's
| template variable syntax) with a one-liner setting.
|
| I'm sure you _could_ do this in React with a custom parser
| function (or maybe there 's a third party library?) but it's
| a lot easier when the framework just gives such things to you
| out of the box.
|
| If I do this all over the place and some other guy comes
| along years from now with no documentation on what he's
| getting into, he doesn't need to know too much to figure out
| what's going on and work on it. Right away he'll see
| "delimiter = [[" at the top of the script block in a template
| and can grep double brackets in the whole project to get an
| overview of what's being done.
| shados wrote:
| React doesn't have templates, so that's a non-issue. JSX is
| sugar on JavaScript, but it's not a string. So template
| delimiters don't matter (that is, if you didn't use a build
| step, then it would be straight javascript functions calls)
| diob wrote:
| You can do the same thing with React though, you can
| arbitrarily render a React root anywhere, and an arbitrary
| number of times on the same page.
|
| For instance, I work on an app that was originally written in
| Backbone / Marionette, but I was able to write generic
| connectors to allow us to drop in React at any point in the
| tree. Similarly, we can go back to Marionette / Backbone at any
| point in the tree. It's made gradually migration towards React
| possible.
|
| Claiming React can't do the same sort of sprucing up as Vue is
| just a lack of imagination. Show me an old app, and I'll show
| you how to do it.
| lhorie wrote:
| React is a quite bit more all-in than Vue though. For
| example, an old app I'm aware of has HTML generated by JSP
| with its own convoluted maven build process and uses a mix of
| AngularJS and jQuery to hydrate client-side functionality on
| top of it. The development workflow is a draconian exercise
| in acrobatics through remote desktops and VPNs in really old
| laptops (because "security" and unions).
|
| Vue has similar hydration capabilities as Angular, but with
| React, you are pretty much forced to describe the view from
| scratch in JSX. To make things more fun, many islands need to
| be aware of each other, something that is not super idiomatic
| in React land.
|
| Just some food for thought.
| jhall1468 wrote:
| I don't know if "from scratch" is really a fair statement.
| React accepts HTML in the render function, so the only
| thing you'd _need_ to do is modify the variables to match
| JSX 's variable syntax, which is exactly what you'd have to
| do with Vue.
|
| I think it's all pretty much the same deal. You might argue
| Vue's template syntax is closer to HTML than JSX is, but
| that doesn't really feel like the major issue when slowly
| refactoring a large application.
| lhorie wrote:
| I'm not talking syntax. I'm saying that vue can be added
| on top of a third party DOM that may have server-rendered
| data embedded in it. You cannot hydrate React on top of
| dynamic HTML that was generated with JSP/PHP/.NET/etc
| unless you a) give up JSX (a big departure from idiomatic
| React) and b) interpolate server variables into your JS
| (a no-no in pretty much every non-SPA framework)
|
| For example, take a rails app, then do the equivalent of
| $('#foo').togggle() based on some condition. In React,
| AFAIK you can't unless React knows what the markup being
| toggled is. Vue can do it without knowing anything about
| the markup inside.
| [deleted]
| crescentfresh wrote:
| Agree with this sentiment. I was in web dev since pre-
| jQuery/Backbone, but left during the rise of the js-framework
| wars. I then returned to this area as I needed to add
| functionality/"spruce up" a web app within my organization and
| randomly chose Vue for the task. It went smoothly and didn't
| require re-writing anything.
|
| Meanwhile the web development team are still fighting with the
| flagship "all-or-nothing" angular app, still stuck on 1.7
| because anything else is an entire rewrite.
| swyx wrote:
| i'm afraid this is pretty much plain wrong. react and svelte
| also support incremental adoption, and i dont know angular but
| i'd hazard there's a way to do it too if you bothered to ask
| angular devs.
|
| what you're responding to is _marketing_ , which Vue has done
| an effective job of. thats fine, but it is unfair of you to
| conclude "Gradual adoption is a feature / selling point not
| many web development frameworks can claim."
| gavinray wrote:
| I think the original commenter might have intended to mean
| without additional build tooling?
|
| While it isn't pretty, you can drop Vue in a <script> tag on
| a page and define components with template strings.
|
| In React, you can technically do this, but you need to
| either:
|
| A. Use React.createElement() calls
|
| B. Use something like "htm" also included via a <script> tag,
| with template literal tags to wrap your component renders
|
| You can technically include Babel in a <script> tag to use
| JSX, but it only works with <script> blocks that have been
| tagged as "JSX", not within regular ".js" files you can
| import using "src="
|
| Jason Miller a-la Preact is the person I see most
| consistently working on and pushing this sort of React/Preact
| no-build setup. I definitely get the appeal, for this exact
| usecase -- you have a simple, mostly-static website (or
| something old and built with jQuery) and you want to
| incrementally modernize it/add functionality without
| rewriting the whole thing.
|
| https://twitter.com/_developit/status/1220102334048624643
| SPascareli13 wrote:
| I can tell you that not only he is right, but I've used Vue
| for exactly that purpose before and works like a charm.
|
| You can go pretty far using Vue with a <script> tag before
| you start needing build tooling.
| hobby-coder-guy wrote:
| Svelte. Popular.
| holtalanm wrote:
| as someone who has used both Vue and React in a _very_ legacy
| system, I can say unequivocally that Vue was massively easier
| to integrate into our system than React was.
| winrid wrote:
| You can do this with Angular. Just create a component, insert
| the compiled script tag, and then you can reference it in the
| html like: <my-component />
| jaequery wrote:
| if this means no more Vuex, i'm all for that. that extra
| abstraction layer never proved useful to me.
| deergomoo wrote:
| Out of curiosity, how do you handle data needed by tons of
| components at different tree depths (info about the current
| user for example)?
|
| I don't always reach for Vuex, but when an app reaches a
| certain size it sure beats passing every bit of common data
| down through the entire tree, as I find you quickly hit a point
| where you're passing data to components solely so it can pass
| it to _it's_ children.
| zmmmmm wrote:
| It's funny I still have never really understood the case for
| Vuex. So far I have built decent complexity apps just by
| having a global reactive object that all components link to
| directly in their Vue data and I have yet to hit a problem. I
| see huge writeups and design patterns all suggesting I really
| need to use a state management library and I'm waiting for
| the day the penny drops and I realise what a mistake I've
| made but so far everything just keeps rocking along .... what
| am I missing?
|
| (I get that there are some nice features like time travel
| debugging etc but none of them seem outweigh the giant
| additional complexity of routing every single state change
| through 1-2 extra layers.)
| jbjorge wrote:
| Since the reactivity api is exposed it's very easy to write a
| file to hold whatever state you want.
|
| Benefits: easy to create, type safety is simple.
|
| Drawbacks: you don't get a serializable state log for free
| (that can be recorded and replayed when hitting bugs).
| pier25 wrote:
| Not sure about Vue 3, but in Vue 2 you can simply use a Vue
| instance without a template as a reactive store. You can also
| share an object between Vue instances.
|
| See: https://vuejs.org/v2/guide/state-management.html
| gorbypark wrote:
| Vuex is still around. They just haven't finished integrating it
| into Vue Dev Tools, yet.
| badhabit wrote:
| i learned vue2 3-4 years ago.
|
| should i learn vue3 or svelte instead?
| k__ wrote:
| Depends on what you want.
|
| I researched tech required in job offers and React was first,
| running circles around Angular and Vue. Nobody spoke of Svelte
| j-krieger wrote:
| Where I live, VueJs isn't even mentioned in any job postings.
| Large companies still work with older Angular projects, new
| projects are more often than not done in whatever fits the
| need.
| dbrueck wrote:
| Maybe take both for a brief spin, but my vote would be for
| svelte. I used vue2 about the same timeframe as you (stumbled
| upon it while trying to find alternatives to React or whatever)
| and really liked it a lot.
|
| About a year ago I had to tackle a few new web projects so I
| decided to give React/Angular/etc another look... and promptly
| went hunting for alternatives again, and that's how I found
| svelte. We've got 5-6 svelte-based projects in production now
| and have really, really enjoyed it.
|
| All that said, I haven't looked at vue3 in depth yet, so maybe
| it's amazing, I dunno. :)
| davidwparker wrote:
| Honestly, it takes 1/2 a day to read through all the svelte
| docs and go through the tutorial.
|
| It's incredibly easy to use and I've (personally) liked it a
| lot more than Vue(2).
| pier25 wrote:
| I started playing with Vue in 2015, even wrote an article [1]
| about Vue which was pretty popular a couple of years ago (it
| was hosted on Medium then).
|
| These days I'm focused on Svelte. It's faster and lighter, but
| IMO the best feature is you write a fraction of the code. When
| I go back to old React or Vue projects I want to cry. Svelte is
| so much more zen.
|
| OTOH the ecosystem is minuscule so you are on your own. The
| support for TS and testing is not great either. Svelte is easy
| to learn but it's not very popular yet. I would understand if
| someone argued it's a risky bet although I'm building my SaaS
| with it.
|
| [1] https://www.pierbover.com/posts/vuejs-good-meh-ugly/
| phaedryx wrote:
| Honestly, this https://svelte.dev/faq#how-do-i-test-svelte-apps
| made the decision to choose Vue over Svelte pretty easy for me.
| deergomoo wrote:
| You could do both tbh, there's not much to Svelte (as the name
| suggests).
| duhi88 wrote:
| If you know Vue 2, Vue 3 will be easy to learn, as well. There
| are some more advanced features you can choose to use if you
| want, but I guarantee you could pick it up really fast. This
| isn't an AngularJS -> Angular sorta change.
|
| Also, give it a few more months before building anything non-
| trivial. Some of the more popular libraries for Vue 2 still
| need to up updated for Vue 3 (vue-router, vuex, for instance).
| therealmarv wrote:
| anybody know the status of Nuxt and vue 3 support?
| gavinray wrote:
| It's meant to be released sometime within the coming weeks from
| contributor comments IIRC.
|
| It works well with the Composition API plugin for Vue 2 though.
| They have a dedicated package for this.
|
| With the Nuxt VCA + Nuxt TS plugin, the experience is solid
| IMO.
| wishinghand wrote:
| It's coming. This is just the slides, but some details were
| gone over by a main Nuxt contributor:
| https://nuxtjs.slides.com/atinux/state-of-nuxt-2020
| didip wrote:
| I am impressed with the amount of energy Evan is pouring in this
| open source project.
|
| I am curious if he ever experience boredom working on Vue.
|
| I am also curious if Patreon based income is sustainable for the
| long run. What if there's another new sexy JS framework in the
| future?
| Traubenfuchs wrote:
| > What if there's another new sexy JS framework in the future?
|
| I am sure he can save a lot, with that income.
|
| I am sure he could find a normal job, with those skills.
|
| I am sure he could be a freelancer, with "created vue.js" as
| reference.
|
| His Patreon based income would slowly die with the decline of
| Vue.js and he'd have enough time to look for something else.
| bdcravens wrote:
| Patreon income may not be, but Vue-based income should be.
|
| This company focuses on development of Coldbox, a ColdFusion-
| based framework still in active development. If they can
| support a team and still continue development, Vue should be
| good for a while
|
| https://www.ortussolutions.com/
| wmf wrote:
| Market growth can cover a lot. Even if, say, Svelte gets bigger
| than Vue in the future, Vue could still be bigger than it is
| today.
| wishinghand wrote:
| > I am curious if he ever experience boredom working on Vue.
|
| I was curious about this too when Vue 3 overshot its release
| estimate and then he started working on Vite, which is a build
| tool.
| mushufasa wrote:
| > What if there's another new sexy JS framework in the future?
|
| That's how a market works. It's a strong incentive to keep Vue
| sexy.
| j-krieger wrote:
| The market also isn't as volatile as people make it out to
| be. The top most used js frameworks (React, Angular and Vue)
| have been in the top spots for 5 to 7 years now. I guess the
| market might as well be settled. Of course there are some new
| comers every year, but they don't enjoy a large market share.
| Hell, I've not even seen VueJS used once in any serious
| project in the industry.
|
| React and Angular are here to stay, and there's no changing
| that.
| Exuma wrote:
| WTF are you talking about... so you don't consider any of
| these to be serious? sentry.io, Gitlab, Grammarly,
| Codeship, Behance
| franklampard wrote:
| React is winning in U.S.
|
| Vue is winning in China
| solarkraft wrote:
| Angular appears to be "winning" in Germany (or all of
| Europe?).
| untitaker_ wrote:
| Sentry is not using Vue.
| erokar wrote:
| Angular seems to be dying. Svelte is an interesting
| contender. I think it will be React's main competitor given
| a year or two.
| mattlondon wrote:
| Angular is massive - MASSIVE - within large orgs you will
| have heard of but which I cannot name for obvious
| reasons.
|
| The twitterati and hobbyist crowd seem to love react, but
| anecdotally I've yet to see it used seriously at a BigCo,
| but Ng+TS is everywhere.
| sdfhbdf wrote:
| Your comment seems to present anecdotal evidence as facts
| about $framework's popularity. I think that's misleading.
|
| I'm wondering if there's a scraper out there crawling
| Alexa TOP 1xxx pages for use of specific libraries,
| frameworks? Maybe that would present a more accurate
| picture about this.
|
| Also it's often misleading since in any company with more
| than a few employees there seems to be more than one team
| of developers which often leads to different frameworks
| being used in different parts of the company. In $dayJob
| we use Angular in some legacy internal stuff, React in a
| rewritten consumer-facing project and preact or jQuery in
| a different consumer-facing project.
|
| It's not that simple to determine marketshare of
| frameworks I think. We can just present different numbers
| and draw different conclusions from it, e.g. number of
| job postings mentioning specific frameworks, number of
| downloads in a registry, number of domains using it
| (assuming one app per domain), number of stars on github
| or number of people claiming to use it in the
| stackoverflow survey.
| mattlondon wrote:
| Builtwith.com does what you describe although not sure if
| it can detect react/angular/etc.
|
| Not everything is public facing though, particularly in
| enterprise
| JMTQp8lwXL wrote:
| A lot of the web isn't publicly accessible. And most .com
| marketing sites are built on a much different tech stack
| than the actual product. Example: landing page is
| Wordpress, actual site is a SPA (be it React/Angular/Vue
| etc).
| miohtama wrote:
| I can name Google.
| Barrin92 wrote:
| >Angular seems to be dying
|
| lol. In the US open jobs for Angular and React are about
| 50/50. (Indeed/SimplyHired), in much of the EU Angular is
| way more popular than React still.
|
| Is Angular the new Rails in this regard? It's not going
| anywhere, massive businesses use it at a huge scale and
| it works.
| blntechie wrote:
| Angular is huge inside big enterprises. Much more popular
| than React.
|
| Svelte is very cool though.
| LocalPCGuy wrote:
| This is a popular opinion particularly if all someone
| pays attention to is Twitter and Reddit but I'd argue it
| is a wrong opinion.
|
| Angular is alive and well, and being used/adopted every
| day for projects no one hears about. It isn't the "sexy"
| choice, but it is the one a lot of companies make.
|
| And if you're gonna point to opinion polls, and all kinds
| of respect to those who put them out, but they have a
| hard time capturing Angular usage due to selection bias.
| erokar wrote:
| Depends where you live and work I suppose. I used to work
| in a consultancy firm in Norway that was all in on
| Angular two-three years ago. Angular has been very
| popular in enterprise here. But Twitter and Reddit reach
| enterprise too in the end. The consultancy firm has now
| switched more or less entirely over to React because
| Angular is so out of vogue.
| fein wrote:
| US consultant here with a similar story. A lot of what
| we're doing now seems to be moving toward headless CMS
| and headless ecommerce with NextJS/Gatsby for the
| integration point. I'm still a big fan of Angular, but
| the amount of work we're getting asking for Angular has
| dropped off a cliff.
| lokethien wrote:
| Similar story in the old company I worked for. Though I
| have experienced that there are a few companies that are
| happy with Angular and see no reason to switch.
| machello13 wrote:
| I used to work for a big financial analytics company that
| used Angular 1.5 for _everything_. Around the time I
| left, they started migrating to VueJS instead. Obviously
| this is all anecdotal, and I have no doubt AngularJS is
| still being used in a lot of places, but I think there 's
| reason to believe its share might be shrinking.
| ccday wrote:
| GitLab uses Vue, that qualifies as a serious product.
| jtdev wrote:
| I've deployed a number of applications using Ember's
| (Octane) and will continue to use that over React, Angular,
| and Vue for as long as these other frameworks continue to
| prioritize fp zealotry over getting shut done.
| Exuma wrote:
| What do you mean 'fp'? Ember was quite literally one of
| the worst experiences ever. Not having javascript
| expressions in handlebars is literally excrutiating. I'm
| so glad I never have to use ember, ever, ever again.
| save_ferris wrote:
| I agree that there will be a need for react/angular talent
| for many years to come. That said, I think engineering orgs
| are picking up on the fact that rolling web apps this way
| introduces lots of complexity and requires lots of
| resources to maintain and extend. I really don't want to
| think about regularly maintaining a 10-year-old redux-
| backed react app down the road.
|
| Whether react/angular/vue are able to continue improving
| enough to justify staying within that world remains to be
| seen. It's very early days for some of the new frameworks
| out there, but with web assembly on the horizon, companies
| will again be motivated to modernize, however that looks.
| wenc wrote:
| The closest thing I can see to a contender is Svelte.
|
| I'd be unlikely to start any new project on Angular. React
| remains dominant and would be a viable option, except Vue
| feels more lightweight and approachable. I'm sticking with
| Vue for now.
| IshKebab wrote:
| I was hoping for better Typescript support for typing properties,
| since that is where 90% of our type errors occur. But it seems
| like you still have to specify the types manually. The example
| from the manual: const Component =
| defineComponent({ props: { name: String,
| success: { type: String }, callback: {
| type: Function as PropType<() => void> },
| message: { type: Object as PropType<ComplexMessage>,
| required: true, validator(message: ComplexMessage) {
| return !!message.title } } }
| })
|
| Contrast this with React where this would be something like this
| (I think; I've never used React): interface Props
| { name: string; success: string;
| callback: () => void; message: ComplexMessage; }
| export default class Component extends React.Component<Props> {
| ...
|
| Quite disappointing. Maybe not that surprising given Evan said he
| only started using Typescript very recently, and many beginner
| Javascript developers don't realise that they should really be
| using Typescript (fortunately Evan isn't one of them). I would
| recommend still avoiding Vue for this reason alone.
| EvanYou wrote:
| It's not that we can't implement it like that, the real
| challenge is in minimizing breakage from v2. We decided it's
| better to not completely alter how props are declared because
| that would be too much breakage.
|
| Instead, there's the compiler-based approach with `<script
| setup lang="ts">`:
| https://docs.google.com/presentation/d/1VjBM6ae-fuawK1TltYLX...
| (runtime props definitions auto-generated from TS interface)
| dbfa wrote:
| More detailed info: https://github.com/vuejs/rfcs/blob/sfc-
| improvements/active-r...
| IshKebab wrote:
| But if the prop definitions are generated at runtime that
| means Typescript can't check them at compile time surely?
| Better than Vue 2 I guess but still not as good as React.
|
| Fair enough on not wanting to break things, but I still feel
| like it is Vue's second biggest flaw and worth breaking to
| fix.
| mthoms wrote:
| FYI Evan, that doc is currently private.
| solarmist wrote:
| The google doc is restricted.
| Udik wrote:
| You can use vue-class-component and vue-property-decorator as
| described here:
|
| https://class-component.vuejs.org/
|
| You get to define your components as classes with their methods
| and properties, and can declare props and watchers via
| decorators. Overall a good typescript experience.
| IshKebab wrote:
| That is what I currently do. It's ok within a component, but
| there's no type checking when another component uses yours
| and gets the prop types wrong.
| quaffapint wrote:
| Anyone know if Vue 3 is isolated? Like can you use it to make 3rd
| party widgets and not worry about version conflict like you would
| with Vue 2?
| ausjke wrote:
| Good to see this out. I want to pick a good frontend scheme for
| future projects but I don't really need most of the fancy SPAs
| and the complexity coming with it.
|
| Invested a few weeks on Vue a few months back, then the concern
| about 'React has 80% market share and you can find React
| developer much more easily in the west" never went away.
|
| Maybe Mithril is the way out? I just need a really light-weight
| client-side-ajax MVC for some embedded product webUI, in fact
| jquery+BT might do the job well but again, jQuery is not modern
| any more.
|
| Not a frontend guy, picking a direction there has always been
| challenging.
| lloydatkinson wrote:
| So you suggest switching from one of the Big 3 to Mithril
| because you are concerned about market share, while Mithril
| probably has magnitudes less market share?
| ausjke wrote:
| if i have to invest into one of the Big 3 then market-share
| becomes a concern, each of them requires quite some time and
| efforts to master, and you normally don't have enough extra
| time to switch after a while.
|
| if I pick less known but easier-to-learn-got-job-done option
| I expect to invest less efforts, thus market-share is less
| critical for the concerns.
| madoublet wrote:
| I think what is not mentioned with any of the big SPA
| frameworks is the amount of time you invest in the churn
| between versions. After dealing with this in Angular for a
| number of years, I ended up going with stock JavaScript for my
| recent projects and could not be happier. Performance is much
| better. I have a better understanding of what goes into the
| product. And, I am not constantly dealing with a new version
| and breaking changes every 3-6 months.
| ng12 wrote:
| That's really an Angular problem; React and Vue have had very
| few breaking changes over the years.
| swyx wrote:
| indeed. React 16 celebrates its 3rd birthday next week.
| (https://reactjs.org/blog/2017/09/26/react-v16.0.html)
| ahpearce wrote:
| AlpineJS? A bit polarizing, but definitely lightweight...
| deergomoo wrote:
| Alpine is great for the niche it fills. All the stuff where I
| used to say "Vue would be overkill for this, I'll just throw
| something together with jQuery", I now use Alpine for
| instead, and it's a much nicer experience. And at 7kb you
| can't really grumble.
| TravelPiglet wrote:
| Can I use it by including it with a script-tag?
|
| Vue 2 was kind of possible to get up and running with a script-
| tag to get components in a pre-existing app.
| Exuma wrote:
| Yes its possible
| brylie wrote:
| I've been confused by some of Evan's presentations about
| performance gains and other statistics. For example, the release
| notes say
|
| > updates (up to 133% faster)
|
| How can something be > 100% faster?
| wenc wrote:
| If you take 100% faster to mean 2x faster (takes 1/2 the orig
| time), 200% faster to mean 3x faster (takes 1/3 the orig
| time)...
|
| Then 133% faster means 2.33x faster (takes 1 / 2.33 = 0.42 the
| orig time).
| Roboprog wrote:
| By doing twice as much in the same time, I guess.
| jaequery wrote:
| is reactive() just a mere wrapper around ref() ?
| gavinray wrote:
| Kind of -- reactive() lets you declare multiple values at once,
| and you can read the property directly.
|
| ref() is for single values, and to get at the actual VALUE, you
| need to use "myRef.value" const state =
| reactive({ msg: "hello", count: 1 }) state.msg //
| "hello" const msg = ref("hello")
| msg.value // "hello"
|
| Though when you use ref()'s in templates, it will bind to
| .value for you.
| mthoms wrote:
| I find myself using `const state = reactive({...})`
| exclusively now. It's just way simpler (read:less mental
| overhead). But, I've only been using the composition API for
| a short while now.
|
| Do experienced Vue devs actually use both regularly?
| Exuma wrote:
| According to the vue discord where I asked a lot of
| composition API questions, pretty much people use ref
| exclusively. It's much more explicit in your `use*`
| composition files when you have to call .value. It's rare
| to me to export a very large object of keys, and I have yet
| to use it yet.
| gavinray wrote:
| Personally, I rarely use refs. I think they have more use
| when creating general-purpose libraries for Vue.
|
| You can also just call "toRefs()" on a "reactive()" object
| though.
|
| Refs are also useful if you want to destructure a reactive
| object without breaking the reactivity, scroll down just
| below this:
|
| https://composition-api.vuejs.org/api.html#torefs
| lykahb wrote:
| I am impressed how they redesigned both internal architecture and
| a public API while keeping the users happy. Many well written
| projects fall into the trap of being a great fit for the
| contemporary practices but become less relevant over time as the
| ecosystem changes. Well done, Vue!
| diminish wrote:
| curious how easy it will be to move from vue 2 to vue 3
| Exuma wrote:
| Its very easy for users, quite difficult for library
| maintainers
| gregmac wrote:
| This is a great tradeoff actually. It sucks to break
| backwards compatibility, but often that's the only way to
| move forward. If you _have_ to break something, affecting
| the least number of developers is best.
|
| This also gives a chance for a refresh of the ecosystem:
| libraries that are no longer relevant (eg, their
| functionality has been incorporated or otherwise made
| obsolete) can go away, and they get a nice "out" so no one
| has to feel bad about shuttering a project.
|
| It also gives a chance for keeping the libraries using
| newer APIs, or even newer libraries to gain traction.
|
| Very similar to doing a controlled burn in a forest: Worse
| than no fire at all, but orders of magnitude better than an
| actual wildfire.
| Jarwain wrote:
| They're working on a "migration build" which is a version of
| v3 that has support for v2 behaviors + warnings, which should
| help smooth any transition.
|
| On top of that, v2.7 slated for 2021Q1 also includes the
| relevant migration warnings, which should help make life
| easier
| [deleted]
| amitp wrote:
| The migration guide [1] lists breaking changes. If you use
| many Vue 2 libraries you'll want to wait until they're
| updated to Vue 3. (I reminds me of the Python situation where
| if you used lots of Python 2 libraries you'd write your new
| code in Python 2 instead of Python 3, until those libraries
| migrated to Python 3)
|
| [1]: https://v3.vuejs.org/guide/migration/introduction.html#b
| reak...
| stared wrote:
| Even for a medium-size project it is not that hard. Most
| things are backwards-compatible and the transition can be
| gradual.
|
| Our example (look at diffs): https://github.com/Quantum-
| Game/quantum-game-2/pull/227
| winrid wrote:
| Ha, I literally just built my first Vue 2.0 project yesterday.
| I'm already behind! :)
|
| (just a Chrome extension)
| https://github.com/FastComments/fastcomments-debug/blob/mast...
___________________________________________________________________
(page generated 2020-09-18 23:00 UTC)