Help me pick the right web stack
I am writing a new web application from scratch. It is not trivial - there will be a requirement to provide streaming video and also facilitate live video streams between users. Front end will be written in Angular.js (because I know it). I need to find the right back end stack. I like .NET but feel limited but am not that familiar with ASP.NET 5. I am considering Node.js with a Postgres back end but the lack of static typing turns me off. Java/Kotlin seems ok but tooling less elegant (+ I am not a fan of big IDEs). Go is nice but its simplicity also makes it very verbose (eg lack of templates). Ruby is dog slow so out of question. Python suffers from the big lock. Any suggestions on a solid web framework with the speed and simplicity of Node.js and the static typing of .NET?
12 comments
[ 3.3 ms ] story [ 26.2 ms ] threadIf you know you can hire remote, then you have more options.
If you likely can only hire locally, then choose a stack that won't alarm local, good candidates. In my area, for example, Python nearly does not exist. Ruby,.NET, and PHP have the overwhelming majority. I can find .NET and PHP programmers tomorrow, but locally I can't find any Julia or Clojure devs.
In general static typing helps me on bigger projects with team members be responsible, but slows me down on weekend projects for funzies. I'd go with static if I were you.
The views are type checked as well, like in asp.net mvc. In fact, it's inspired by the razor template engine, you won't miss the magical @.
There are a ton of templates available[0], auth, websockets, upload etc..
Over the last few years, the Play framework improved a lot, Java is not a second class citizen anymore, like many people think.
> I am writing a new web application from scratch. It is not trivial - there will be a requirement to provide streaming video and also facilitate live video streams between users.
This is from the official docs:
Because of the way Play works, action code must be as fast as possible, i.e., non-blocking. So what should we return as result if we are not yet able to generate it? The response is a future result!
A Future[Result] will eventually be redeemed with a value of type Result. By giving a Future[Result] instead of a normal Result, we are able to quickly generate the result without blocking. Play will then serve the result as soon as the promise is redeemed.
The web client will be blocked while waiting for the response, but nothing will be blocked on the server, and server resources can be used to serve other clients.
Also make sure to checkout the streaming section of the docs[1].
If you are looking for a robust framework which embraces performance and developer productivity, Play is the way to go. I've never found a framework that could satisfy all my needs, like Play.
I didn't even mention all the awesome features but if you are interested check out the Play Philosophy[2].
Why am I so convinced about Play ? I have more than 5 apps in production, I couldn't be more happy about my decision to use Play. I wrote applications in asp.net mvc, Spring MVC/Boot, Rails for many years, they all failed me.
[0] http://www.lightbend.com/activator/templates
[1] https://www.playframework.com/documentation/2.5.x/ScalaStrea...
[2] https://www.playframework.com/documentation/2.5.x/Philosophy
Could you elaborate more on how these alternatives failed you?
I've been considering jumping into the Java/Play ecosystem for awhile but have been hesitant so far. Analysis paralysis at its worst!
What asp.net MVC and Rails got in common, is that they are heavily opinionated how things should work, this can create many problems if you need a solution to a specific problem which is outside of the typical CRUD scope, it's very hard to break conventions and do things differently. This lead my many times to just start over the whole project.
Let's start with asp.net MVC, they open sourced it, that's good news, but the deployment options are still bad, as far as I know, there are a few community driven web servers, which aren't production ready in my opinion.
ASP.NET MVC:
works great, if you use the other MS tools like MSSQL, ISS etc, but if you are trying to replace one of those components, you are in a world of pain. So basically asp.net mvc, is on hold for a while.
Spring:
I'd love to sum up why I prefer Play over Spring but Yevgeniy Brikman did a great job doing that.
https://www.quora.com/Which-is-better-Play-Framework-or-Spri...
Rails:
is ... the perfect framework for smaller CRUD applications, that's all I can say.
> I've been considering jumping into the Java/Play ecosystem for awhile but have been hesitant so far. Analysis paralysis at its worst!
What's your background ?
> What's your background ?
I went something like game dev (C++) -> enterprise client/server apps (C++/Qt) -> web dev (Python/Django)
Django, like Rails is fantastic for hashing out small-med sized apps, but I've been looking to add another tool to the box. Something statically typed, more performant relative to Python, and with a large ecosystem to draw from to get stuff done quick.
I've been using Java on and off since the late 90s... it's overly verbose but it seems like it's gotten a bit better w/ Java 8 and the code gen features available in IntelliJ. I've also avoided J2EE/JEE like the plague. Coming from Django, and not wanting anything to do with JEE makes Play a rather appealing choice on the surface.
Go seems like the only viable alternative as I do not want to switch to a MS hosting stack to host .NET.
Of course there are all of those other JVM languages to poke at!
I guess the JVM is your best bet at this point, there is a huge eco system out there, the best thing about it, is that it's very mature.
Well if you got any questions about Play, just drop me a line.
It is designed for concurrency that you will need when designing live streaming web app.
> and the static typing of .NET
The last time I checked on Clojure everything was quite dynamic, did they change that ?
If OP were to look at using Clojure/Luminus they might find that the combination of everything except the static typing was sufficient to overcome the lack of static typing (also something like Prismatic Schema to mitigate types might help). I haven't messed around with it enough to say, but there is also JVM interop with clojure so one could write the most type-concerned components in Java (or even in Scala).
tldr: failing one requirement of many isn't necessarily a reason to not offer an option if it succeeds on many others.
> tldr: failing one requirement of many isn't necessarily a reason to not offer an option if it succeeds on many others.
Yes I agree, if the question allows that approach but in this case, it doesn't.
The libraries are top-notch and unlikely to be found in other languages due to the superior typesystem.
It has broad tooling support, and Scala's JavaScript backend is stable, mature and actually works (unlike some other JVM languages' JS backends which currently exist mostly in marketing speeches).