Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

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/backbone-fundamentals/blob/gh-pages/chapters/08-modular-development.md

# ¿ Sep 22, 2013 17:47

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 05:46

sim: Sep 24, 2003

I'm also really interested in React, but haven't tried it on a real project. The thing that scares me is writing HTML inside of JS. But I can understand the benefits, and with every JS MVC there's already a lot of blurring between HTML/JS anyway. NetTuts just posted a nice intro to React: http://net.tutsplus.com/tutorials/javascript-ajax/intro-to-the-react-framework/

# ¿ Nov 19, 2013 14:49

sim: Sep 24, 2003

DreadCthulhu posted:

Anyone here got experience with Marionette? I'm liking the idea of perhaps swapping the regular Backbone views with the "managed" ones to avoid some of the typical boilerplate, and the region swapping logic seems pretty reasonable too

If you're going to use Backbone to any extent, Marionette is pretty much required for view management. Like you said, you'll end up writing boilerplate code for everything Marionette does anyway, so you might as well just use it from the beginning. CollectionViews (and ItemViews) are super useful too.

Ochowie posted:

any thoughts on D3.js? It seems like a really neat visualization library.

It is! If you want to do something custom, especially using maps or some other unconventional chart, D3 is the way to go. If however, you just want functional, nice looking bar/line/pie charts, Highcharts.js is the easier choice.

# ¿ Nov 20, 2013 14:47

sim: Sep 24, 2003

DreadCthulhu posted:

Does anybody have advice on how to properly structure lazy fetching of resources in nested views with Backbone + LayoutManager? ... Do you essentially call fetch() on initialization of each view and immediately render a spinner in place, then register a callback on whenever the collection is done and just replace the contents? I think this is the simple case, but I also think there's a situation where some views don't quite know what children views to initialize until an outstanding fetch is completed, in which case now calling render() recursively cannot work, and you have to manually setup logic that checks for the presence of data.

The other hassle is that you need to account for two ways of fetching data: sometimes you already have it (a user lazily fetched it before, and never reloaded the app), you can render right away, and sometimes you don't, so you need to do an async operation.

Use event listeners. They are meant to get out of callback hell and situations like this. Usually I assign a model or a collection to each view (or multiple views to the same model/collection), then assign the view to render itself on model/collection sync.

For example, inside each view's initialize function:

code:

this.listenTo(this.model, "sync", this.render);

You could also trigger a custom function to get rid of the loading animation (and maybe have that call render instead). This is one of the nice features of Marionette; the collection views will automatically re-render in response to model/collection events.

# ¿ Dec 9, 2013 15:47

sim: Sep 24, 2003

Anyone have experience with Ext.js or Sencha Touch? I've avoided it like the plague but I keep getting recruited for jobs that require it.

# ¿ Dec 10, 2013 23:07

sim: Sep 24, 2003

the talent deficit posted:

Is there any reason to use RequireJS (or similar) over concating all my scripts (and dependencies) together via grunt/gulp/browserify if I'm using grunt/gulp anyways?

It's nice not having to worry about namespacing or script ordering, but in terms of benefits to your users, no.

# ¿ Feb 27, 2014 22:42

sim: Sep 24, 2003

Same here! I use Backbone at work and at home so I'd love to see how it works with React.

# ¿ Apr 14, 2014 14:10

sim: Sep 24, 2003

I'm a big fan of Addy Osmani. He's written two very comprehensive books on JavaScript design patterns (including OOP and MVC) and Backbone, both of which are free online:
- http://addyosmani.com/resources/essentialjsdesignpatterns/book/
- http://addyosmani.github.io/backbone-fundamentals/

In short, models are for getting/setting your data and views are for presenting that data to the user. OOP and MVC are generally the same in JavaScript as they are in any language, but of course each library has specific differences. If you already understand OOP/MVC in PHP, I think it's safe to just start learning Backbone. There is no controller in Backbone, instead a view will contain most of that logic. The view then renders a templates that are more like the views from other MVC libraries.

Addy Osmani posted:

Models manage the data for an application. They are concerned with neither the user-interface nor presentation layers but instead represent unique forms of data that an application may require. When a model changes (e.g when it is updated), it will typically notify its observers (e.g views, a concept we will cover shortly) that a change has occurred so that they may react accordingly.

Addy Osmani posted:

Views are a visual representation of models that present a filtered view of their current state... JavaScript views are about building and maintaining a DOM element.

A view typically observes a model and is notified when the model changes, allowing the view to update itself accordingly. Design pattern literature commonly refers to views as "dumb" given that their knowledge of models and controllers in an application is limited.

Users are able to interact with views and this includes the ability to read and edit (i.e get or set the attribute values in) models. As the view is the presentation layer, we generally present the ability to edit and update in a user-friendly fashion.

# ¿ Jun 17, 2014 16:32

sim: Sep 24, 2003

nexus6: I think you can build entire apps using just Knockout, never learn Backbone, and you'll be fine. Or vice versa. Both libraries, along with every other JavaScript MV-whatever are all solving mostly the same problems. Knockout is more focused on the view layer and it adds two-way data-binding, which if you're coming from just jQuery, seems like a godsend. Backbone is more focused on RESTful interactions... but like I said, they can both solve the same problems: organizing complex code that allows users to interact with a lot of data.

Chengiz: what about Twitter Bootstrap or Zurb Foundation?

# ¿ Jun 20, 2014 18:24

sim: Sep 24, 2003

Maluco Marinero posted:

... the way React renders is a lot more straightforward than you think.

Of course there's a decent amount going on in the internals, but you can simplify it down go this:

