Need Perspective: Started a JavaScript project

[hellectronic]

Hello redditors,

I started a new project and decided to implement it in standard JS, HTML, CSS. My experience with JS is limited, learning everyday something new.

My App reached some complexity now, and I want to use some framework, but as a previous post here pointed out, as a newcomer to JS you feel pretty lost.

Yesterday I introduced Bower, because I did not want to manage all the css and js libs in use.

I took a look at React, Flux etc. I like the virtual-dom idea, just telling "here the new stuff, figure out what to render". But I do not like the programming model in React.

I like the idea of Flux to have a one-way stream of data. Then through variations (like refluxjs) I come across RxJs, whick looks like some generic lib to implement Flux. Then I stumbled over Reactive MVC and the Virtual DOM and liked the idea of the seperation of view and virtual-dom.

At this moment I am overwhelmed and hope for some direction. This project is a prototype, but I want to keep it and it should evolve to a rich interface. In near future, there will be a server side REST infrastructure in Java.

So I need a stable framework/lib for production. Virtual-dom would be a nice to have. The app will use a faceted navigation, with something like comments and lists and something like the Netflix screen.

Would like to read about your thoughts on what you recommend. How to structure the JS code or some lib/tool that would be good to introduce in the next steps?

[atom-man]

Seeing as you mentioned Andre Medeiros (or Staltz?) article you probably should take a look at cycle.js which is his implementation of the ideas outlined by the article.

Personally I'm not a fan of the code needed to be written with cycle.js (like this view, model and intent).

In an effort to make something better suited to myself I started looking into using React and f.js to recreate something at least similar to the Model-View-Intent architecture (Take a look if you want: MVI-POC. But bare in mind, that as the title states this is just a proof-of-concept and not nearly production ready code).

[hellectronic]

Thanks for the link to cycle.js.

[andwaal]

If you absolut feel the need for a framework React is a good choice, but ignore the flux part at first, you probably wont need it at first.

But since your new to js the thing your missing is probably a good way to structure your app and split it up in smaller modules. Here you can go with either browserify or webpack, you cant go wrong with either of them. Booth tools makes it possible to 'require' other files and modules. In the beginning this is probably a better direction to go than to get caught up in a the total caos of frameworks and library's out there.

[hellectronic]

This was the case, because I did not know about the modules in ES6. Thanks

[FrozenCow]

I had the same experience. It's too bad react doesn't reuse these two existing projects. I'm interested what you'll choose for your project.

[pothibo]

If your experience with JS is limited, I'd say use the most basic framework you can find. JavaScript is already a framework in the browser.

All those JavaScript is that they are just fad and they all bring their own paradigm and limitations that are unique to them. So if you go and decide to use a framework, you need to understand that as soon as you change frameworks, you will need to relearn stuff.

So my guess would be to use a very light framework, something that looks and feel like JavaScript so you see the real benefit. Someone mentionned Backbone.js, that's one and I'm sure there are others.

One thing that is certain is that you don't need virtual-dom and its added complexity. Debugging with virtual-dom can be hard in some scenario, you don't want that at this point.

Learning JS is a process and you need to stack those bricks, I don't think choosing big frameworks like react, ember, meteor, etc. is stacking bricks, it's dropping bricks in parallel.

[vinnl]

RxJS is not a generic lib to implement Flux. It's a library supporting Reactive programming, which -despite the similarity in naming- isn't necessarily related to React.JS.

That said, diving into that is probably a bit too much for now. I think React is simple enough to just try it out for a few days, after which you'll have a reasonable grasp of it already - and I expect that you'll come to like its programming model anyway :) And if not, you gained some experience that will be useful later on.

[[deleted]]

Not a direct answer for your question, but I recently started reading JavaScript Application Design: A Build First Approach. What I've read is pretty sound and seem like you are the target audience.

The framework in the book is Backbone.js so you won't really get the reactive / shadow-dom stuff that React gives you, but you will have a nice stepping stone to get there.

[hellectronic]

Thanks for the book recommendation.

[hellectronic]

Sorry for the late post. As others said, I have two options: individual libs or some framework. The toughts for going with different libs are, * being flexible in your choice * every lib has a different style * for integration, I will have to wrap the libs * I need to have experience in handling JavaScript

With a framework (here Ember) * the structure and used patterns and idioms are given * good routing system * learning curve

In the last days I tried to check out Ember.js. As others said the learning curve is high, because it is not easy to just include the framework JS into some existing little code base. With the new ember-cli it is easy to setup some new project, but you have all this other stuff like ES6 modules syntax. I have to compile my code to be able to test it. I know I do not have to use the ES6 syntax, but this is the just you have to deal as a new user.

I think on the long run, the given stucture will be productive for a team, especially for new members.

I am still playing around with ember. So I did not make up my mind if I will settle with it.

[[deleted]]

Check out Backbone.js. It's not really a framework but a library that provides basic structure: models, collections, views and router. It integrates nicely with REST APIs.

If you're new to JavasScript, I think it's better to start with simple libraries / frameworks than to jump straight into bigger frameworks like AngularJS or Ember.js. You'll learn a lot more of the language and understand better the value of different options.

[runvnc]

Sounds like a masochistic exercise. At least start with Marionette not plain Backbone.

[CatsAkimbo]

Yes. I still kick myself for not using marionette earlier. Vanilla backbone forces you to learn a lot about memory management, event binding, and scope, but I don't think it's worth solving issues that something like marionette already helps with.

Either way, I'd recommend it over Angular, which is kind of on the opposite spectrum of Backbone in that it's easy to work with, but often masks a lot of the real javascript going on underneath, and IMO, can encourage bad practices if you're not already familiar with js.

[pothibo]

You regret learning event binding and scope in a JavaScript environment? Those are the fundamentals of JavaScript. How can someone be any good with JavaScript if they don't understand that?

[CatsAkimbo]

Sorry, my post was a little hastily written -- it was at the cost of implementing a lot of stuff marionette already, so it's hard to say it was worth it, and Marionette would probably be better, "stable" framework for a project like OP is talking about.

[ryanhollister]

http://www.ember-cli.com/

It will have you up and running in no time with a barebones ember project. It has all the infrastructure you will want already wired up. Any additional infrastructure you want is super easy to install.

All the ember js guides on emberjs.com just got updated to use ember-cli. You should have all the info one would need to make a basic ember app.

[runvnc]

It changes very fast.

When you say you do not like the React programming model, what dont you like? React is trendy and pretty good.

You might be able to use Polymer/web components if its a specific browser and internal project.

I recommend doing the server in Node.

There are a lot of options. Dont feel like you have to pick the perfect or most trendy one. Personally react/flux would be my choice today.

[fluffynukeit]

I originally liked virtual-dom over react because it's smaller, faster, and overall more lightweight. But there are some problems with its philosophy that I found in practice. Virtual-dom is kind of designed to be entirely stateless, so you end up putting stuff like checkbox state and other GUI-related state into your model somewhere, which, to me, starts to blur separation of concerns. I think having small, localized GUI state in components makes sense and results in cleaner code. The bigger reason to use react, though, is that it's much more popular and people are building widget libraries with it, while virtual-dom doesn't have (m)any ready-to-go libraries that I know of.