Search Amazon.com:
Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us $3,400 per month for bandwidth bills alone, and since we don't believe in shoving popup ads to our registered users, we try to make the money back through forum registrations.
«15 »
  • Post
  • Reply
abraham linksys
Sep 6, 2010

> typeof null === "object";
true
>


This is a thread about modern front-end web development frameworks, tooling, and practices. I wrote a long OP for it because a lot of people don't know much about these things, and it's only relatively recently that this has stopped being "web hipster bullshit' and started being stuff that people create production applications with. Yes, even CoffeeScript.

What is modern front-end development?

A long time ago (in client-side terms), John Resig released jQuery, drastically simplifying life for developers doing client-side scripting. Abstracted away were awkward APIs like XMLHTTPRequest or the seventeen different implementations of the DOM, replaced by cute little $("selectors") and $.get("/my-rad-resource"). Of course, jQuery wasn't the only library attempting to simplify front-end development: new frameworks like Dojo, YUI, and SproutCore were being released around the same time, attempting to simplify a minefield of half-implemented specs and poorly-understood standards.

Life was good. jQuery became a de facto standard over time, people shared plugins that made it (relatively) easy to drop in widgets and custom behavior, and code became cleaner and easier.

But there were problems on the horizon. Client-side code became larger as the client became more capabilities, with no clear way of organization. It was hard to write anything with actual dependencies. It was even harder to write custom build steps to concatenate and minify your code in production, so the browser wouldn't have to deal with a meg of JavaScript split across 200 <script> tags.

Thus, developers started making cool things to make it easier to develop apps, and that's led to the modern front-end development scene today.

Frameworks



Backbone.js is the most popular of the new crop of JavaScript frameworks. This is owed to its ease of use and extremely tiny footprint - Backbone is about 6 kb minified, and all of 1500 LOC unminifed. Backbone is extremely unopinionated, providing nothing but a very barebones model layer, an Underscore-powered collection class, a minimal view layer, a simple router, and an events system for these pices to communicate with each other.

Because of Backbone's simplicity, many libraries and boilerplate templates have sprouted up around it. These include Backbone Boilerplate, Marionette.js, and LayoutManager, all of which I know basically nothing about but I'm told are quite useful for large-scale applications!

Major sites using Backbone include Pitchfork, Gawker, Airbnb, and Khan Academy.

The only good resource I know of for learning Backbone is its website. Please post any suggestions if you know them!



AngularJS is a framework that's gained a lot of momentum in recent months, mainly because, well, look at that byline. Angular is a large framework, unique due to its lack of a custom data model. While both Backbone and Ember have a model layer based around using getters and setters to compute properties and fire off events, Angular opts for a dirty-checking based system that constantly iterates over your data, looking for changes. While this might sound terribly inefficient, in practice it's quite fast, and allows you to write code that feels more like vanilla JS.

On the other hand, while Angular's data layer may be simple, the rest of it is quite daunting. Angular brings a ton of concepts to the table. Some, like data-binding your HTML, are easy to understand, while dependency injections, factories, and directives may take a bit of reading to properly grok. The upshot to Angular is that it is incredibly robust, and surprisingly integrate with existing applications. The downside is the steep learning curve, as well as some immature components (such as the router).

Major sites using Angular include, well, probably some Google products. I can't find a decent list of large sites using it in production, though I'm pretty sure they're out there! I used it where I was last working. It was pretty fun.

While Angular's docs are kind of awful, the upshot is that everyone knows it and tech bloggers and writers have been scrambling to supplement them. While you can probably find an Angular tutorial by just going to Hacker News and looking in the current top 10, the most-recommended resource I've seen are the screencasts at egghead.io.



Y'all, I'm gonna be honest: I loving love Ember.js. I contribute to it, I use it, and it has an adorable hamster as its mascot.

But it's not for everyone. Ember is probably the most difficult of these three frameworks to use properly. It's heavy. Rails-level heavy. There is lots of magic, there's lots of documentation (a lot of which is not great!).

