Starting off with a SPA using ang/ember is a bad idea for version 1

Salman · January 7, 2015, 10:45pm

With all the hype around SPA (single page applications) I always think to myself that people who start off going with a very fancy UI using ember/angular are really shooting themselves in the foot because the amount of time it takes to build a SPA is orders of magnitude higher than going with html with a sprinkle of jquery.

Do you guys agree? The only time I would say go with a SPA is if your major differentiator is going to be a better UI experience and with that you feel going with a SPA is the killer feature.

Once you have traction and paying customers, you can then look at the pros/cons of going with improving your UI.

craigvn · January 7, 2015, 11:56pm

I would say it depends on how much experience you have with the tools and how much longer you think it will take. You need to remember changing later will be much more difficult.

johnf · January 8, 2015, 2:44am

Did you mean to use “orders” as in the plural here?

Are you saying that if I think a app will take 400 hours it will actually take 40,000 (2 orders of magnitude bigger) hours at the very least?

I’m on my 4th angular project, 3rd saas application, and 2nd 100% full spa app from a combination of a full time job, freelancing and soloprenuering. I’ve also written tons of jquery/jquery UI and knockout and fiddled with react and ember. At this point you could say I’m very proficient at SPA’ing.

The big benefit to SPAs is anything more complicated than basic CRUD grids and forms becomes so much easier to do without writing bespoke jquery or javascript. Anything wizardy is so smooth with a SPA app over plain old server refreshing.

The con of course is you have to write a little more code… well that depends… hmm. Actually it could be less. You know all that code you have to write when a user submits a form and validation triggers and you have to send back the form with a message and oh god I’m already bored now. Well that with a SPA is so much easier.

Actually you know what, who cares if its 20% slower of even 50%. SPA’s are slick apps which are fun to write.

I should write about this angle more, but in general I think we, as a bootstrapper community, are making technical decisions trying to optimize some edge case that could have a negative effect on the mental health of the bootstrapping programmer.

Look if you want to learn a new technology and be super cool about your tech stack and make a full SPA because and that will make you feel GOOD about what you are working on BUT it will take twice as long, well fuck it, take twice as long. If you’re a decent programmer you are not going to be heading towards financial oblivion and don’t have any deadlines you have to make. Well thats assuming you don’t quit your job way too early like I did, whoops…

Optimize the beginning stages of a saas for personal happiness. Once you have customers emailing you dumb support questions and your growth rate is a half a point of nothing and you have no idea why you just spend a year of your life building some glorified todo list thing you can still look back at the code and say “man, I learned a lot and that was FUN”.

Building the product is the funnest part of SAAS, why would you rush that just so you can get to the un-fun parts sooner?

Salman · January 8, 2015, 3:37am

I understand what you are saying, but you also agreed with my points
Some people want to combine having fun and making a profit, and the faster you can validate your idea the better. If my premise of it taking longer (maybe not orders of magnitude, but I would say it could take 2-3x longer) is correct, then it might not be a good idea after all.

danielstudds · January 8, 2015, 10:46am

I’m way faster in angular than anything else, because that’s where I’ve spent all my time for the past two years. I think this is very much a matter of what tools you’re most familiar with.

johnf · January 8, 2015, 12:33pm

I don’t think I ever said it would take longer, just that it doesn’t matter if it did.

Is this your first saas?

You should “validate” (which is one of those “bootstrapper ecosystem” words we use before we figured out “validation” has been called market research for hundreds of years) before you even write a line of code.

Generally speaking you should figure out of if you have a market, and then if you can reach that market and finally get that market to take an action (sign up for a newsletter) before you start developing anything.

davidw · January 8, 2015, 2:25pm

You’re not neglecting to do that on the server as well as the client, right? It seems to me this kind of application pretty much forces you to duplicate that work, or keep it on the server in any case, because you can’t really trust what’s coming from the client.

Salman · January 8, 2015, 4:08pm

There are multiple areas where your application gets complicated. Just take a look at the source code for discourse, specifically the UI side of things. You have hundreds of javascript files, controllers, views, components, libraries, etc. etc. Ofcourse there are advantages to all of this, but it sure does complicate the application. On the server side you have to architecture things differently also.

I do agree there is allot of benefit in a SPA, it also helps you be mobile friendly since your back-end is pretty much an API.

But the reality of it is, most apps that I have seen did not start with a SPA (and never migrated to one either). I remember reading a post by the developer who made cheddarapp and he regretted going with backbone b/c it took much longer to add new features.

I guess what I am saying is, as a developer I also get caught up in the ‘whats new’ and cool and spend/waste allot of time learning and adapting but at the end of the day it is about shipping a product and more often that not having a SPA isn’t a deal breaker. What I am arguing is you should think long and hard about going that route, especially for version 1.

