Javascript is our (new) Language

Posted By on Dec 31, 2016

Ok. If you had read my “Why PHP” post from the past, you’d think we were building Skooppa with the core language being PHP and you would have been correct. However, unfortunately, that is no longer the case. Some people might jump for joy with this decision, some might laugh and some might cry. Some might say, “Oh hell. Now even more waiting.” Sorry. Good things take time. Great things even more.

Theoretically that past post about PHP wasn’t completely correct anyway, as the UI’s behavior in the browser would have to be programmed in JavaScript too. So that article’s title should have read, “Why PHP (and Javascript)?”.


The Explanation


When I originally came up with the Skooppa idea, I felt deeply about Skooppa including the PHP community and its 5+ million developers.  The target market for Skooppa also uses PHP software, like WordPress and 80% of the websites today are powered with PHP. I was and still am a fan of PHP and its community. Those are all considerable motivators to have PHP be the core language.

I had also looked at Javascript, but wasn’t too sure of its backend ecosystem (i.e. NodeJS). It was fairly new at the time being about 3 to 4 years old. (Yeah, I’ve been working on this idea for about 3 years now!). Also, NodeJS was also going through some growing pains community-wise. They had just split up Node into two forks and that just sounded like an uncertain direction.

During the past couple of years, I had been working on my own developer skills. At the same time I was working with a group, who had developed a special PHP server, which could also support a framework type of PaaS. PHP’s shared nothing architecture is great for getting things done quickly and cleanly for single websites or web applications, but in a “framework PaaS” scenario, application code does need to be shared at some point. PHP doesn’t offer the needed architecture for this convention. And in fact, no language does it well, without needing to do some “circumcision” of the languages capabilities. Still, on top of the troubles of “dumbing down” and securing PHP for a PaaS environment, which I had envisioned for Skooppa, the issue of sharing a core code base with different tenants of a PaaS just wasn’t feasible, let alone performant.

Also, while working on the backend strategy, I was looking for a simplification of the technology needed to create applications. If you’ve worked on any kind of large applications with PHP as a full-stack developer, it is basically a juggling act between, front-end design, front-end behavior (i.e. what happens in the browser) and back-end design and data modeling (i.e. what happens on the server). I looked at other PHP frameworks like Laravel and Symfony and learned they offer very little to relieve the developer of this juggling act. In fact, they only play as heavyweight middle-men. A couple of small examples of where they do help are Laravel’s Elexir (which is a resource manager ran with…haha….NodeJS!!!) and Symfony’s Assetic. These two examples are only asset management (i.e. controlling which files, like JS, CSS or image files, get sent to the user’s browser). That is only a very small part of the juggling!


Finding Alternatives


I also delved into an experiment with MVC architecture too and dug into the concepts. I got into a deep discussion about MVC with a smart developer I was asking advice from, and he was of the opinion that I shouldn’t really need much of a controller. Other smart developers actually plead for “thin” controllers and want “fat models”. Others deny this as a necessity.

Be that all as it may, I am of the opinion that the backend need only be data resources and business logic. Some say this IS the model. I say, “kinda.” I can’t explain this in words down to the detail, as it would bloat this article to extremes, but I feel any “backend” is truly only data resources and business logic. Nothing else. Whether it is found in a model, or in some other convention, doesn’t really matter.

While looking for technologies to meet this viewpoint, all I could deduct was, what we are doing today with MVC simply isn’t “future proof”. Working in the old MVC paradigm like Symfony and Laravel do meant still living in the old box and I considered it quite limiting. REST APIs are sort of heading more in the direction I liked, but I still wasn’t satisfied. Creating REST endpoints is a messy deal.

So, I was at a dead end in terms of moving Skooppa forward. The technologies I felt were necessary for a future proof PaaS framework just weren’t available and I was just floating around, getting nothing purposeful done for a few months……..

…..until I watched this video. In that video, the team members from Facebook presented GraphQL. By the way, I had only found that video towards the end of 2015.