Ember began life as a fork of SproutCore, a framework most famous for being used at Apple to power the original version of iWork.com. SproutCore was intended to bring desktop app semantics to web development, and Ember still keeps on this legacy - if you've done work with Cocoa, you'll probably feel at home with Ember. The difference is that Ember is still a web framework first and foremost and sticks to web standards, rather than trying to reinvent HTML like SproutCore did.

In practice, Ember's the most like a traditional MVC framework. Ember's model layer is similar to Backbone's, though persistence is entirely handled through a separate, optional, and less stable library called Ember Data. Ember's controller layer is intended to be the place for your business logic, while the view layer deals with presentation. The key difference with Ember is that it is router-driven - Ember's router is incredibly robust, and handles a lot of edge cases that other stateful client-side routers do not.

Major sites using Ember include Square, Discoure, Travis CI, Zendesk, and Twitch.

Ember's recently released 1.0.0, and a major docs push has come with that. The guides on the site are quite good. EmberWatch and Ember Weekly are also good resources for keeping up to date.

Oh, and for figuring out the architecture of your app, I recommend Ember App Kit. Think of it as the rails create of Ember.

I'm gonna finish this OP sometime in the future, but in the meantime, here are some more neat things you should at least know of:

Tooling
  • Are you using Grunt? You should be using Grunt. Why aren't you using Grunt? Use Grunt.
  • Bower is basically just git clone as a "package manager," but it's better than tracking down files to wget.
  • Yeoman is a generic command-line tool for generators to use. It's good for setting up boilerplate for whatever you're making.
  • Chrome Dev Tools
Other Things
  • CoffeeScript is neat. It does source maps now too.
  • ClojureScript is a toy, but it's a fun one. Also has source maps now!
  • Promises are important. It doesn't matter what library you use for them, as long as it's Promises/A+ compliant. That means not jQuery's.
  • Module systems! RequireJS, Browserify, or for those who aren't faint of heart, the ES6 module transpiler will allow you to use the module syntax of tomorrow (where tomorrow === 2025) today.

Adbot
ADBOT LOVES YOU

bartkusa
Sep 25, 2005

Air, Fire, Earth, Hope


Sometimes I see people talk about "routing" with these frameworks, and I'm not sure what that means. Can someone explain it?

abraham linksys
Sep 6, 2010

> typeof null === "object";
true
>


bartkusa posted:

Sometimes I see people talk about "routing" with these frameworks, and I'm not sure what that means. Can someone explain it?

http://routing.just/means/urls!

A router is the piece of your application that handles the current URL. In a traditional, server-side model, usually you have some kind of routes.[rb|py|js|php] that determines which controller/view/whatever handles each route.

On the other hand, client-side routing usually is based on one of two things. In both cases, you usually have a single-page app, which doesn't mean that your app is actually a single logical page, but is represented with a single HTML file on the server.
  • Hash routing. So, if you have a file on your server at index.html, because of the way hashes work in URLs, index.html/#/foo will also take you to index.html. A client-side router can then handle the hash bit as if it was a URL, in this case /foo. It's simple to set the current hash in JS, and the browser automatically considers that a new page in your history. Then, your router can listen for the onhashchange event to determine when to update the current "page."
  • PushState routing. This is more advanced, and involves your router pushing new "pages" into the history using the HTML5 history API. This will give you what appear to be the same as a server-side URL, like myapp.com/foo, with no hash. The downside is that, if you've architected a "single-page" app where your application is represented in only a single server-side HTML page, your server's router will need to always send you to the same page, regardless of the URL. So the tradeoff is prettier URLs for a bit more server-side configuration
All three of the major frameworks can be configured to use either of these modes. Hash routing has better browser support, and is usually used as a fallback if you set up PushState routing.

Client-side routing is inherently more difficult than server-side routing because, unlike in server-side routing, your state isn't reset between each page! There's a lot of weird issues that arise because of this. If you've ever been navigating a site, hit back while it was loading, and everything suddenly broke, that's probably because they were using client-side routing (lookin' at you, GitHub).

fidel sarcastro
Nov 13, 2009

nailed it


abraham linksys posted:

[*] PushState routing. This is more advanced, and involves your router pushing new "pages" into the history using the HTML5 history API. This will give you what appear to be the same as a server-side URL, like myapp.com/foo, with no hash. The downside is that, if you've architected a "single-page" app where your application is represented in only a single server-side HTML page, your server's router will need to always send you to the same page, regardless of the URL. So the tradeoff is prettier URLs for a bit more server-side configuration[/list]
All three of the major frameworks can be configured to use either of these modes. Hash routing has better browser support, and is usually used as a fallback if you set up PushState routing.

Is this the same thing people have been doing with mod_rewrite for ages, or am I misunderstanding?

What's a typical back-end look like for one of these apps, anyway? Are they pretty minimal, or are you basically just spitting out JSON instead of rendering a view? I'd like to start doing more client-side stuff because I actually like writing JS (weird, I know) but I'm pretty lost with how it all fits together.

abraham linksys
Sep 6, 2010

> typeof null === "object";
true
>


fidel sarcastro posted:

Is this the same thing people have been doing with mod_rewrite for ages, or am I misunderstanding?

Nah, you nailed it. Of course, for those who eschew writing URL rules at the server level, you can do a simple wildcard route in your back-end of choice.

quote:

What's a typical back-end look like for one of these apps, anyway? Are they pretty minimal, or are you basically just spitting out JSON instead of rendering a view? I'd like to start doing more client-side stuff because I actually like writing JS (weird, I know) but I'm pretty lost with how it all fits together.

You can do pretty much anything you want on the back-end, but the flow is different. It's a bit tricky to explain without pulling out OmniGraffle, but instead of "Server-side route -> get data in a controller -> put that data in a server-side view -> output rendered HTML," your flow becomes "server-side route goes to your single-page app -> client side route figures out what data needs to be retrieved -> ajax call to your server -> return as json -> pull into your models/controller -> render in your client-side template" (with a few other layers mixed in for good measure).

Baby Nanny
Jan 4, 2007

I ATE TEHLOKI'S BUTTHOLE WITH MAYO AND IT WAS DELICIOUS


If you're using backbone be sure to check out http://marionettejs.com/ which adds some neato stuff on top of it.

A MIRACLE
Sep 17, 2007

All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

Cool, subbing to this. Maybe it will bridge the gap between the web design/development thread and the Javascript questions thread!

fidel sarcastro
Nov 13, 2009

nailed it


abraham linksys posted:

You can do pretty much anything you want on the back-end, but the flow is different. It's a bit tricky to explain without pulling out OmniGraffle, but instead of "Server-side route -> get data in a controller -> put that data in a server-side view -> output rendered HTML," your flow becomes "server-side route goes to your single-page app -> client side route figures out what data needs to be retrieved -> ajax call to your server -> return as json -> pull into your models/controller -> render in your client-side template" (with a few other layers mixed in for good measure).

That actually makes a lot of sense, OmniGraffle or no. Thanks!

Stoph
Mar 18, 2006

Give a hug - save a life.

Marionette seems to be more popular but at work we use Chaplin with Backbone.js:

https://github.com/chaplinjs/chaplin

PlesantDilemma
Dec 5, 2006

The Last Hope for Peace

So of the big three, I thought only Backbone had support for old browsers, but it seems that Angular can work on IE7. However the docs says that google only officially tests against IE8. Backbone still supports IE6 but Ember only goes down to IE8.

Baby Nanny posted:

If you're using backbone be sure to check out http://marionettejs.com/ which adds some neato stuff on top of it.

At my work we have to support IE7 so we went with Backbone + Marionette and it was pretty awesome. However, getting a view to sort a collection was a pretty big headache. I have a feeling that is super easy in the other frameworks but in Backbone you gotta do it yourself.

quote:

Because of Backbone's simplicity, many libraries and boilerplate templates have sprouted up around it.

Yeah this is a major strength of Backbone. Having a simple core library that others build on means you are not serving a huge framework with features you might not be using to every client, but can focus and customize to what you need. However, it does mean that you have to pay attention to the libraries you are building on and make sure they are compatible with each other and keep up to date on new releases. We've got Backbone, Marionette, and CollectionSubset to keep track of at work.

smug forum asshole
Jan 15, 2005


Great thread, but you have a border around the Backbone.js logo and I resent that

hedgecore
May 2, 2004


The web link seems to be temporarily unconscious, but Addy Osmani's free e-book was my beginner's guide to backbone.js and brought me up to speed enough to build applications right away.
https://github.com/addyosmani/backbone-fundamentals

Los Techies has some useful http://lostechies.com/

For me, Marionette is a must. Build an application and then you will realize the difference in CollectionViews, CompositeViews, ItemViews, and Layouts .

I can't ever imagine not using underscore.js again.

RequireJS is a must. Anyone know of a guide to RequireJS that's a little less... dry(?) than the official documentation? I have trouble getting others started on it because of the incredibly flat tone.

DreadCthulhu
Sep 17, 2008

u mad, brah?


Couple of points I'd love you guys to elucidate for me:

  • I'm a Backbone user who's never worked with Angular. I've seen claims that Angular is a lot easier to partially integrate into an existing server-side website than Backbone. As in, you can opt to have one or two pages be SPAs if the use case calls for it, and you can still reap the benefits of server-side templating for the rest of the site. The claim is that Backbone pretty much calls for a complete integration across the entire website. Is there any truth to this?
  • What are some basic rules of thumbs for deciding when you'd really benefit of a SPA over traditional server-side rendering? I've been really lazy and just decided to have the entire front-end in a SPA, but then I've somewhat regretted it due to how much slower everything is now, for what is in my case a very small gain.

PlesantDilemma
Dec 5, 2006

The Last Hope for Peace

hedgecore posted:

RequireJS is a must. Anyone know of a guide to RequireJS that's a little less... dry(?) than the official documentation? I have trouble getting others started on it because of the incredibly flat tone.

Someone needs to do a newbie-friendly write up of RequireJS because I don't really understand it but it gets a lot of buzz. If I use RequireJS, I know I get to define what a script depends on and have a way to describe it in my code, so that has value. But I don't get how it brings in those depends. Does it compile everything into a big .js file with all my stuff? Or does it generate <script> tags to bring them in at run time? Right now we just have grunt concat and min all our stuff, but deciding the order that everything should be concat-ed was a headache.

DreadCthulhu posted:

The claim is that Backbone pretty much calls for a complete integration across the entire website. Is there any truth to this?

On the app that we used backbone.js for, we did not have to do 'backbone specific' back-end work. We just ignored backbone.sync and wrote our own ajax handlers for getting data from the server. So we don't call model.sync() or model.fetch(), but the rest of the backbone system works fine.

Now, our app might be unique in that it is just an interactive display of data. It does not upload new data to the server or otherwise change the state of object on the server. But even if it did, I don't think it would have been difficult to write our own sync handlers to send data in the format that our sever was expecting.

Wheany
Mar 17, 2006

CATAƆ
LOVES
FISHƧIᖷ


Well, I'm going to repost my question from the javascipt thread here:

How should I separate view data from server data?

If I have a view such as this (rendered as HTML):
code:
<select multiple>
	<option value="1" selected>Butt</option>
	<option value="2" selected>Arse</option>
	<option value="3">Rump</option>
</select>

(The user has selected the first two values) Then some refresh script in the background updates the model, with
Javascript code:
{
	1:"Butt",
	2:"Arse",
	3:"Rump",
	4:"Buns"
}
How do I preserve the user's selection when I re-render the select in response to "change:butts" event? The "selected" state is part of the view's state, it's not something that is synchronized back to the server, but it should not be lost just because an element changed.

Yes, this is specific to Backbone, since that's the only framework I've used. Do other frameworks somehow automatically separate model data from view data with some kind of converters in between?

DreadCthulhu
Sep 17, 2008

u mad, brah?


PlesantDilemma posted:

On the app that we used backbone.js for, we did not have to do 'backbone specific' back-end work. We just ignored backbone.sync and wrote our own ajax handlers for getting data from the server. So we don't call model.sync() or model.fetch(), but the rest of the backbone system works fine.

Now, our app might be unique in that it is just an interactive display of data. It does not upload new data to the server or otherwise change the state of object on the server. But even if it did, I don't think it would have been difficult to write our own sync handlers to send data in the format that our sever was expecting.

I think I might have explained myself poorly. The question was about how easy it'd be to turn only one portion of the front-end into a MVC thick-client javascript app with Backbone vs Angular respectively.

blugbee
Mar 1, 2004
hi c-fut

Assuming you have devs who are equally competent in both server side (Rails/Django etc.) frameworks and JS based ones what are the major factors that would lead someone to choose between a server side or JS framework? Am I wrong in thinking that JS based frameworks are unsuited for projects with performance and security based requirements?

For example, can someone more or less 'steal' all your JS and reverse engineer the backend, to reproduce your website? Or are all the JS controllers/models/logic etc somehow obfuscated in the frameworks

blugbee fucked around with this message at Sep 20, 2013 around 09:16

NtotheTC
Dec 31, 2007

and as for you..


I posted a little about this in the web dev thread but it's very interesting to me that in a world where average bandwidth is steadily increasing to the point where things are sliding more towards "dumb client/smart servers", these sort of frameworks that put a lot of the logic into the client side are gaining popularity.

I use Django primarily and one of the features I love about it is the effort they put into disconnecting the business logic layer from the presentation layer. I don't know how these .js frameworks flow when done properly but do they basically require developers to be front-end AND back-end?

Also, is there not a lot of code duplication required? For example, having to write client-side validation on form fields to gain the benefits of the fast response times/lack of page refresh, but also write validation on the back-end to cover off the genuinely prickish users that try to bypass all your client-side js code?

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

PlesantDilemma posted:

Someone needs to do a newbie-friendly write up of RequireJS because I don't really understand it but it gets a lot of buzz. If I use RequireJS, I know I get to define what a script depends on and have a way to describe it in my code, so that has value. But I don't get how it brings in those depends. Does it compile everything into a big .js file with all my stuff? Or does it generate <script> tags to bring them in at run time? Right now we just have grunt concat and min all our stuff, but deciding the order that everything should be concat-ed was a headache.

It does generate script tags, though in practise there'll only be a single compiled file (the grunt requirejs plugin take over from what concat is doing now). Then you've the control over order and dependencies all nicely baked together. Here's the current dev version of of a site I've just started doing (sorry, it's a poo poo example as no actual modules have been written yet), with all my scripts injected via require.js:



and here's a quick production version, compiled:



The requirejs file is in the footer, but I could use almond to remove the need for it altogether; at the minute it runs require, which then injects my compiled main.js into the head.

I generally do website development, not apps, so my needs are a bit more basic than if I were using frameworks heavily, but I can't recommend require enough.

----

On frameworks, Ractive seems very, very good if you need something fairly simple. Just worked through the tutorials. Well written and engaging, which generally swings things for me, plus ractive was built for practical use by The Guardian, so it's somewhat battle-tested.

Skiant
Mar 10, 2013


Jesus Christ, after digging for the first time in the underscore doc, I just realized that my whole team is currently working with a half-assed underscore written by one dude in the team.

The only thing I'm unsure about is the promises pattern.
He really fancies that a lot, and it looks like _.defer() is doing just that. Is that right?

Wheany
Mar 17, 2006

CATAƆ
LOVES
FISHƧIᖷ


Skiant posted:

He really fancies that a lot, and it looks like _.defer() is doing just that. Is that right?

No. _.defer(someFunction) basically means window.setTimeout(someFunction, 0);

Skiant
Mar 10, 2013


Wheany posted:

No. _.defer(someFunction) basically means window.setTimeout(someFunction, 0);

Indeed, so I guess these mixins would do the trick?

hedgecore
May 2, 2004


I'm certainly still very new to this too, so while I'm going to try to help, my word is still a mere suggestion at this point.

PlesantDilemma posted:

On the app that we used backbone.js for, we did not have to do 'backbone specific' back-end work. We just ignored backbone.sync and wrote our own ajax handlers for getting data from the server. So we don't call model.sync() or model.fetch(), but the rest of the backbone system works fine.

Now, our app might be unique in that it is just an interactive display of data. It does not upload new data to the server or otherwise change the state of object on the server. But even if it did, I don't think it would have been difficult to write our own sync handlers to send data in the format that our sever was expecting.

I thiiiink the "proper Backbone" way to avoid spaghetti code would be to call .fetch() on the model to retrieve the data, override .parse() to format it how your model is set up, and use .deferred to continue execution once the request is complete. It took me forever to break away from using $.ajax().

Deferred writeup - http://quickleft.com/blog/leveragin...s-in-backbonejs

Wheany posted:

Well, I'm going to repost my question from the javascipt thread here:

It sounds like a bad idea to refresh a view/form field the user is actively filling out. Is there another way you can structure this? How would this behave outside of a MV* environment?

Bognar
Aug 4, 2011

I am the queen of France


So this thread motivated me last night to go check out Ember.js and dick around with it while watching the tutorials. The first thing that came to mind was that it could get very unwieldy once you start having a lot of templates. All the tutorials just have templates thrown into index.html which I could very quickly see growing to a huge number of lines.

What options are there for organizing your templates into different files?

chmods please
Apr 28, 2009

The machine is a piece of shit!


DreadCthulhu posted:

Couple of points I'd love you guys to elucidate for me:

  • I'm a Backbone user who's never worked with Angular. I've seen claims that Angular is a lot easier to partially integrate into an existing server-side website than Backbone. As in, you can opt to have one or two pages be SPAs if the use case calls for it, and you can still reap the benefits of server-side templating for the rest of the site. The claim is that Backbone pretty much calls for a complete integration across the entire website. Is there any truth to this?
  • What are some basic rules of thumbs for deciding when you'd really benefit of a SPA over traditional server-side rendering? I've been really lazy and just decided to have the entire front-end in a SPA, but then I've somewhat regretted it due to how much slower everything is now, for what is in my case a very small gain.

  • We do just that for some stuff here. One of our main applications is a large lumbering ASP.NET web forms behemoth and we've written a few custom components for it with Angular. It doesn't touch anything outside your application container element which is a huge win for integration.
  • We do a ton of server-side rendering for the application I'm working on. It's a huge performance win since we need to support IE8, so Angular is mostly used for the client-side UI with a lot of templating happening server-side. We have one form with over 2000 possible controls which in practice is usually around 20-50 depending on specific circumstances - I wouldn't want to have to generate all that dynamically with Angular just for performance reasons alone. We have three SPAs in this application, the entire administration section is one, then two for the customer side of things.

abraham linksys
Sep 6, 2010

> typeof null === "object";
true
>


Bognar posted:

What options are there for organizing your templates into different files?

grunt-ember-templates is what you want. If you want to skip actually setting it up, you might want to try Ember App Kit, which includes it as part of its boilerplate. Alternatively, if you're using Rails, the Ember Rails gem will handle templates, too.

A MIRACLE
Sep 17, 2007

All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

Wheany posted:

Well, I'm going to repost my question from the javascipt thread here:

How should I separate view data from server data?

If I have a view such as this (rendered as HTML):
code:
<select multiple>
	<option value="1" selected>Butt</option>
	<option value="2" selected>Arse</option>
	<option value="3">Rump</option>
</select>

(The user has selected the first two values) Then some refresh script in the background updates the model, with
Javascript code:
{
	1:"Butt",
	2:"Arse",
	3:"Rump",
	4:"Buns"
}
How do I preserve the user's selection when I re-render the select in response to "change:butts" event? The "selected" state is part of the view's state, it's not something that is synchronized back to the server, but it should not be lost just because an element changed.

If I remember correctly, in Backbone you have to call render manually right? When I was using it, I used it underscore.js templates. Anyways if you ARE calling render manually, maybe wrap that call in a closure, saving the selected index as a state in and of itself?

Wheany posted:

Yes, this is specific to Backbone, since that's the only framework I've used. Do other frameworks somehow automatically separate model data from view data with some kind of converters in between?

Knockout.js does this with ko.computed. I love knockout but it's probably easier to uhh, not change up your framework in the middle of a project.

Stoph
Mar 18, 2006

Give a hug - save a life.

blugbee posted:

Assuming you have devs who are equally competent in both server side (Rails/Django etc.) frameworks and JS based ones what are the major factors that would lead someone to choose between a server side or JS framework? Am I wrong in thinking that JS based frameworks are unsuited for projects with performance and security based requirements?

You need both. JavaScript frameworks don't replace Rails/Django, they replace jQuery spaghetti. Your application is not less secure because you organize your client side code better.

hedgecore
May 2, 2004


NtotheTC posted:

Also, is there not a lot of code duplication required? For example, having to write client-side validation on form fields to gain the benefits of the fast response times/lack of page refresh, but also write validation on the back-end to cover off the genuinely prickish users that try to bypass all your client-side js code?

You should be validating form input on both the frontend and backend.
Frontend equally for security and for user convenience (and to save you a page reload), and backend for security.

Wheany
Mar 17, 2006

CATAƆ
LOVES
FISHƧIᖷ


hedgecore posted:

It sounds like a bad idea to refresh a view/form field the user is actively filling out. Is there another way you can structure this? How would this behave outside of a MV* environment?

But isn't that the whole point of using models that fire change events? You just render your view whenever you feel like it, whether or not you have fresh data, and then just update the view when a change event comes in.

A MIRACLE posted:

Knockout.js does this with ko.computed. I love knockout but it's probably easier to uhh, not change up your framework in the middle of a project.

I don't use backbone for anything at the moment. I used it in a project a year ago. A current project I have inherited uses all the worst practices of from 2002, and might at some point get refactored into using some framework.

Currently I'm just slowly refactoring a 5000+ line file filled with (at best) inline HTML, but usually var div = document.createElement('div'); div.appendChild(document.createTextNode('This text isn't even dynamic, why would you do this'));. All the functions in that shitheap are going to be strict mode and use templates.

e: forgot to reply, but judging from the name "computed" sounds like exactly what I'm after in this case. Is knockout still being developed? A coworker was pretty excited about it a couple of years ago, but he said that it had been abandoned.

Wheany fucked around with this message at Sep 20, 2013 around 17:09

Plorkyeran
Mar 21, 2007

Plorky Pig, let's get that Maria+Holic typesetting done yeah? You're starting to develop the requtation of lazy and slow, so ammend that for your own sake


Stoph posted:

You need both. JavaScript frameworks don't replace Rails/Django, they replace jQuery spaghetti. Your application is not less secure because you organize your client side code better.
They sort of can replace Rails and Django. There's a large range of variation in how much of the logic goes on the server and on the client. At one extreme the server is just a thin wrapper around the database that handles authentication and security, and for that a microframework like Flask or Sinatra is more than sufficient. At the other extreme you can have everything but templating and animations and such on the server, and for that using a fully featured backend framework is nearly always a good idea.

A MIRACLE
Sep 17, 2007

All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

Wheany posted:

e: forgot to reply, but judging from the name "computed" sounds like exactly what I'm after in this case. Is knockout still being developed? A coworker was pretty excited about it a couple of years ago, but he said that it had been abandoned.

I'm not sure if it's still under active development. I used it over a year ago when my old company "revamped" our .NET stack to not be a huge pile of jQuery and nested ternary operaters (yes, really. Thanks 'lead' developer). Anyway Knockout as-is is fine, it doesn't really *need* anything, and will more than suit your needs if you have to clean up a huge mess. I used it with a bunch of underscore at the time, and I loved coding in it. But I kinda hate .NET/VS2012 and proprietary Microsoft stuff so at the time I was literally just using the server as a JSON / validation service, and did everything else with Javascript.

