Really wish Spark was straight Laravel/PHP, no VueJS!

@skattabrain not really. I believe Taylor mentioned that the only part in the application that requires Vue is the settings page.

You can just remove any other Vue component and change your views HTML markup. You can then just use Angular

Yeah, I'm fighting this. I'm reversing my existing app into a new spark install, and just about to remove Vue for client functionality as I'm going nuts with part of the template! (I have a sidebar that as soon as I enable the spark-app stuff, poof, sidebar gone!). Then the settings will be fine with Vue but won't fit with template!!

I'm probably spending as much time making it fit as I would have done rolling the basic payment stuff with Cashier! I "assumed" Spark would have been more modular.

However, like any crossword puzzle, once I work out the secret sauce I'm sure it will all fit! (I hope!)

I'm kind of at the point of do I / don't I with Spark. I come from a (somewhat recent) React background.

I assume I can just use react for all customer facing stuff - but its hard to find that out without purchasing first. I'd be very interested to hear about people have been going without Vue in Spark

Vue is kind of everywhere in the "logged-in" area. It does not seem practical at all to try to remove it there.

If there is anything you want to customize in that regard you will have to deal with Vue (and I bet you will want to change things there).

Hmm - I think I am happy to leave the settings page alone - it's more the "content pages". Basically I am building out a site which is like a lightweight LMS - and so I have already built out a lot of the quizes and stuff in react.

So ideally those pages aren't bound to vuejs. I'm sure they wouldn't be.

Well, here's the thing... the settings panel for instance... it's great, it works awesome and it's clean. Now try adding some fields, or maybe a new panel. It's a perfect spot to add some of your app's settings, but it's not straight forward and you will have to use Vue for this... your routing etc.

Taylor is by far a better developer than I am, by a long shot, but I find his JS overly complicated. If I tried Spark before I had to buy it, I wouldn't have bought it. I bought it so I'm going to make it work. By the time I'm done I might love it... but if you know Angular or React well there is not a compelling enough reason to use Vue IMO.

Maybe the next project will go smoother and faster, but the way the front end was developed has slowed me right down. If I could go back in time, I'd use Angular and work directly with Cashier and the Stripe API.

Of course with Spark you do get a lot of cool stuff too... notifications, kiosk, teams... etc.

I love Laravel and love all of Taylor's work, it's just not working out like I hoped. Without a demo, you have to take a leap of faith.

Side note - Should I be feeling icky about editing files inside a "vendor" directory? It's freaking me out editing the files inside "/resources/views/vendor/spark"

@cjke7777 - sounds like where I thought I was... but there are a few global settings that I want attached to the user profile, I will have to use Vue for this. Really... software like this needs to be evaluated before purchasing.

Thanks @stattabrain for the detailed response. I am literally on the purchase screen now, and you raise valid points.

I have just emailed support to request a list of functionality that would be lost if Vuejs wasn't embraced by a project. To be honest I might purchase just to see how he has set up the various pieces like JWT and whatnot.

The dollar value doesn't really bother me, I'd pay $100 for a good tech book, and this is above and beyond that, I just don't want to waste time.

You can't decouple Vue from Spark. If you did, you would be creating so much busy work it would defeat the purpose of buying Spark... which is to quickly get your app live.

My last was maybe misrepresented. I don't want to remove Vuejs, I just want to use react for the more customer facing content. But I think your above above points still are valid and make sense.

Agree about the app going live quickly. I think its also about not doing the stuff that isn't unique to your site - no point of me rigging up logins and billing if its been done 1000's of times before. I should focus on what makes my app a pretty snowflake of uniqueness.

Another minor critique I have is the CSS.

Seeing this is all Bootstrap anyways, I'd prefer little to no custom CSS as it's simply not necessary. If it was vanilla Bootstrap, customizing Spark to look like your app would be much easier.

I just purchased it, so we shall see. Worst case I get to see how Taylor approaches app dev with Laravel.

I'm not sure I understand about the CSS, are you saying you can't create your own styles?

No, that's not the problem. The problem is you now have to overwrite Spark's styles versus overwriting vanilla Bootstrap (which we probably all have been doing for many years now). I should say this is only a minor annoyance for me.

Ok thanks for explaining. I will post an update here with how I went with React integration Thanks

Sorry if I sound like a crank!

Usually I drink the Laravel kool-aid all day long because it's awesome, but where Spark is and what I thought it was aren't the same. Maybe I'm just pissy about learning yet another front-end workflow under time constraints.

That's ok. We all have frustrations, goodluck with your app and timelines

As @skattabrain discusses earlier, it does appear the css mods are where I'm crashing and burning badly. It appears my template that I'm trying to integrate makes the sidebar dominant with the navbar within (so to speak). However soon as try to integrate everything goes to hell in a handbasket. I have no issues with Vue etc.

I'm thinking of using a new template but again, not sure if I'm heading into ever decreasing circles. I love the concept of Spark, but right now not sure it's loving me ! I'm close to shelving Spark for now & carrying on with plain old Cashier integration. I'll save my license for a new project one-day!

