https://htmx.org/
https://unpoly.com/
A lot better, imho.
Vue 3.2
141–150 of 153 posts
Re: Vue 3.2
#142Anyone moved from React to Vue. I've been reading the Vue docs and I like some things about it but the compositional model seems a bit more confusing compared to React. Also, I think I do prefer working with JSX versus using html templates. I prefer that close coupling of JS logic and JSX presentation. The most appealing thing about Vue is that it seems to be more of a framework, maybe somewhere in the middle between…
I'm in my first few months with Vue after 5 years of react and so far I'm loving it for the most part. I'd say the things I like the most are 1) More of a framework than s library (official router, state, css-in-js, etc) and 2) automatic tracking of dependencies. The worst part so far has been mostly related to the ecosystem. I find Next superior and better maintained than Nuxt, and the 2/3 transition situation looks…
> (sadly reminds me of the python 2/3 situation)
It’s nowhere close to the python version debacle that I first came across back in 2012, which was already years old. Vue v3 is very new if not bleeding edge. And there are polyfills for new v3 features like the Composition API[0].
Re: Vue 3.2
#143Earlier quoted context omitted.
I'm completely unqualified to offer anything. The last time I tried React was four years ago, I've never used Svelte, and I'm currently using Vue 2. Vue 3 supposedly fixed a lot of the most surprising/annoying things about Vue 2. But I'll say this. Thank goodness I don't consider myself a frontend dev. The selling point of Vue was that it's supposed to be less of a learning curve compared to React. It's "closer" to r…
The big gotcha for Vue2 was the performance when you wanted to display a list of like 10,000 things. I like to tinker with data and a lot of my day is spent on an sql prompt inside of emacs watching results sets of 1,000 rows or 50 columns just fly by so I can search them visually. Having to remember to "freeze" things for performance or create simpler "views" of the model I'm playing with is sometimes jarring.
This tripped me up recently too. Somehow I'd got it in my head that Vue (2) would selectively re-render sub-trees within a given component if no dependencies within the tree had changed. I had a table functioning as a datasheet (not even that big—about 20 columns by 100 rows) that was absolutely chugging and I couldn't work out why, because nothing within the table was changing very often. Extracted it to its own component and all the performance issues went away.
Re: Vue 3.2
#144Earlier quoted context omitted.
I think you should swap Vue with React in this take, I'd agree with you 110% if you did that. React is the most over engineered tech I've ever worked with and if it weren't for excellent IDE support a la TS etc would be a nightmare to use on a daily basis. Also Vue 3 has great support for TS, 2 not so much. I can't see myself doing any project without Vue, it's literally plug and play and by far easier to grok and us…
templates are still stringly-typed, aren't they? And that whole extra language just for templates is annoying, and unnecessary. I don't want a v-else-if="level ==== 6", because I'm going to make typos, and I want the ability to refactor code in the future without painstakingly reviewing every string in the codebase. How good is the jsx integration in practice? It's there, but the vue docs recommend against it, withou…
I agree with the template sentiment but it's really hard to defend the webs of ternary operator nests I've seen in jsx Vs v-*
Re: Vue 3.2
#145Can anyone comment on how best to use Vue 3 with TypeScript to avoid as many runtime errors as possible? I know you can use JSX/TSX with Vue but it doesn't seem a focus. I've worked on projects that use Vue 2 HTML templates + TypeScript before and a big chunk of the bugs are clustered around where TypeScript is interacting with the HTML templates.
use vue-tsc package + Volar VSCode plugin to get type checking in templates. works great!
Re: Vue 3.2
#146The js-framework-benchmark used here is really hard to run. I'm not a javascript programmer, I'm always baffled that any of the command listed in the README page always end up in error. I even re-install a new version nodejs but can't make the benchmark run.
Feel free to post any issues to the github repo and I'll try to help. Building is indeed not trivial, since there are so many languages and tools and thus builiding is currently only fully supported on linux (rather a docker linux build). With a few exceptions building on windows and OSX works.
A simple workaround is to delete the folders of those implementations that cause errors.
Re: Vue 3.2
#147In Vue 2, you'd just write this as:
Color is: {{ color }}
Simpler than this new syntax, for this particular example.
Re: Vue 3.2
#148Earlier quoted context omitted.
I moved to Vue from ~3 years of React. I've now done ~2 years of VueJS while continuing to use React in some side projects. To be quite honest, I'd probably stick with React if given the choice. My takeaway with Vue is it makes a number of choices for you out of the gate w.r.t to things like data store (Vuex) and routing (Vue-router) whereas with React you'd bolt these on yourself (i.e. mobx and found-router). I also…
I work about 80-90% with Vue 2 and 10-20% with React, so take this with salt. But, with React, I rarely find myself wondering why the component isn’t re-rendering when something changes, whereas this happens frequently with Vue. I also rarely find myself having to plan out how props will flow to state or when something needs to be a computed (or memoized) property. Things usually just kind of come together. There are…
I, similarly, work about 90% with Vue2 and 10% with React.
I have a different experience though. I generally find React pretty mysterious, with very confusingly named methods, and several generations of approaches that are completely different from each other. (React Hooks changes everything...)
I used to occasionally find situations in Vue where something wouldn't re-render, but that almost never happens anymore. The main culprits are when a component never gets mounted (because it's in a v-if), or expecting reactivity before it gets mounted.
I hate the clumsiness of React, the lack of "methods" and simple event handlers, the need to be overly verbose everywhere.
I almost never use Vuex, fwiw. I find both Redux and Vuex (which apes it) are an incredibly complicated solution to the problem, and wish there was something simpler.
Re: Vue 3.2
#149Earlier quoted context omitted.
That’s not necessarily a belief that holds true universally. Plenty of developers have found that React and JSX are two technologies that have beautifully matured outside of their initial home in the web browser ecosystem. To use your phrasing, React and JSX are always going to be there regardless of what is fashionable for them to be wrapped around.
If you mean React Native, many of those devs are now adopting Flutter fashion, at least from the iOS and Android corners of the Internet I happen to move around. Cordova => React Native => Flutter => who knows
Flutter looks very exciting, iff your team is willing to switch away from JavaScript. I’ve always been excited about Dart as a better JavaScript.
Re: Vue 3.2
#150Earlier quoted context omitted.
templates are still stringly-typed, aren't they? And that whole extra language just for templates is annoying, and unnecessary. I don't want a v-else-if="level ==== 6", because I'm going to make typos, and I want the ability to refactor code in the future without painstakingly reviewing every string in the codebase. How good is the jsx integration in practice? It's there, but the vue docs recommend against it, withou…
I agree with the template sentiment but it's really hard to defend the webs of ternary operator nests I've seen in jsx Vs v-*
You're free to use if's instead, if you prefer; that's more similar to v-if's.
I agree that ternaries aren't the prettiest of language idioms, but if clearly formatted (e.g. eslint defaults are fine), I think it's mostly a question of getting used to it. I mean, the tricky but also common && and || are almost certainly worse for this, I suppose?