[HN Gopher] VueJS turns 10 years old
___________________________________________________________________
VueJS turns 10 years old
Author : YourCupOTea
Score : 117 points
Date : 2024-02-03 14:41 UTC (8 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| codethief wrote:
| I still don't understand why they had to introduce a proprietary
| file format. It means that, instead of being able to rely on
| existing tools for type checking & proper IDE support (like React
| does), you need custom tools for that custom file format.
| Unfortunately, developing those takes time - apparently more than
| 10 years: To this day (I set up a new Vue project just a few days
| ago) there are countless bugs in vue-tsc and Volar.
|
| What's worse, type checking was largely an afterthought in the
| development of Vue. Can we, as an industry, please finally agree
| that languages & frameworks with proper (tools for) static type
| checking are infinitely better than those without, instead of
| having to painfully re-learn that lesson time and again? Heck,
| even Python devs are using type hints these days!
| troupo wrote:
| You need custom tools for React, too. Because JSX is not valid
| JS.
|
| In most (all?) IDEs you can also tell the IDE to treat the file
| with a certain extension as written in any language
| codethief wrote:
| The translation from JSX to JS is rather easy, though. It is
| just syntactic sugar.
| ipaddr wrote:
| The class vs className breaks every css style.
| zdragnar wrote:
| It is a macro ("syntactic sugar") for JavaScript, not
| HTML.
| whizzter wrote:
| You still need a full JS(x) parser (and lexer) though since
| / symbols are contextual (as are < in JSX).
|
| / and < in operator positions becomes operators, whilst /
| in plain JS in a value position becomes the start of an
| reg-exp and < becomes the start of an JSX tag, so to handle
| it there needs to be a full parser (with a pull-lexer to
| correctly handle the contextual part) as you cannot just do
| a textual replacement due to ambiguity.
| mostlylurks wrote:
| You don't, because JSX is not required for react. This isn't
| even just a theoretical point, but something I've actually
| done in the past several times; it's very convenient to just
| try something out by throwing react into a script tag and
| then just writing a small prototype or something without
| utilizing JSX and thus avoiding the need to set up a build
| system and everything else. I would still use JSX for larger
| projects, of course, but it is mostly just a small quality-
| of-life improvement, and I'd be using react even if JSX
| didn't exist, as the actually important parts of the library
| are not about JSX.
| moritzruth wrote:
| I know you didn't explicitly say the opposite, but I want
| to point out that everything you said about React also
| works with Vue.
|
| You can use .vue files, use JSX or write the h-function
| invocations by hand. Except for SFC-support, this also
| works without a build step: https://vuejs.org/guide/quick-
| start.html#using-vue-from-cdn
| martini333 wrote:
| SFC is not required for Vue either.
| troupo wrote:
| > You don't, because JSX is not required for react.
|
| And what does this have to do with the fact that the
| absolute vast majority of react code is written with JSX
| and that you need special tools in IDEs to deal with React
| code (because regular JS tools would break)?
| 4death4 wrote:
| Typescript supports JSX out of the box. It was once true you
| need custom tools for React, but JSX has proven useful enough
| that support is provided almost anywhere you need it. Also,
| as someone else mentioned, JSX is really just syntactic sugar
| around vanilla JS, so supporting it is much easier.
| bcaxis wrote:
| I use webstorm, works pretty good out of the box. I agree that
| messing with vscode plugins isn't a great experience.
| codethief wrote:
| I moved away from JetBrains to VSCode a while ago because of
| bugs related to Vue. Now, a week ago, I moved back to
| JetBrains because of a bug in Volar. Sigh.
| Hawxy wrote:
| > What's worse, type checking was largely an afterthought in
| the development of Vue
|
| I'm not sure what you mean. For Vue 3 it was a priority and
| extensive work went into exposing types that would make it
| easier for IDE tooling to integrate. Features like the
| `defineProps` macro are specifically designed to make TS
| development easier.
| codethief wrote:
| You're proving my point.
|
| > For Vue 3 it was a priority
|
| Right, for version _3_. And type checking & IDE support
| still don't work glitch-free.
|
| > Features like the `defineProps` macro are specifically
| designed to make TS development easier.
|
| As you say, in more recent Vue versions, defineProps is a
| compiler macro, no longer something you `import [...] from
| 'vue'`. So IDE developers had to put in effort to support it.
| uallo wrote:
| > It means that, instead of being able to rely on existing
| tools for type checking & proper IDE support (like React does),
| you need custom tools for that custom file format.
|
| React has (but does not require) JSX. It introduced a new file
| format: jsx or tsx. JSX is _not_ valid JavaScript syntax.
| Hence, tooling needs explicit support for JSX. For an editor
| /IDE, that means it needs to add a relatively easy new syntax
| and a couple of custom React attributes. Obviously, there is a
| little more to add React support to an IDE, but this is the
| very first step.
|
| Vue has (but does not require) single-file components. It
| introduced a new file format: vue. Vue files _are_ already
| valid HTML syntax. For an editor /IDE, that means it does _not_
| need new syntax but only a couple of custom Vue attributes.
| Obviously, there is a little more to add Vue support to an IDE,
| but this is the very first step.
|
| PS: Vue 3 has _great_ TypeScript support.
| robertoandred wrote:
| Vue files are absolutely not valid HTML.
| uallo wrote:
| > A Vue SFC is syntactically compatible with HTML.
|
| https://vuejs.org/api/sfc-spec.html
| robertoandred wrote:
| No, Vue's template attributes are not valid html
| uallo wrote:
| Vue uses @:[]. in their attributes and these _are_ valid
| HTML attribute syntax. HTML attribute syntax only
| disallows SPACE "'>/= and some specific code points.
| Everything else _is_ valid syntax.
|
| https://vuejs.org/guide/essentials/template-syntax.html
|
| https://html.spec.whatwg.org/#attributes-2
| CharlieDigital wrote:
| Template, script, and style are all valid tags.
| codethief wrote:
| Sure but that is as helpful as saying a Word document
| (.docx) is a valid ZIP file. The tags in Vue files are
| merely containers of the actually interesting stuff.
| runarberg wrote:
| What matters for most (all?) tools is that the file is a
| valid HTML syntax. Most (all?) tools don't care if the
| document it self is valid HTML. I don't think I've used a
| single developer tool which stops working if I remove the
| <title> tag, nest <a> elements or even insert a self
| closing <div /> tag.
| habosa wrote:
| Does anyone know of a good open source syntax highlighting
| library for Vue SFC? That's my biggest issue with the file
| format (I maintain a code review tool)
| simlevesque wrote:
| You could look at the Vue SFC Playground's code, seems like
| this does what you want using monaco: https://play.vuejs.org/
| gilfoy wrote:
| > Heck, even Python devs are using type hints these days!
|
| I switch between Python and TS regularly at work, Python type
| system is honestly kind of shite compared to TS.
| evnp wrote:
| Couldn't agree more. We've been having good luck working with
| TSX-templated Vue components (using "render functions"[1])
| after getting fed up with gaps in VTI back in the day - most of
| https://radiopaper.com is built in this way and we're closing
| in on it all being so. We haven't run into any issues with
| Vue's (alleged) lack of ability to optimize TSX templates in
| certain ways as opposed to traditional Vue templates - maybe
| comes down to the nature of our use cases - but our view is
| that this trades off against many other benefits:
|
| - File extensions are all .tsx, and thus work with bog-standard
| editor tooling and syntax highlighting
|
| - We're more confident about typechecking in templates, because
| template code is 1 minor transformation away from raw
| typescript, and basic `tsc` has understood TSX well for years
| now. Up and down the component stack, it feels like we
| understand typings better without "gaps" at each template
| layer.
|
| - Scoping of values in templates is easier to understand.
| Everything you write is what it says it is, it's just
| whatever's in the same scope as the template. There are no
| transformations, no omissions of various words, no magic.
|
| - It's easier to compose templates from small easy-to-
| understand parts in the same file, without fragmenting code
| across many small components. Not everything needs to live in a
| `<template>` tag separate from your `<script>` tag.
|
| - When React folks have joined the team they've had no problem
| ramping up.
|
| - By the way, in Vue TSX you just say "class" not "className"
| which is refreshing.
|
| Feel free to email me at evan at radiopaper dot com if any of
| this interests you - we're currently working on expanding the
| team and looking for like-minded people interested in
| contributing.
|
| [1] https://vuejs.org/guide/extras/render-function.html
| tgsovlerkhgsel wrote:
| I started using VueJS when I got thrown off the deprecation
| treadmill by Angular.
|
| Regardless of whether something is a hobby project that you want
| to only touch a couple times a year or a big project with dozens
| of developers, having your platform deprecated under your feet
| and being forced to do migration work sucks.
|
| Vue is now on version 3 within 10 years. That means anyone who
| relied on v1 has had their work churned away under their feet,
| twice.
| ceejayoz wrote:
| We transitioned from Vue v0.14 to v2 to v3 without all that
| much code churn. Most of the work was a couple third-party
| components that got abandoned in the 2 --> 3 switch.
|
| A couple major version upgrades in a decade seems reasonable.
| PaulRobinson wrote:
| I was around for the first Angular deprecation treadmill, and
| it was jarring.
|
| I was thinking about doing some stuff for a hobby project
| recently and as a mostly back-end engineer, I am very out of
| date for most front-end code. I did a scout around, and didn't
| feel too impressed.
|
| Finally last week I was thinking "I wonder what happened to
| jQuery", and there it was. Just as it ever was. Updated,
| freshened up, but completely recognisable and completely
| usable.
|
| Is it new and shiny and full of awesome features? No. Do I
| understand it? Yes. Are there plugins for most things I need?
| Sure.
|
| I feel old, but I'd rather make progress with something
| unfashionable than have to deal with deprecation and learning
| curves with something fashionable.
| Hasu wrote:
| I'm genuinely curious - what features does jQuery have that
| make it better than modern vanilla JS? Back in the day the
| vanilla DOM APIs were bad, so jQuery was great, but I haven't
| felt the need to reach for it in ages.
| ipaddr wrote:
| Better and shorter syntax, plugins, ecosystem.
|
| Hide Show
|
| ```
|
| $(".box").hide();
|
| $(".box").show();
|
| vs
|
| document.querySelector(".box").style.display = "none";
|
| document.querySelector(".box").style.display = "block";
|
| ``` Both work. The first is more clear
| jacobr wrote:
| ```
|
| const $ = document.querySelector.bind(document);
|
| $('.box').hidden = true;
|
| $('.box').hidden = false;
|
| ```
| troupo wrote:
| 1. Not really.
|
| jQuery is designed not to fail. So if there's no `.box`
| on the page, jQuery will not do anything.
|
| `querySelector` may return null, so `$('.box').hidden`
| will hard break your page if you're not careful enough
|
| 2. `$('.box').hide()` is just one such example.
|
| The hilarious https://youmightnotneedjquery.com/ shows
| that jQuery remains more consistent, concise, and
| composable than most things in modern browser APIs
| ipaddr wrote:
| jQuery still works great
| demondemidi wrote:
| It certainly does but only for very flat designs. I was in
| jQuery camp for a solid 15 years (2000~2015) but once you
| get a taste of reactive design, it physically hurts to go
| back to jQuery. For me, that is.
| 1123581321 wrote:
| I would look around more. You might like one of the small
| reactive frameworks if you find the large ecosystem of React
| and Vue off-putting. My last jQuery app was several years
| ago, when I realized I was just maintaining a slower
| reimplementation of a reactive framework. These are mature
| technologies now that quickly save time and prevent headaches
| down the road. jQuery's best lessons have been absorbed into
| both the reactive frameworks and native JS and you can alias
| the handful of selectors you're used to.
|
| For development, browsers and version managers/containers are
| stable enough that you won't be on a deprecation treadmill.
| Any pressure would come from including other people on the
| project, which you'd get even more of with jQuery.
|
| I appreciate the 'do what works' mindset quite a bit but I
| hope you'll give a modern reactive framework or library a
| try; I'm glad I made the change.
| MatekCopatek wrote:
| As someone who started using Vue before 1.0, I find that
| characterization unfair. The overall API didn't change much
| from 1 to 2.
|
| 3 was initially going to be a big change, but after a lot of
| community resistance, they decided to make the reworked API
| entirely optional so people wouldn't be forced to make changes.
| AFAIK this is still the case and the classic variant (Options
| API) is still fully supported.
| tinco wrote:
| I fell for a feint though. Reading their docs it seemed like
| they were going to go in the direction of class components
| with attributes (class decorators). So we built our app for
| that, thinking we'd be future proof, but alas the community
| went 180 degrees the other way, and our Vue 2 app became
| super hard to upgrade to Vue 3.
| simultsop wrote:
| Without more context can't comment on your upgrade process.
| But as others stated above, there's not much difference
| betweeb 2 and 3, except you do not get composition api on a
| v2 project, while you can use composables but can't go full
| composition api and have to stick to options api. Other
| than that most of v2 code would work on v3.
| SparkyMcUnicorn wrote:
| This isn't correct. I'm using the composition API on all
| my Vue 2 projects. It's even baked into 2.7.
|
| https://github.com/vuejs/composition-api
| tinco wrote:
| Yeah our path to upgrade is going component by component
| switching them to compositional style.
| joshstrange wrote:
| They did drop class components though which I had heavily
| used for both professional and personal projects. I still
| haven't gone through the process of upgrading one of those
| but I've written a new project in vue 3 with the composition
| API and I like it overall I just hate that I have to switch
| from class components
| cjblomqvist wrote:
| We have a 100kloc codebase and migrated 2->3 + replaced our
| whole build stack (webpack -> vite) with a few dev days of
| effort (mostly on SSR stuff). It hasn't (at least not
| negatively) our general velocity at all.
|
| A totally different thing than moving from Angular 1 -> 2 for
| example.
| aniforprez wrote:
| Was an Angular 1 -> 2 even possible? If I remember correctly,
| they were one of the first big open source projects to go all
| in on Typescript and even the fundamental way that the
| rerender and state changes were tracked were completely
| different. I worked on an app on AngularJS and when asked for
| an assessment on a migration, it felt clear to me that it
| would require a complete rewrite. Even the tooling was
| totally different
| tylerchurch wrote:
| It was a complete rewrite. Angular 1 vs. 2 share nothing
| besides name and some basic concepts. The actual code and
| tooling was completely separate.
| ipaddr wrote:
| That opening is what react used to become what it is today.
| With the 1 -> 2 no upgrade path it forced a rewrite and
| many left to react and never came back.
| mushufasa wrote:
| We're about to need to do the same thing with similarly sized
| codebase. Would love to hear your story. Did you find any
| migration tooling to help? Would be happy to DM to chat as
| well.
|
| One of our issues is that we've used some component
| frameworks that also need to be migrated.
| CharlesW wrote:
| > _Did you find any migration tooling to help?_
|
| With the caveat that I don't do software engineering
| professionally, I recently migrated a personal Vue
| 1/JavaScript project to Vue 3/TypeScript, and it was mostly
| painless. There's a migration guide1, and Phind and Copilot
| were helpful.
|
| 1 https://v3-migration.vuejs.org/migration-build.html
| whstl wrote:
| I did it to a similarly sized codebase too. Vue itself was
| painless.
|
| I also migrated our component framework, from Buefy to
| Oruga. Some string replacement to change component
| prefixes, then Typescript to help catch incorrect
| properties. I might have fixed several bugs in the process
| thanks to Typescript working better with Oruga. The only
| real tricky part was converting customized CSS, which was A
| LOT in our case, but Oruga provides a better way of
| overriding CSS, so it was worth the time.
|
| Took about 2 days of me doing pure coding with a blocked
| calendar, plus a third day for testing and code reviews by
| the rest of the team.
| cjblomqvist wrote:
| Basically, see other comments. We simply followed the
| migration guide. Very painless. We use few external libs,
| sa that helped a lot. You can find me on LinkedIn with the
| same username as here for DM.
| yagodragon wrote:
| Going through the same migration from nuxt 2 to nuxt 3. Can
| you share more details? Did you also move from vuex to pinia
| ? If so, how did you manage the API change (dispatch, commit)
| scattered through the codebase. I'd love to learn more
| cjblomqvist wrote:
| We had a homegrown store lib that was very similar to
| pinia, so migration was basically minor renaming.
|
| Like others have mentioned, the biggest fear was other libs
| we used. We are quite conservative with that though, so
| want a big deal.
| joshstrange wrote:
| I'd love to hear if anyone has done this migrating from vue 2
| with class components. There doesn't seem to be as nice of an
| upgrade path from what I can tell.
| whimsicalism wrote:
| this seems reasonable to me
| demondemidi wrote:
| I'm still on Vue2 for my personal projects because the
| migration path is painful. Someday I'll get to 3!!!
| DanHulton wrote:
| "Version 3 within 10 years" is, in this industry, glacial pace.
|
| And also, the work required to do those upgrades has always
| been relatively minimal, with a backwards path for stuff you're
| not ready to convert yet, but real tangible benefits for the
| stuff you are. I still have a few projects that are a mix of
| Vue 2/3 - new stuff written in 3 because it's nicer, older
| components not rewritten yet because they haven't needed to be
| touched and just still work.
| monero-xmr wrote:
| I dislike react and liked vue. However I'm on the svelte
| bandwagon now, which is similar to vue but improved. Basically
| sveltekit makes a lot of opinionated decisions for you but those
| are all good places to have opinions.
| agumonkey wrote:
| What i liked in things like vue, is that they get you to
| prototype things quickly with a thin layer of conventions that
| guide you softly and avoid creating a mess. Even if I stopped
| using vue (went to backend) I still appreciated the voyage /
| lesson.
| nlh wrote:
| +1 to Svelte. I used to work in Vue a lot but something about
| Svelte clicked so much better for me. It's so good that when
| new fancy reactive frameworks come around I don't even bother
| to get distracted - not even for a week (LOL) ;)
|
| I'm curious to see how Svelte v5 takes hold. I get the
| motivation behind why it's been created, but it does
| dramatically change the syntax to make things feel less
| "Svelty".
|
| It's an interesting side-effect of a maturing project. A lot of
| the things that make Svelte <=4 enjoyable is how approachable
| and logical it is. I understand how more complex projects need
| more ability to split up large components, etc., so Svelte 5
| logically makes sense, but it loses some of the charm and
| simplicity of the original.
| code_runner wrote:
| I really enjoyed vue for a large project back in the day. I
| seemed to have loved everything that everyone else here
| disliked... which is sometimes par for the course on HN.
|
| My project pre-dated the composition API and some other bells and
| whistles that I've never looked into since leaving FE projects...
| but IMO, a really good framework with a good community and lots
| of resources to learn.
| uallo wrote:
| I like Vue a lot. It has a terrific documentation, good official
| --but mostly optional--tooling (Volar, Router, Pinia, Vite),
| built-in component-scoped styling, fine-grained updates (like
| signals, but already before it was cool), generates small
| bundles, their TypeScript support is great, their IDE support is
| great, single-file components are a blast to work with, and much
| more. What I also like is that their decisions are not rushed.
| They observe other frameworks and copy the best ideas from them
| but address the learnings and add even better versions of these
| features into Vue. They are rarely the first, but often (imho)
| the best.
|
| Thanks to all contributors and happy birthday!
| timetraveller26 wrote:
| "Vue.js: JavaScript MVVM made simple (2014)"
| https://news.ycombinator.com/item?id=7169288 (Referenced in
| tweet)
| coding123 wrote:
| To me Vue is just a maintained version of angular 1
| huskyr wrote:
| ...without the cruft and needless complexity of Angular 1 ;)
| whizzter wrote:
| It got so much right from the start, looking at Angular 2 just
| made me throw up my hands.
|
| But saying "just" is unfair to Vue, it's a big upgrade thanks
| to the internal mechanics as it solved a lot of brittle and
| error prone ceremony associated with writing Angular that just
| went away with the same elegant style of templating.
| synergy20 wrote:
| This is an amazing project, it tells yet another story how one
| guy can start a project ended up challenging big companies like
| Google(Angular) and Meta(React).
|
| While React is adding all those complexity by SSR and server
| component etc these days, Vuejs separates them wisely, if you
| need just the original SPA, use vuejs as-is, if you want SSR, add
| Nuxt.
|
| I am moving back from React to Vuejs after realizing how heavily
| React is nowadays affected by VC company Vercel, which has its
| own agenda of SSR-first(Next.js) and make React even further
| complicated, Vercel hijacked React in my opinion and made it no
| longer a "neutral" OSS project, so long, thanks for all the fish.
|
| On the same note, Vercel also bought up Svelte and made it SSR
| first.
|
| If you just need SPA and has no need for SSR, which made frontend
| even more complex, go with Vuejs.
| todd3834 wrote:
| I build React apps without SSR all the time. What has changed
| in React besides optional support for it?
| jgalt212 wrote:
| If the preponderance the documentation and examples favor
| SSR, I can see what the poster is speaking of.
| impulser_ wrote:
| Svelte is not SSR first. Svelte has nothing to do with the
| server. There is no server related code in Svelte. Svelte is a
| UI library/framework/language w.e you want to call it.
|
| SvelteKit can be bundled with server code, but it's just as
| easy to bundle it without any server code. SvelteKit is
| essentially just a Vite plugin.
|
| You can add adapter-static and have to bundled as an SPA and
| not change anything with you code as long as your not using
| .server.js files which are files meant to protect server code
| from not being bundled with the client.
| qudat wrote:
| You haven't described anything different from what the OP is
| saying: the main dev behind svelte now works for a company
| that wants you to use SSR for all your projects. That
| absolutely impacts feature development to favor sveltekit.
| The same thing is happening with react.
|
| The same thing is happening with deno as well: most active
| dev is with deno deploy.
|
| VC has infiltrated open source development and is driving how
| features are built. Not saying it's necessarily bad but it
| does change the incentive structure.
| impulser_ wrote:
| What feature was added to SvelteKit on the behave of
| Vercel?
| mp05 wrote:
| I don't see where the person said that some feature was
| added to SvelteKit on behalf of Vercel.
| synergy20 wrote:
| Svelte has no routing for client-rendering, and itself
| recommends everyone to just use SvelteKit as boilerplate,
| which is SSR-first.
|
| I spent two months with SvelteKit for a SPA project,it did
| not fly, the SSR-first (e.g. documentation etc) made CSR-SPA
| a second class citizen plus added unnecessary burden for
| those who does not need SSR, no it's not as easy as just
| "setting this flag you will be golden for CSR".
|
| If I need SSR sometime, I might as well just do Django,
| Rails, Laravel etc which are solid. Please give me a true SPA
| as it used to be, and make SSR optional instead of the
| default.
| impulser_ wrote:
| SvelteKit is the "router".
|
| We use SvelteKit for a internal application that we embed
| into a Go binary. It as simple as adding adapter-static as
| the adapter and not using .server files.
|
| You can use SvelteKit the exact same way as the API for
| server and client are nearly the same. Load function on the
| server work the same as the Load function on the client
| expect for where they are called.
|
| What problems did you have?
| gherkinnn wrote:
| React with SSR is fine. Astro and Remix both do it well and
| it's effortless.
|
| Vercel pushing Next's terrible app router has a VC stink to it.
| That's the only way I can explain their downright awful
| solutions.
| bdcravens wrote:
| From what I recall, most of the early development was funded
| due to Patreon, and if you looked at the list of donors,
| something like 75% of the money came from a few large
| companies.
| samwillis wrote:
| I think it's a shame the reactivity/signals system from Vue 3
| wasn't broken out as a separate project under a different name.
| They had so much success with building Vite as a separate
| project, and the reactivity system they built for Vue 3 is so
| good it warrants the same attention.
|
| It can, and is, used outside of Vue, see Alpine.js, but it's
| adoption would be so much greater if it was packaged under its
| own name.
|
| There is this project that even combines it with react:
| https://github.com/antfu/reactivue.
|
| I wish we had slightly looser compiling between templating and
| reactivity systems...
| Rapzid wrote:
| I agree and that's one reason I've stuck with MobX. Works with
| React, Vue, Solid, and even mixed solutions. Heck, I've bridged
| it with backbone codebases..
| y-c-o-m-b wrote:
| I've been in FAANG for a couple of years now and stuck in React
| world unfortunately. Prior to that I had to use Angular, which
| imo was even worse. I've had a couple of short opportunities to
| use Vue professionally in an enterprise application though and
| damn I loved every second of it. Vue is still my favorite by far.
| It's just so elegant with its simplicity, it allows me to
| actually focus on the app and not any bullshit cognitive overhead
| dealing with state or weird incoherent syntax (looking at you,
| Angular). I wish there was a larger adoption of Vue.
| rpmisms wrote:
| Thanks for 10 years of opinionated, efficient UI dev!
| jthemenace wrote:
| We have a large legacy PHP code base originally using "xajax" in
| many places for asynchronous parts of the UI. We've pretty much
| got somewhat of our own "framework" and any sort of re-write is
| absolutely out of the question. We have been slowing replacing
| xajax with VueJS via a script tag and it's been working great for
| us as a modern / supported alternative to xajax . There are
| certain VueJS niceties we can't take advantage of because of the
| script tag approach, but that hasn't been a big deal.
| alexcroox wrote:
| What I love about Vue/Nuxt devs are not only the powerful tooling
| they create, but the way they build it so any framework can
| utilise it. Biggest examples are Vite, Unjs, Nitro. Plus I love
| the way they think about providing so much flexibility with
| deployments. Want to deploy your SSR Nuxt app to Cloudflare
| workers? It's a 1 line config change in the Nitro config
___________________________________________________________________
(page generated 2024-02-03 23:02 UTC)