|
This is a thread about modern front-end web development frameworks, tooling, and practices. 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. Tooling This post used to have sections on these, but they became comically out of date literally like two months after I posted them, because of course they did it's JavaScript. Maybe some day I'll update them! Until then, try the tried and true method of picking a framework and build system based on the most Hacker News posts about it, or possibly where it ranks on Google Trends. abraham linksys fucked around with this message at 20:09 on Apr 5, 2015 |
# ? Sep 19, 2013 20:45 |
|
|
# ? May 2, 2024 22:09 |
|
Sometimes I see people talk about "routing" with these frameworks, and I'm not sure what that means. Can someone explain it?
|
# ? Sep 19, 2013 20:58 |
|
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.
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).
|
# ? Sep 19, 2013 21:11 |
|
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] 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.
|
# ? Sep 19, 2013 22:03 |
|
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).
|
# ? Sep 19, 2013 22:26 |
|
If you're using backbone be sure to check out http://marionettejs.com/ which adds some neato stuff on top of it.
|
# ? Sep 19, 2013 23:53 |
Cool, subbing to this. Maybe it will bridge the gap between the web design/development thread and the Javascript questions thread!
|
|
# ? Sep 20, 2013 00:18 |
|
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!
|
# ? Sep 20, 2013 00:23 |
|
Marionette seems to be more popular but at work we use Chaplin with Backbone.js: https://github.com/chaplinjs/chaplin
|
# ? Sep 20, 2013 00:28 |
|
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.
|
# ? Sep 20, 2013 00:32 |
|
Great thread, but you have a border around the Backbone.js logo and I resent that
|
# ? Sep 20, 2013 01:48 |
|
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.
|
# ? Sep 20, 2013 03:45 |
|
Couple of points I'd love you guys to elucidate for me:
|
# ? Sep 20, 2013 05:39 |
|
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.
|
# ? Sep 20, 2013 05:58 |
|
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): HTML code:
(The user has selected the first two values) Then some refresh script in the background updates the model, with JavaScript code:
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?
|
# ? Sep 20, 2013 07:39 |
|
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. 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.
|
# ? Sep 20, 2013 08:45 |
|
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 10:16 on Sep 20, 2013 |
# ? Sep 20, 2013 10:11 |
|
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?
|
# ? Sep 20, 2013 10:41 |
|
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.
|
# ? Sep 20, 2013 10:41 |
|
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?
|
# ? Sep 20, 2013 11:11 |
|
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);
|
# ? Sep 20, 2013 11:18 |
|
Wheany posted:No. _.defer(someFunction) basically means window.setTimeout(someFunction, 0); Indeed, so I guess these mixins would do the trick?
|
# ? Sep 20, 2013 11:25 |
|
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. 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/leveraging-deferreds-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?
|
# ? Sep 20, 2013 14:54 |
|
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?
|
# ? Sep 20, 2013 14:58 |
|
DreadCthulhu posted:Couple of points I'd love you guys to elucidate for me:
|
# ? Sep 20, 2013 15:20 |
|
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.
|
# ? Sep 20, 2013 15:46 |
Wheany posted:Well, I'm going to repost my question from the javascipt thread here: 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.
|
|
# ? Sep 20, 2013 16:30 |
|
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.
|
# ? Sep 20, 2013 16:57 |
|
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.
|
# ? Sep 20, 2013 17:10 |
|
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 18:09 on Sep 20, 2013 |
# ? Sep 20, 2013 18:07 |
|
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.
|
# ? Sep 20, 2013 18:09 |
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.
|
|
# ? Sep 20, 2013 18:42 |
|
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. 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 08:16 on Sep 22, 2013 |
# ? Sep 21, 2013 00:14 |
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.
|
|
# ? Sep 21, 2013 00:46 |
|
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!
|
# ? Sep 21, 2013 10:06 |
|
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 21:14 on Sep 25, 2013 |
# ? Sep 22, 2013 09:37 |
|
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. 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/backbone-fundamentals/blob/gh-pages/chapters/08-modular-development.md
|
# ? Sep 22, 2013 17:47 |
|
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. 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)
|
# ? Sep 22, 2013 23:56 |
|
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. 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.
|
# ? Sep 23, 2013 02:50 |
|
|
# ? May 2, 2024 22:09 |
|
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.
|
# ? Sep 23, 2013 03:48 |