Render cycle is done in JavaScript, and each component is given a key, this is either a number when you put in component children as arguments, or a string key when you use the property 'key' on that component. This key is how React finds the element in the real DOM, which you'll see in the only proprietary tag React uses, 'data-react-id'.

When the render cycle is done, it's diffed against the last render cycle, to see what changes need to be made. In the above case it would see that the only difference is that the {style: width: '65%'} property has changed.

With that information React does the DOM operations in as simple a way as it can. Using keys and what not to reuse elements effectively.

If a key needed to be moved, it can do it without having to rebuild the entire DOM element because it knows where it was and where it needs to go. In the case of the simple style tag, the resulting Dom operation is basically equivalent to:
code:
document.querySelector('.progress-bar').style.width = '65%';

Just wanted to say thanks for this. I've haven't worked with React yet, but I'd really like to. I've read multiple tutorials/introductions and while I understood the benefit, I never fully grasped exactly how it worked. This plain english description helped solidify it for me.

# ¿ Jul 8, 2014 18:14

sim: Sep 24, 2003

Need this http://www.urbanspoon.com/spin-widget for JS frameworks.

# ¿ Jul 16, 2014 18:55

sim: Sep 24, 2003

I've used http://requirejs.org but from what I've read it's not all that different than LABjs. All JS script loaders are basically the same. You don't have to turn everything into a module, just everything that you want to keep in a separate file. RequireJS provides a shim config option for fixing any libraries that aren't setup as modules. To do what you want to do, basically create a script that defines all your dependencies:

code:

requirejs.config({
    baseUrl: 'js/lib',
    paths: {
        app: '../app'
    },
    shim: {
        backbone: {
            deps: ['jquery', 'underscore'],
            exports: 'Backbone'
        },
        underscore: {
            exports: '_'
        }
    }
});

https://github.com/requirejs/example-multipage-shim/blob/master/www/js/common.js

Then wrap your main JS in a require call that loads in 'backbone' (or 'ember'), 'jquery', etc. and RequireJS will handle loading them all in the right order.

# ¿ Oct 17, 2014 17:53

sim: Sep 24, 2003

I agree that Angular has major problems. I just started developing with it a couple months ago, before that I used Backbone, Knockout, or just plain old JavaScript for many years. Here's a great article that references many of the problems: https://medium.com/@mnemon1ck/why-you-should-not-use-angularjs-1df5ddf6fc99

Basically:

two-way data binding is slow, makes data flow complex, and has hard limits (2k watchers)
string based dependency injection breaks on minification
errors in templates don't fire, which might be ok except...
logic is in your HTML
scope inheritance is complicated
directive methods are complicated
terrible documentation

There's also this article: http://www.fse.guru/2-years-with-angular, which talks about similar but different issues with Angular. The author only recommends it for prototypes, or very basic CRUD applications.

# ¿ Jan 11, 2015 16:58

sim: Sep 24, 2003

HaB posted:

The guy who spent 2 years on Angular has a few valid complaints, but I'm guessing two years with ANY library would result in an equal number. Angular is not the end-all, be-all - neither is any other library. We looked at a lot of frameworks before doing the project we started a year ago at work, and Angular / Ionic turned out to be the best tool for our specific situation. Would I recommend it for another project? Maybe? Depends on the project. Like it always should.

I agree, 100%. I'm also building an app with Angular / Ionic and if I had to start over, I would still pick Angular / Ionic. Angular is great for what it does. I think the people who complain about it are just venting frustrations and playing devil's advocate to all the complimentary articles and seemingly endless praise. I find their tear downs useful for planning around Angular's shortcomings.

# ¿ Jan 12, 2015 16:38

sim: Sep 24, 2003

Do you have a <ui-view> in _buildingGrid.html? "Child states will load their templates into their parent's ui-view."

# ¿ Jan 28, 2015 17:20

sim: Sep 24, 2003

https://thinkster.io/a-better-way-to-learn-angularjs/ - I think mostly free links, including a lot pointing to egghead.io (their paid courses are great too)

# ¿ Apr 20, 2015 15:23

sim: Sep 24, 2003

While I 100% agree with you Lumpy and try to follow the same patten, I'm not sure how much it matters. If you decide to change your UI from a modal to a new screen/route, you've only really saved yourself from renaming the "isModalVisible" property. You still have to change out the interface that opens the modal and inject the new one.

# ¿ Nov 21, 2015 18:59

Adbot: ADBOT LOVES YOU

# ¿ Apr 27, 2024 05:46

sim: Sep 24, 2003

Click Beelay posted:

I'll be using JavaScript, React, Async, and Redux, and will apparently be given some exposure to backend (my preference) and mobile development.

Now the hosed up part, I never used any of those technologies throughout my degree. The last three I'd never even heard of until I started researching after the interview. I was very up-front about my experience and was assured it wasn't an issue, though I was made aware that I "will be learning a gently caress load".

...

My question - am I hosed, or is it likely that since I have no experience outside of uni I'm overthinking the difficulty of being thrown into several technologies I've never heard of? Finally, could anyone recommend some learning resources for the four things I've listed?

Thanks.

At this point in my career (8 years), I specifically choose jobs where I'll get a chance to learn a new library, framework, stack, etc. I spent the last year building with Angular and earlier this month I started learning React / Redux. You'll be fine. Get used to continually learning new things, it will make you a better developer. As far as learning React/Redux specifically:

egghead.io video course on Redux from the author of Redux (all egghead videos are super useful)
Reactiflux Discord chat - lots of helpful devs here talking about all things React/Flux/Redux
http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html
https://www.stanleycyang.com/tutorials/mastering-react-redux

# ¿ Jan 28, 2016 15:50

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT