Damn you Vue.js... Vue warn: Unknown custom element

Wow, sounds like you dropped $100 on something you knew nothing about. The Vue aspect of Spark was not kept secret. It was discussed for months leading up to release.

I'm not sure how the marketing could have been any clearer, given Vue is listed as one of the features of Spark.

The primary goal behind Spark was to provide the boilerplate for users, teams, signup, subscriptions, etc. allowing you to focus on building your business-specific stuff.

Mixing frontend frameworks is always going to be a mess. Perhaps instead of trying to force Angular into a Vue frontend, you spend a little time trying to convert your frontend concerns to Vue. I think you'll find it simpler a task than trying to mix and match the two. You may even end up liking Vue.

Overall, Spark is there to help you get up and running from scratch rather than trying to merge an existing project but if you choose to do that, Spark is opinionated about how it does things. If that's not what you're after, then perhaps Spark isn't the right tool for your particular use case.

Angular and React may be the bee's knees today, but they weren't always. They may not always be in the future. As long as the reasonably significant Laravel community is backing in Vue, I don't think there'll be too many issues with it. I wouldn't hold my breath for Spark 2.0 dropping JS entirely; if that's what you're hoping for, I think you've misunderstood the purpose of it.

I don't agree or disagree with the original poster - I have only owned a license to Spark for about a week (but have been dev'ing in Laravel for years). I purchased it largely to learn from, and also with some hope that it would help get apps out the door.

However I think it's a little unfair on the original poster to say he knew nothing about it as VueJS was discussed for months prior. I barely use twitter, and barely use these forums, so I'm not really keen to trawl a social feed to get that information. My decision to purchase was based on the information presented on spark.laravel in combination with a deep respect for Taylor.

"Spark's client-side is powered by Vue.js, a beautiful JavaScript framework that makes the front-end a joy. Want a different JavaScript framework to power your application? You can do that too!"

The above being from spark.laravel in regards to VueJS. So if the original poster is feeling difficulty in implementing another framework besides VueJS, is it ok to suggest that they dropped money on something they didn't understand or research? We don't know the original posters particular case, and simply subbing out an entire framework might not make sense - his workplace may have dozens of libraries already in place, integrated and used in other parts of the business, who knows? I certainly don't.

I absolutely agree that Angular/React are the bee's knees today, and everyone knows that it doesn't last, especially in FE land - and this would be equally applied to all major frameworks, VueJS included - despite having been backed by Laravel devs.

Again, I don't really participate in the forums here, but we have to be careful as a community not to instantly knock people who happen to go against the trend. I have utmost respect for Laravel and Taylor, but if decisions can't be questioned we are actually stifling the future of the Laravel ecosystem.

Did the original poster approach his feedback in the right way, possibly not. But should his situation be met with an open ear? In my opinion, yes I think so.

You can reimplement the views completely without VueJS using your own framework of choice. VueJS is just there as a placeholder. Reimplementing the views will surely take time but if you look at it, the boilerplate cannot satisfy everyone and every use case of your apps, so it will need some kind of modification anyway.

So, I should start by saying I know better to write forum posts when I'm frustrated, I should sit back and chill. Seconds after posting I'm thinking, why did I just do that, but what is done is done... maybe if I stay quiet this post will go away... haha, not. So I apologize for sounding so snarky. I'm a huge Laravel/Taylor/Laracasts/Way fanboy. Huge... listen to all the podcasts, read everything I can, a huge fan... I wish Laravel was a part of my full-time job, but I'm a full-time front end developer in a C# shop and Laravel is used for personal projects and freelance.

I did know Spark was using Vue, that was not unknown to me. However, I was really envisioning it being app sugar and I didn't think I was going to essentially be confined to it unless I took great effort to decouple it. I bought Spark specifically to launch my app quickly without having to build out everything Spark aims to solve. It's a multi-tenant app for whatever that is worth. Outside of the competeing Javascript framework issues, it's working out.

However, I took the following to heart from the Spark sales page...

Vue The Future Spark's client-side is powered by Vue.js, a beautiful JavaScript framework that makes the front-end a joy. Want a different JavaScript framework to power your application? You can do that too!

I really wish there was some documentation to doing that. I wonder how far that capability was truly investigated.

Unless you build out a second dashboard for your app, which I'm considering, you can't simply shoe horn in another framework. There may be repercusions... nevermind routing issues. Which tool owns the routing?

So while I feel a little like a chump for coming off as a hot head, I stand by my personal opinion that Spark would have been best served as a Laravel/backend layer solution. I'm definetely frustrated (with myself in the end I guess) because I made a bad call and decided to wait months for Spark instead of building out the subscriptions myself. I actually already have an implementation of that in an old Code Igniter project, oh the irony.

That global spark object in the HTML is feeling kind of gross. If you find yourself having to abide by one of those security audits that system admins like to run, that global object script in your HTML source forces you to ratchet down your security. Specifically I'm talking about the Content-Security-Policy headers. For the 'script-src' option you will need to add 'unsafe-eval' and 'unsafe-inline' to the header... which I'm getting push back on at the moment from an unrelated C#/Angular project. Maybe it's not a big deal, our admins tend to err on the side of stricter by default.

Anyways, thanks for hearing me out.

My exact thoughts. As Spark is supposed to be starting point for projects, choosing the front-end framework for someone else's project is just a bad idea. Spark should have come with plain blade templates.

I saw this https://github.com/laravel/spark/issues/166 issue at GitHub and it seems like there is some sort of support for Spark without Vue.js, but it's undocumented and I haven't had time to figure it out yet...