New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
What's your Single Page App stack? Your JS Framework Choice?
raindog308
Administrator, Veteran
in General
I read an article on the MEAN stack (MongoDB, Express.js, Angular.js, and Node.js) which intrigued me. I've done some light Javascript stuff (mostly with things like the Google Map API, customizing JQuery widgets, etc. But I haven't gone so far as to write a single page app.
Looking at this stack, my thoughts are:
Not a huge fan of MongoDB, but probably no reason this couldn't be either a different NoSQL engine or MySQL, PostGreSQL, etc.
I've read a bit on Ember.js and how it compares to angular.js
Not sure where Express.js fits into this which is probably my own ignorance.
There's also Backbone.js and others...this is a nice chart:
Comments
Ember with a C# Owin, Web Api backend is my goto.
C#, being one of the most featureful modern languages in use today, then Owin to make it fast and cross platform (I've seen it faster than Nodejs). For the frontend I like Ember. It definitely is opinionated, but I feel it's more intuitive to use than Angular. The developers aren't afraid of fixing conceptual flaws.
None.
Ember.js + node.js + NoSQL
Backend with REST API (PHP or Node.js, depending on factors like "Do I need websockets?", " Do I need to process things even when no requests are coming in?" and so on). If I go for Node.js, I usually either use Express.js (serving the static files for my SPA and providing the REST API) or restify.
A database - either MySQL or MongoDB. Depends on what I'm heading for, if I just need plain structured data with sanity checks, transactions and so on, I'll head for MySQL ofc.
Angular.js all the way - it really rocks. I've tested quite a few frameworks and I went for
AnsibleAngular, as there's a great community and regular updates. Also, it's not that hard to get started and from all frameworks which I've tested, it seemed to be the most clean & slick framework.@Silvenga: Never heard of Owin before. How does it compare resourcewise? Does it need a lot of memory or is it LEB friendly?
Be carefull with PHP REST, PHP has a "bug" (they call it a "proper implementation of the RFC", so it's not going away) with PUT and multipart, you'll have to parse the raw data yourself (or hope your framework does this for you).
Yea, it's good that after testing Angular you went with ...Ansible
Uuurks, it's getting late. Fixed it
I haven't had problems with PHP backends yet, but they've always used some kind of framework, so I guess it was "automagically" done for me.
I should probably say it's still in a beta like stage, so things will charge, but from my experience it is very light (light like Nodejs). Microsoft took a completely different approach with ASP.Net 5, if you want something you must specify to load it, no more IIS that's preloaded with every library known.
Sequelize, Coffeescript, Angular, Express, static and Socket.IO
Plain Javascript... Sometimes jquery... I guess I'm oldskool now?
PHP for server-side..
Nope, you're just not building very complex sites
A js framework is not always the best choice.
Angular.js + Firebase is all you'll ever need. The backend is dead.
I dont really do front end stuff but when I have to, Vue (19kb) and Riot (4kb) are both very simple to use. They both use a React-like mvvm model which I really like.
Reading the docs... he rants about how cool is to not use templates as React preaches and then says how he dislikes React's syntax and his solution is to create a template system which he doesn't call a template.
Yeah, I'd trust my apps on his work, any time. 
Looks nice but it's not self-hosted and while they have a free plan, it looks like production is expensive. Not for a big company but still, more than I'd be willing to spend as a hobbyist. I mean, storing 30GB of data for $449 a month...O_o
I see they've been bought by Google...on the one hand, one of my chief concerns with writing to any API is if the service is likely to still be around in a few years, so that helps. On the other hand...it's Google, who loves to turn off things they buy.
Flask + Jinja2 + Whatever framework I feel like using. Right now, that template is Zurb + Sass for simple sites. For more complicated sites, I use Angular.
Generally, I look to use things that are more well tested and have support of larger companies and/or communities. Chances are, in a few years, half of the new JS frameworks will vanish, or become non-well maintained, and when that happens, fixing/updating your app is going to be a huge PITA and a timewaster. I would rather spend some more time learning about a more complicated, but more well supported framework rather than using one that is simple but not as tested/supported
>
If that's your criterion, picking Angular.js considering the 2.0 vs 1.x fiasco makes no sense.
This is to be used for textual data. Not to put images / videos in it. That kind of stuff normally resides on a CDN like S3. Yeah, I think 30GB of TEXTUAL (JSON) data is plenty for $449, it should be enough for at least 10,000 active users if not more.
Whatever you do, don't use MongoDB. It's slow, encourages bad practices, loses data, and there's nothing it's really good at - not even its own advertised usecases!
PostgreSQL is almost certainly a better option, and if you really need a schemaless/non-relational database (and if your data is relational, you do not), then look at any of the other options for that; eg. CouchDB, Cassandra, or even RethinkDB (despite its large storage overhead).
Aside from that, I tried AngularJS and didn't like it. Too much boilerplate, too hard to reason about the code, too much work to do simple tasks, and once you start building complex applications it just becomes layers upon layers of hacks.
React is a nice idea in theory, but I find the syntax to be horrible, personally. It's like I'm back in the 90s of unmaintainable spaghetti HTML/JS.
Ember tries to do everything, seems to make it really easy to accidentally create memory leaks (from what I've heard, anyway), and if you want to do something Ember wasn't made for, it becomes a similar amount of hacks to AngularJS - the problem with any monolithic framework, really.
I liked Polymer, which is built on Web Components (ie. a proper HTML standard), but I don't like the breaking changes in 0.8/0.9 at all, and it's a nightmare to bundle with tools like Webpack.
I've been looking at RiotJS lately. Similar conceptually to React, but much smaller (it really only implements the base functionality you'd need, lets you use existing libraries everywhere else), a much cleaner API (see also here), and very easy to pack with Webpack/Browserify/etc., even when using preprocessors. The one thing I haven't completely figured out yet, is how exactly it handles scoped CSS.
So yeah, I think I'll be settling on RiotJS.
EDIT: I should note that, aside from the view engine, I just use any usecase-specific modules from npm when I need them, using Webpack. I can definitely recommend that approach.
No, it's not. If you're building a shitty app to flip to Facebook a year later, maybe.
Try do anything analytics related, see how much textual data you'll get
Emberjs please
I'll comment on this as Ember is my choice (meaning I've spend some time with it).
Ember is made for building SPAs. I am curious to see an example where Ember was a problem instead of an asset when building an SPA.
Regarding the everything comment, I'd say it's a personal choice. Some people like tiny libraries they can compose bigger things out of. Other people prefer opinionated frameworks that provide the whole package. For someone who subscribes to the "small components" idea, certaily none of the big frameworks (Ember, Angular, React) apply.
For memory leaks, yeah, there's the occational one here and there. Gets reported, gets fixed asap, problem solved. Ember devs are super awesome.
AngularJS + MySQL
The previous version of the ArchiveBot dashboard used Ember. It doesn't anymore, because of these kind of issues.
Right. While I understand this, I more and more find that this tends to be a matter of "false simplicity". Much like people tend to pick MongoDB because it's "simple" (when it ends up being anything but simple in the long run), just because it seems easy to get started with, I find that people often end up doing the same thing with full-stack frameworks.
They go "oh, it's so easy, it provides everything!", only to be layering hacks upon hacks a few months later because they were trying to do something the framework wasn't designed for, or leaving a bug intact because it's a framework bug and they can't work around it, or...
The thing is that the purpose of "having something provide the whole package" can also be accomplished with a proper package manager (eg. npm), a proper module system (eg. CommonJS as implemented by Webpack/Browserify), and a list of recommended modules to use together on a blog. It's a documentation problem, not a technical problem - and trying to solve it through technical means is bound to result in monolithic frameworks that just create more problems in the long run.
In short; I have yet to see a valid reason for using a monolithic framework in an environment that provides good modularization capabilities (including browser Javascript, when using a CommonJS bundler).
Take a look at Ember-Orbit - here's a detailed intro that explains how to use it with websockets and how it all makes sense.
This is why choosing a framework is a big deal. It took me a lot of pain to settle to Ember. Imho, its way of dealing with things is intuitive and flexible (at least to my way of programming).
It's a bit of NIH syndrome, I'd say. Personally, I don't think my code can beat the tons of hours of work, thought and framework specific expertice the Ember/Ember-cli core devs have put on their product. So, given that we are not in the beginning of the whole thick frameworks thing (i.e. there is a lot of maturity), it makes sense to me to go with a ready made framework instead of rolling my own ad lib implementation.
I'm not the one who developed the dashboard, so that'd be somewhat lost on me
Right, but it's only really a big deal if you're using a monolithic framework. If I decide tomorrow that I don't like Bookshelf, for example, I could swap it out for Sequelize relatively easily - it'd be maybe a day of work, if that. Smaller dependencies - say eg.
money- would cost maybe 10 minutes to replace with a different one, if they end up misbehaving.Basically, the cost of choosing the "wrong" framework or module is drastically lower if you use modular frameworks and dependencies. They're much smaller parts to swap out, and generally interoperability with other modules is taken into account for modular dependencies - for example, a modular dependency is much more likely to implement Node.js streams than its own proprietary stream system, whereas a monolithic framework could fairly easily get away with a proprietary one.
But that's the thing - I'm not arguing against using frameworks - quite the contrary! It's not a good idea to try and roll everything yourself, exactly because you end up reinventing the wheel, usually poorly. I'm rather arguing against monolithic frameworks specifically, and would encourage using modular frameworks (and modules) instead.
Express, for example, is great - it's a framework that offers all the functionality needed for HTTP request routing, and you can plug in pretty much any piece of middleware that you might need. And if no middleware exists for the particular thing you want to use, it takes literally two minutes to write one.
In other words; you still end up benefiting from the work that others have done. The only thing you're still doing yourself, is the "glue code" (which is maybe 5% of the code, if that) and the business logic, which can't really be provided by a framework of any kind, whether monolithic or modular.
The trade-off here is that especially as your application grows, the explicit "opinions" in a monolithic framework are going to increasingly get in the way of what you want, and working around them starts costing more time than that 5% of glue code would have.
I should note that the reason for mostly bringing up Node.js examples, is that Node.js has a very well-developed modular ecosystem, that really allows for the advantages of modular dependencies to manifest. The same advantages can be gotten in any CommonJS environment, or even non-JS environments, as long as they similarly value modularity. Indeed, most Node.js modules on npm work in a browser out of the box, when using Webpack or Browserify.
I think this is the core of the conversation. In my view, that glue code is so much more than 5% and so very hard to do it right. Gluing parts to make a car does not make a good car by merit of the act of gluing itself. The parts you pick, how they all fit together, the system design choices you make, I find extremely hard to do satisfactorily.
For simpler apps, sure, it's not that hard. As app complexity rises, the importance of the gluing "quality" rises exponentially. So, for me, it makes sense to let someone else pay the pricing of doing it right. And since there are many who want to do that (many different frameworks), all I have to do is pick the one that I think fits best with my way of coding and learn it well.
That facebook react thing is getting interesting. We do use angular though
Recently I've been learning Angular. It kicks ass. I was considering Ember too, but the ember-cli thing was too complicated, and even though you don't have to use it, it seemed it was recommended and considered as "the right way". There's also some other alternatives like backbone + chaplin, but angular has the biggest community and is supported by Google, which is nice.
Angular + Go is now my choice. Its as quick to develop in as my old Flask + Custom JQuery route, yet noticeably less in server resource usage and faster in server requests. Also was a doddle to learn Go as its very similar in structure to old languages, especially Python and C.
There is a reason why lots of the big internet companies in the past year have moved there server side stack to Go, that its a hell of a lot lower TCO. Go really has suddenly hit it big.
wished there was a poll on this.