If you're absolutely married to the idea of having something definitely still under active development, look into other MVVM solutions. I don't know any off the top of my head though. Knockout owns though and you can use as little or as much of it as you need, you're won't be tied into a framework mindset like you are with backbone or angular.

The Insect Court
Nov 22, 2012

right-wing>>>
strawmen>>>
found here>>>


It would be interesting to see a brief write-up of Meteor/Derby/other cutting edge frameworks, if anyone knows enough to write blurbs for them. I can probably toss one together for Meteor if nobody else gets around to it.

duck monster posted:

I still can't decide if meteor is some sort of future alien technology or potentially the most bonkers confirmation that the web design world has no memory for hard learned lessons of the past.

Some of it just scares me. Querying the database from the client side? Sounds like a recipe for tears to me!

Meteor lets you define allow/deny rules for client-side queries, but yes it is a bad idea to let clients have full write access to the database.

The Insect Court fucked around with this message at Sep 22, 2013 around 07:16

A MIRACLE
Sep 17, 2007

All right. It's Saturday night; I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape... Let's rock.

I'm willing to contribute to Meteor discussion and answer questions about it. But if you're just looking for a tl;dr there are plenty of good resources that we could probably just link to.

duck monster
Dec 15, 2004



I still can't decide if meteor is some sort of future alien technology or potentially the most bonkers confirmation that the web design world has no memory for hard learned lessons of the past.