I am currently getting into angular and I just thought I would ask others if they feel the same in case I make the mistake myself (or get convinced it is a good idea)

johnf · January 8, 2015, 5:37pm

That whole quote was about the code that synchronizes a virgin form with what the user enters and ties all that up with the validation messages don’t have to be written because you never actually leave the form via post submission. Validation can still occur server side but all you have to return are the validation messages and SPA framework will tie everything together.

Well right, backbone is pretty much a framework for writing your own SPA framework.

Haha, so wouldn’t the fact you are totally new at angular and SPAs make the effort 2-3x harder and really had nothing to do with SPAs?

Salman · January 8, 2015, 7:52pm

That could be true, but from the open source code bases that I have seen there is allot of work going into designing the UI. When building a SPA you def. will add more UI sugar since you have so much more control, and with that your timelines and shipping dates will get stretched out. That’s basically the point I am making.

Richard · January 8, 2015, 8:06pm

My opinion: it depends.

I’ve built both. I’d still use both methods depending on what I’m making. If the app is likely to become sophisticated, SPA immediately.

If your app is something where most of the value can be realised in text, and slickness is a nice-to-have, then yup, a HTML app with some jQuery will do fine.

What frustrated me with a HTML-first app was that it felt like we were continually working towards something but making it really nice was going to take far too much rework. Going direct to SPA, slower initially but it just feels designed properly. There’s space to refactor without starting from scratch. There’s no upper limit on how nice I can make it. I don’t build to save myself time now, I build so I hate my life less in 5 years time. It’s possible I’m prematurely optimising

Build half an SPA, not a half-assed MPA. (With apologies to DHH.)

johnf · January 8, 2015, 8:42pm

So the major point is if you decide to spend more time working with the UI you’ll be spending more working with the UI? Fair enough. ;p

davidw · January 8, 2015, 8:43pm

No, validation is not optional server side - it must happen there too. Otherwise your user can just look at the parameters they are sending, and craft their own message with curl or whatever. So it has to happen server side. What’s optional is adding it client side so that it’s quicker/cleaner/nicer for the UI, but at that point you’ve just doubled your work.

ian · January 8, 2015, 10:25pm

This is all irrelevant

You should only start your first product with a language/tech you know. Anything else is insane. The ONLY exception would be if your idea truly requires some special language/tech to even be possible. That pretty much applies to nobody on this board.

I’ve made this mistake myself though. We did SPA with Snappy and it cost us tons of extra time and money because none of us knew much about it (and it was pretty new really a few years ago). We would have got it up and running way faster and better with only a few mostly irrelevant downsides by just doing it in a more traditional way.

johnf · January 8, 2015, 10:27pm

Haha maybe I’m explaining this poorly. Have you written a SPA before?

In a plain old form submission app you submit details, then validate the details, then in the case of a validation error return the form the user submitted (so you can sync state) AND the validation details.

In a SPA you you submit details, then validate the details, then in case of error YOU DONT have to return the form data the user submitted (state is already synced because you never left! ) AND the validation details.

You know all that code you have to write to make sure the form the user submitted is the form they get after a validation error? You know when you have to set the dropdown value to what the user wants to change it to and not whats in the database? If there are errors, show this message here and blah blah. You don’t want them to do the same form tweaks twice right?

Well all that with a SPA isn’t necessary… does that make sense?

Ok so more specifically addressing the “doubling” comment this is probably from a misunderstanding on how to take advantage of modern frameworks to assist in keeping server and client logic in sync and maybe just a lack of experience in writing SPAs.

So sure, you do have to write if(something == nothing ) then {fail} on the server and then someplace in the html write something like in the client. However, because you know this is a SPA problem, what you really want to do is have a html view engine/renderer that can take the model as defined in your server logic and then output the required html automatically for you in the front end. Every web framework has a way to do this.

http://lostechies.com/jimmybogard/2014/07/22/conventional-html-in-asp-net-mvc-replacing-form-helpers/

Sorry, is this getting ranty?

Can we prefix further comments with people’s experience level in these frameworks? I just feel like people who have never painted a house before are starting to talk about what brushes to use.

davidw · January 9, 2015, 1:00pm

That’s what I was referring to. There are other advantages and disadvantages, as you point out, but you can’t avoid validation on the server.

gravelld · January 9, 2015, 3:11pm

I think this is generally sound advice, it’s hard to argue with.

That said, I built the UI portion of bliss in a language and framework I didn’t already know - Scala and Lift. Yeah, there was a learning curve, but the bits of Lift in particular that made developing a web app about 10x faster than the alternatives in J2EE… that partially made up for it, AND I learned me some Scala.