top | item 39243109

(no title)

jthemenace | 2 years ago

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.

discuss

order

downsplat|2 years ago

Similar story here, we have a fairly large code base which has been continually evolved since year ~2000, with our own legacy "framework" for much of the server-side structure. Back then the forms used to reload the whole page, keeping user input and adding error messages (fun times!), then some kind of AJAX was added, where the server would send actual JS back to the client for execution. Some older pages still use jQuery.

A couple of years ago we needed to choose a way forward for new front-end dev, and we chose Vue just as Vue 3 was maturing. I didn't know much about reactive frameworks back then, so it was a bit of a hunch, but I'm very happy with how Vue3 has worked so far.

We did however do the effort of adding a build step. The site is basically multi-page, with small SPAs sitting at their own URLs for individual jobs. So we wrote a Rollup config to bundle each of the mini-SPAs into its own file, and modified the framework to add a way to configure "this page wants Vue3 and this is the path to its bundled JS". We load the main Vue script as a <script> tag of its own, instead of adding it to all the bundles, for better caching. But as far as I can tell, in this way we can use all the Vue3 niceties, including Single-File Components.