Some of it just scares me. Querying the database from the client side? Sounds like a recipe for tears to me!

Knyteguy
Jul 6, 2005

COME WITH ME IF YOU WANT TO LIVE.
WITH ME.
IN MY APARTMENT.
I NEED A ROOMMATE.


Thanks for the thread I've been hoping one would pop up (I was getting pretty close to creating one that wouldn't have been nearly as good).

Currently tutsplus.com ($20/mo) has a few good tutorials for this new style of web development. I'm running one on their site that basically teaches you how to create a whole analytics app with graphs and other cool elements with Ember.js using MongoDB, require, and a bunch of other stuff. It's been an extremely helpful place to get started after watching the old EmberJS video tutorial on the Ember site. The books on these subjects are obsolete almost before they're published.

Knyteguy fucked around with this message at Sep 25, 2013 around 20:14

sim
Sep 24, 2003


abraham linksys posted:

The only good resource I know of for learning Backbone is its website. Please post any suggestions if you know them!

hedgecore posted:

The web link seems to be temporarily unconscious, but Addy Osmani's free e-book was my beginner's guide to backbone.js and brought me up to speed enough to build applications right away.
https://github.com/addyosmani/backbone-fundamentals

Los Techies has some useful http://lostechies.com/

Seconding Backbone Fundamentals and Los Techies (lots of posts written by the author of Marionette); definitely add these to the OP.

hedgecore posted:

RequireJS is a must. Anyone know of a guide to RequireJS that's a little less... dry(?) than the official documentation? I have trouble getting others started on it because of the incredibly flat tone.

How did you recommend Backbone Fundamentals and not mention the RequireJS section:
https://github.com/addyosmani/backb...-development.md

ambushsabre
Sep 1, 2009

It's...it's not shutting down!


duck monster posted:

I still can't decide if meteor is some sort of future alien technology or potentially the most bonkers confirmation that the web design world has no memory for hard learned lessons of the past.

Some of it just scares me. Querying the database from the client side? Sounds like a recipe for tears to me!

The client just has a local copy of the database (which you can only send specific parts of) so that when they update something it can update in realtime and not care about when the server gets around to updating it. They still need to call a method on the server which can figure out permissions and stuff, and if the client's copy and the server's copy differ the client will revert to the server's copy. So in essence someone could gently caress with the DB on their client but as soon as they try and connect to the server again it'll revert back to whatever the "official" version of the DB is.

quick edit: sorry if this isn't clear I just really love meteor, I'm currently working on a writing app with it (source is here please don't kill me I haven't really taken the time to make it clean and nice and fully commented)

Nebulon Gate
Feb 23, 2013


ambushsabre posted:

The client just has a local copy of the database (which you can only send specific parts of) so that when they update something it can update in realtime and not care about when the server gets around to updating it. They still need to call a method on the server which can figure out permissions and stuff, and if the client's copy and the server's copy differ the client will revert to the server's copy. So in essence someone could gently caress with the DB on their client but as soon as they try and connect to the server again it'll revert back to whatever the "official" version of the DB is.

quick edit: sorry if this isn't clear I just really love meteor, I'm currently working on a writing app with it (source is here please don't kill me I haven't really taken the time to make it clean and nice and fully commented)

Holy poo poo. This is loving what meteor does? Would you mind if I PMed you? I'd like to know your thoughts on something.

Adbot
ADBOT LOVES YOU

ambushsabre
Sep 1, 2009

It's...it's not shutting down!


Winter is Cuming posted:

Holy poo poo. This is loving what meteor does? Would you mind if I PMed you? I'd like to know your thoughts on something.

Yeah hit me up, I will talk about meteor all day err day.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
«15 »