Now, some of you in the know will say, “Scott, that is only an API technology and has nothing to do with MVC.” and you’d be partially correct. The concern of getting data to and from view (web app, mobile app, even desktop apps) is what GraphQL is all about. You might also say, “REST also solves this problem”, and you’d also be partially correct. As I mentioned, REST was never something I felt comfortable with. It doesn’t totally solve the controller problem I wanted to avoid.

GraphQL does. It simplifies REST and improves it a lot. If you have the time, do take some to learn about GraphQL. I am betting it is going to replace REST at some point. And yes, doing GraphQL properly also means putting the view completely on the client (for the most part). It requires the client application to be a Single Page Application or SPA or a stand-alone application (like a mobile app). The GraphQL tackles a problem that caused an itch I needed scratching. It is the better and more future proof choice of API.


Finally Moving Forward (sort of)


So, Skooppa taking on GraphQL also meant the back-end was left to only send and store data and make sure business logic is adhered to. There would be no controllers! Well, not in the old MVC sense and not with REST. GraphQL was the answer I was looking for!

The world of GraphQL was also new, but not totally unknown to the PHP world. The stranger thing was, Facebook created a reference application based on Javascript and not on Hack, their PHP derivative. Go figure…. I even asked personally about this development.

Sadly, the answer from Facebook left me positive that I might get the Skooppa backend done with PHP (or if need be… with Hack) at some known point in time. This hope, however, inevitably just wasted a lot of time. Facebook never published the Hack version of a GraphQL server and I wasn’t about to get it done on my own.

I had come to the conclusion nothing would come about with a PHP/ Hack version of a GraphQL server. So, during the past several months, I started digging back into the NodeJS scene and Javascript and was pleased to see it had progressed very well. I started a poll among PHP devs in November and asked them if they’d be up for a “JS only” development platform. As you can see from the results, over 80% said they’d be ok with programming only in JS. That surprised me and lowered my acceptance threshold for a JS only platform.

Also during this time, an important PHP OSS project needed for our technology stack basically died in mid-flight. The devs that started the project also ended up having to work with different languages for their own companies. So, that left me high and dry with PHP and going nowhere fast.

It is also important to mention that Javascript itself has also gotten a good number of improvements with ES6. It is just a matter of time, before these improvements will work within browsers standard. Right now, it is possible to transpile the new features down to the old version, so developers are already coding with ES6 features (me included).


The Decision was Made


So, I decided to drop PHP for Javascript as the back-end language and it was done with reluctance. Still, with a majority of PHP developers not worried about working with JS, I am still confident this decision won’t alienate them. In fact, only needing to work in one language is a positive aspect of the decision. I must say too, once that decision was made, the amount of possibilities opened up tremendously. Everything that I had come up with as problems for Skooppa’s PaaS framework had some sort of solution already built and the GraphQL ecosystem has been growing like crazy, as has the NodeJS ecosystem.

That brings us up to today. I am sure most of you were thinking, “nothing will ever happen with Scott and Skooppa” and to be honest, that may still be true. Though, I am still working on Skooppa in my spare time and it is a lot of fun for me. I am learning a lot and I love pushing the envelope to break out of past paradigms. That is the only way Skooppa can make any difference, if and when it becomes a reality.

This is the first time I’ve ever nailed myself down to any kind of project date. I am doing this, because now I feel very comfortable with the direction. I am now planning to have a working POC of the basic Skooppa platform (code named “S6A”) working by the end of 2017. This base framework will also be OSS software, with a couple of stipulations. I’ll make those stipulations clear, once the time is right. Also, as the POC starts to take shape, I’ll be making a lot more update posts than I have been. I’ll be showing you all some of the technologies and “wins” S6A is going to offer for developing apps. Remember, I am working hard to lower the juggling I mentioned earlier.

If you have any further comments or questions, meet me on our forum and ask away. I’d really be happy to get some activity going on our forums other than the occasional spammer. LOL!

With that, Happy New Year and cheers for reading and your interest in Skooppa.


software image
4 based on 4 votes
Software Name
Operating System
Software Category
Landing Page