@skattabrain I'm with you 100% on this, and for others that have mentioned, no VueJS isn't just a setting/admin/logged in page thing. Its everywhere. Its on some of the most important parts of the app, i.e., the registration page is your selling page, with your plan details.

TL;DR – The biggest gripe is the lack of VueJS documentation for Taylor's version of VueJS implementation.

Do I mind it, no. Do I mind the lack of VueJS documentation, not really.

Here's why, Taylor's support is amazing, he recently added a two part series on customizing the registration page (however he did leave some key sections out, migrations, I was able to get this working well.

Do I mind all the JS, yes. I honestly purchased Spark expecting it to be a Laravel/PHP app. Rather its a Laravel/VueJS app. Recently, I'm spending more time learning "his" way of VueJS. As he does not implement it the same as the VueJS docs do.

Regardless, I have hope that as Spark matures, Taylor will transition from doing PHP/Laravel examples, and possibly move into how to do VueJS in Spark. His other services, Forge, and Enovyer, which I'm also using, are amazing, and well thought out. And by using those, I can see a strong desire to use a robust JS framework.

Hoping for good things to come. Spark is only a few months old.

P.S., @skattabrain, yes, customize them in /vendor does seem odd, but they're actually overriding the ones found in /spark/resources/, also you can run php artisan vendor:publish which will copy them over for customizations.

@cjke7777 you can't really replace VueJS, I did a quick grep/find in views for @{{, which is what Blade uses to handle JS variables.

183 matches across 46 files

Granted many of these are the admin pages.

What I dislike about vue - like many js frameworks - is you have to put custom syntax in your html. I don't understand why so many js framework goes this way whereas you can just use js functions to declare the bindings and everything.

I don't want to turn this into a Vue v other framework debate, however I agree with @pmall. It's basically the reason I became a React fanboy - you are bringing HTML into JS, not JS into HTML.

Considering JS is an actually language with language constructs like ifs, loops, etc it feels more natural to let it handle the heavy lifting.

@zanematthew - You can replace VUE, just for some it may not be worth it...

I am more then half done preparing a update for my app that will 100% remove VUE. Yes i had to rewrite some stuff, but to say it cannot be done is very misleading and false.

Just wanted to clear that.

@zerohour Did you replace VUE from the admin pages? Or just on the front-end? If so was it daunting?

@zanematthew - Just front end for now.. I actually already have my own Admin are so I don't even use the kiosk. And it wasn't so much daunting as was just a little extra work.

Just a little time, patience and coffee or tea :D

@zerohour - I didn't mean to be dismissive of Taylor's implementation or Vue itself nor did I intent that one couldn't decouple them, but rather why would you. I had a bad couple days of not fast enough progress and had some extreme "you told us this Spark stuff was going to get things launched fast" being thrown at me.

I guess I take it for granted that just about anything is possible, so yes... looks like we can de-couple Vue. A sans-JS Spark would still be great IMO. But to my point... now that you have done that, would you do it again or just use Cashier?

Regarding using {{ }} - I have no problem with it really, feels quite natural to me... much better than extra span's or div's to me. When you are using templates like that, I think the main use case is Apps, not SE readable pages anyways. I like the workflow.

Outside that... I don't get the mustache hate. I'll get deeper into React at some point... having invested some time in grokking Angular I'm not eager to move just yet. I've tried React and it is indeed cool. I still don't have a need to use it as Angular ticks the boxes for me... plus it's a framework. Which is what I want, which is why I use Laravel.

I might be wrong but with React you have to be in the know regarding which external libraries to pull in that aren't made by the React team.

Had I considered React more seriously when I was dealing with the early days on ng1, I might have already jumped ship, but my teeth are already cut. Who knows though... ng2 might be a flop. Time will tell.

@skattabrain - As a back end developer Vue was new ground for me.. I do not like dealing with anything with a front end interface, there's a specific set of people who do this.. and I am always glad to hire out for this when time is right.

IMO its extra unnecessary steps to output data. If i knew all this, I would have just done it all myself with cashier.

I bought Spark on day 1. I've decided to use either Laracogs or laravel-5-boilerplate for now as I don't have much front-end experience, and the whole Vue oriented development of Spark was a bit overwhelming for me.

It will be really awesome when Jeffrey releases his series around Spark + Vue though. Can't wait for it :)

I personally dropped Spark as the core of my app and just went back to L5.2. I have kept it installed as a seperate, no changes, vagrant install purely as reference. Along the lines of "hmm, how did they implement JWT in Spark?" - look through it, learn, then jump back to my own application.

Hey @cjke7777 You could do the same thing with Laracogs and put in PRs if you want anything special added to the package :) The nicest part is the way it adds components to a vanilla L5.2 app means you can just as easily undo what it adds, or add it then customize it. The best part is the magic CRUD generator :) I'm biased though its my baby. That being said I like that Otwell is introducing new/ other concepts to the community.

@mlantz I have been hearing really good things about Laracogs, and have been checking out the site. I like that it's an passive way to add functionality, in a build it up piece by piece rather than the whole hog - the word "cog" is definitely apt.