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

«‹›235 »

SuicideSnowman: Jul 26, 2003

Wheany posted:

What is the state of the art with asynchronous script loading/dependency resolution? I tried $script.js but turns out it's too simple for us. I'm not sure if I want to go all the way and start using modules, especially since I don't think all our libraries even support that.

I'm currently looking at LABjs, which hasn't updated in years (because it's stable and "done", apparently).

I "just" want to give a list of files to load, that are loaded as asynchronously as possible, but also say that "file_a.js must be run before file_b.js because file_b.js depends on file_a.js" (apparently this is easier said than done).

Some of the files are external libraries, like Ember, jQuery and Moment, so I can't easily wrap them into callbacks. Or I could, but it would be a maintenance nightmare.

So I need to be able to say "load jQuery before Ember. Then when both are ready, run app.js", except many more levels because our models and controllers are in separate files.

Not sure if it's something that would work for you, but I've had great success using Browserify to streamline my development process for a medium sized AngularJS project.

Using Browserify I've bundled my entire application into 2 JavaScript files. The first is for all the libraries that don't change like angular, angular-routing and some bootstrap components. The second file is all the Angular services, controllers and directives that are spread throughout dozens of separate JavaScript files. The app.js file that ties it all together essentially tells Browserify to "require" all my external libraries like Angular and then to look in separate folders I've created for controllers, services, etc which all contain an index file that declares all the controllers, services and directives my application uses.

In addition, with Gulp, I simply run a command which does it all in a matter of milliseconds. Using gulp-watch anytime I make a change to a CSS, HTML or JS file the aforementioned command is automatically executed. It then copies the updated files to the necessary location and I can immediately refresh the page and see the results.

Not to take anything away from Require because I used it previously with great success but my current process is much cleaner and efficient.

It all depends on your project though. I'm sure Require will work better for certain projects.

# ? Oct 18, 2014 02:20

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 08:31

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

So what should I do with modules that do not export anything, like jquery plugins and Ember app components?

JavaScript code:

define(['Ember', 'jquery', 'noty.layout'],
function (Ember, $, notyLayout /* uhh? */) {
	// I don't even need notyLayout for anything here, but there is a line that says
	$.noty.defaults.layout = 'topCenter';

	var app = Ember.Application.create();
	//...
	//...
	//...
	return app;	
})

Then again my own module:

JavaScript code:

 
define(['Ember', 'app'],
function (Ember, app) {
	'use strict';

	app.SomeController = Ember.ObjectController.extend({
	});

	// do I simply not return anything here because all I do is add the controller as an attribute to app?
});

Should I return app from the function?
Should I just use requirejs() for that function? Does that work when I need to access SomeController from another controller? Can I just use requirejs('SomeController') even when it doesn't return a value?

# ? Oct 18, 2014 13:47

Stoph: Mar 19, 2006; Give a hug - save a life.

Browserify is the current "state of the art" imho, but it requires you to adopt some unholy tool chain of grunt scripts, or gulp scripts, or who knows what is in vogue...

RequireJS is nice because it doesn't have a build step until you release to production...

# ? Oct 18, 2014 22:18

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

There's an RC out for React .12.

# ? Oct 19, 2014 00:48

ambushsabre: Sep 1, 2009; It's...it's not shutting down!

Is there any way in ember to call .save() or .update(), but only affect the local cache? I've got the code

code:

client.addListener('names', function(channel, nicks){
        var chan = store.all('channel', {name: channel});
        chan.set('names', nicks);
        store.update('channel', chan);
    });

Which seems to update it temporarily (I can call .get within that function and the update is reflected), but elsewhere it doesn't work. Am I missing something else?

e: for reference, the reason I'm using store.all instead of store.find is because I'm writing a frontend app with no backend, so everything needs to be done in the cache.

# ? Oct 19, 2014 13:36

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Wheany posted:

So what should I do with modules that do not export anything, like jquery plugins and Ember app components?
[snip]
Should I return app from the function?
Should I just use requirejs() for that function? Does that work when I need to access SomeController from another controller? Can I just use requirejs('SomeController') even when it doesn't return a value?

Okay, just shoving the non-module parameters to the end of the dependency list and just ignoring them in the argument list seems to work.
Also not returning anything seems to work too, so that's what I'm doing.

I made a separate "app-bootstrap" module that just does var app = Ember.Application.create() that I can add as a dependency to all my routes, controllers, models, views and other components that need "App" to exist to add properties to it.

# ? Oct 19, 2014 20:58

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

You might look into Ember CLI too. Like everything Ember, it has its own take how to handle modules. I don't really know what half this stuff means, but I signed for Ember knowing that people smarter than me were going to impose their opinions my workflow, so best to just go with it.

# ? Oct 19, 2014 21:17

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Kobayashi posted:

You might look into Ember CLI too. Like everything Ember, it has its own take how to handle modules. I don't really know what half this stuff means, but I signed for Ember knowing that people smarter than me were going to impose their opinions my workflow, so best to just go with it.

Well, I guess I could do that too, but I'm kinda not looking forward to doing the same work the third time within a week. But if that is a clean (and supported) way of modularizing an Ember app, it's probably worth at least checking out. :smith:

# ? Oct 20, 2014 14:28

EVGA Longoria: Dec 25, 2005; Let's go exploring!

CSS performance question: Is it better to have one block of rules with a lot of selectors up top, or a lot of duplicate blocks with simple selectors up top?

Basically, a coworker is using extend-only selectors in SASS for things like our buttons. Our code is clean when we write it, but we end up with generated CSS that makes me want to die:

CSS code:

nav.lander section.search input[type="submit"]:disabled, section.jobs button:disabled, button.action.paginate:disabled, .registration-form button.continue:disabled, .button:disabled,
button:disabled,
input[type="submit"]:disabled, nav.lander section.search input[disabled][type="submit"]:hover, section.jobs button[disabled]:hover, button[disabled].action.paginate:hover, .registration-form button[disabled].continue:hover, [disabled].button:hover,
button[disabled]:hover,
input[disabled][type="submit"]:hover, nav.lander section.search input[disabled][type="submit"]:active, section.jobs button[disabled]:active, button[disabled].action.paginate:active, .registration-form button[disabled].continue:active, [disabled].button:active,
button[disabled]:active,
input[disabled][type="submit"]:active, nav.lander section.search input.disabled[type="submit"], section.jobs button.disabled, button.disabled.action.paginate, .registration-form button.disabled.continue, .disabled.button,
button.disabled,
input.disabled[type="submit"], section.jobs button.disabled:hover, .disabled.button:hover,
button.disabled:hover,
input.disabled[type="submit"]:hover, section.jobs button.disabled:active, .disabled.button:active,
button.disabled:active,
input.disabled[type="submit"]:active {
  color: #BBBBBB;
  border-color: #CCCCCC;
  background-color: transparent;
  cursor: not-allowed; }

Is this more efficient than 4 identical blocks with shorter selector lists?

# ? Oct 20, 2014 15:40

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

This is just a guess, but I'd say that if the amount of selectors is the same, so the performance.

But what I don't understand is why you care what generated code looks like, if the source code is clean.

# ? Oct 20, 2014 16:35

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

Wheany posted:

But what I don't understand is why you care what generated code looks like, if the source code is clean.

Because that's what the browser is actually looking at, thus it's the only file that actually has the potential to affect performance.

Whether you string together selectors with commas or repeat code blocks is likely negligible. The bigger issue for performance is being overly specific with your selectors, which happens when you do too much nesting in your sass.

For example, do you absolutely have to do this:

code:

nav.lander section.search input.disabled[type="submit"]

or would:

code:

input.disabled[type="submit"]

or better yet just:

code:

.disabled[type="submit"]

give you the same result? If so, consider cutting back on the nesting to reduce the length of your selectors. Each additional class qualifier or descendant selector adds extra work for the browser.

# ? Oct 20, 2014 16:56

bartkusa: Sep 25, 2005; Air, Fire, Earth, Hope

caiman posted:

Because that's what the browser is actually looking at, thus it's the only file that actually has the potential to affect performance.

Have you measured the performance of your pages, and found CSS is actually the bottleneck?

I've written some terrible CSS, and found it didn't matter even 0.01% compared to my terrible Javascript.

# ? Oct 20, 2014 17:07

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

bartkusa posted:

Have you measured the performance of your pages, and found CSS is actually the bottleneck?

I've written some terrible CSS, and found it didn't matter even 0.01% compared to my terrible Javascript.

No. Since we're talking CSS performance, I'm only talking about CSS-related files. Speaking of site performance in general, CSS is about the last thing to look at.

# ? Oct 20, 2014 17:09

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

caiman posted:

Speaking of site performance in general, CSS is about the last thing to look at.

Yet here we are

# ? Oct 20, 2014 17:31

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

bartkusa posted:

Have you measured the performance of your pages, and found CSS is actually the bottleneck?

I've written some terrible CSS, and found it didn't matter even 0.01% compared to my terrible Javascript.

I've seen a few articles about optimizing yout css and this is always what I've wondered as well. I could see the point of trying to minimize the size of the css file, if you serve google-amounts of data, but at what point does it start to matter if your selector is '.disabled[type="submit"]' instead of 'nav.lander section.search input.disabled[type="submit"]'?

# ? Oct 20, 2014 18:46

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Newf posted:

Yet here we are

It makes a freaking huge difference to any complicated site. If your render times are tight, lovely CSS rules are a great way to make them poo poo the bed, especially on Mobile or old rigs.

My rule of thumb is to pretty heavily use BEM, and only use classes. Why you ask, well every tag only selector you, such as -- .something a { rules } -- requires the browser to traverse every single instance of a .something to find if it has a child a, or the reverse. The flatter you can keep your hierarchy, the less grabby every rule can be requiring far less DOM traversal. On its own its trivial, but it multiplies pretty quickly with a poor approach.

# ? Oct 20, 2014 19:01

Spatulater bro!: Aug 19, 2003; Punch! Punch! Punch!

Newf posted:

Yet here we are

Last on the list, but the list is called Things You Must Look At.

# ? Oct 20, 2014 19:03

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

caiman posted:

Last on the list, but the list is called Things You Must Look At.

Well nuts to me.

# ? Oct 20, 2014 19:17

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Meh, kicking it down the can means you may have to rewrite your CSS and HTML and JavaScript to accommodate the rule changes. Actual separation of concerns is kind of a pipe dream, once you find out your CSS is garbage your usually tacking on a good amount of time to clean house if its critical.

# ? Oct 20, 2014 19:23

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Wheany posted:

Well, I guess I could do [Ember-CLI] too, but I'm kinda not looking forward to doing the same work the third time within a week. But if that is a clean (and supported) way of modularizing an Ember app, it's probably worth at least checking out.

Hmm, I like parts of the project structure, it seems to be mostly compatible with our current thing, except it wants dasherized-filenames and we use CamelCaseNames currently. That is not a huge problem, just rename the files. I also like the idea of using bleeding edge ES6 modules (I'm a web "developer" cowboy coder after all), and our files should be relatively easily convertible because it's usually just (function(){App.WhatEver=Ember.SomeClass.extend}());. I like the resolver automatically loading modules as needed without having to do a bunch of setup like with adding RequireJS. (RequireJS seemed to work fine except I didn't finish the conversion yet and stuff like models did not get loaded in the right order)

It seems that it's kind of a pain in the rear end to convert an existing project into the structure created by "ember init", but I'm going to try.

# ? Oct 24, 2014 12:12

excidium: Oct 24, 2004; Tambahawk Soars

Looking for some ideas and this was the best place to start I think:

My company's software is installed on Windows environments and uses IIS. We have a bunch of component software that makes up our suite of tools and unfortunately the installer process is kind of a huge pain in the rear end. While we are waiting for the platform engineering team to straighten things out and make it a lot easier, I am looking for ways to streamline the developer ramp up time. We are currently using Oracle VM VirtualBoxes with a base set-up of the platform and some other tools. The developer then just runs and works directly on that Host machine.

Problems:
Image size is huge. Downloading for some of the developers that work on this is a pain.
Licensing. We don't have Office installed on the Host machine due to licensing so developers are required to switch back and forth, moving files when necessary to work on Office related items.
Resources. To reliably run the VM you're going to need 8GB of RAM, most likely more. This is fine for most of our guys in the US, but offshore developers have lesser baseline machines and a longer time for upgrade.

Ideally I'd like to see something that runs the VM in the background with a mapped drive to the environment that can be accessed from the Host machine. The Guest should basically just be the smallest Windows image I can get with SQL, IIS and the platform software. This would allow us to hit the associated web server that the Host machine creates to test coding changes before committing them.

Any suggestions would be great!

# ? Oct 27, 2014 18:06

Don Mega: Nov 26, 2005

We are about to implement a front-end framework at my current small company to replace the jQuery spaghetti mess. We were thinking of using Angular, but with the Angular2 core changing so much it seems like a waste of time. Any thoughts?

# ? Oct 27, 2014 18:25

Spraynard Kruger: May 8, 2007

Don Mega posted:

We are about to implement a front-end framework at my current small company to replace the jQuery spaghetti mess. We were thinking of using Angular, but with the Angular2 core changing so much it seems like a waste of time. Any thoughts?

Angular 1.3 just went stable, I think it's a bit early to declare it dead. 2.0 will also be dropping support for older browsers and focusing on the latest versions only, so it might not be a great choice if you need to support a wider range of users.

There will always be hot new frameworks on the horizon, sometimes you just have to pick one and get some work done.

# ? Oct 27, 2014 22:16

geetee: Feb 2, 2004; >;[

I am in love with react. Give that a looksie. Supports IE8+.

# ? Oct 28, 2014 03:26

abraham linksys: Sep 6, 2010

Don Mega posted:

We are about to implement a front-end framework at my current small company to replace the jQuery spaghetti mess. We were thinking of using Angular, but with the Angular2 core changing so much it seems like a waste of time. Any thoughts?

I agree with Spraynard Kruger that Angular will continue to be a viable framework, whether or not the very pie-in-the-sky dreams the team has for Angular 2.0 come to fruition or not.

However, I also agree with geetee that React sounds like your best choice. It's a very good library for rescuing jQuery spaghetti without requiring a restructure of how you handle your app's state or routing.

(also lol @ how outdated the OP became in barely over a year. Oh JavaScript :allears:

)

# ? Oct 28, 2014 04:06

Pollyanna: Mar 5, 2005; Milk's on them.

I want to move on to doing T/BDD in Javascript. Is this book recommended, or there a better reference out there?

# ? Oct 30, 2014 16:26

Wungus: Mar 5, 2004

Let's say I've got four different controllers in Angular, that all look like this

code:

app.controller('theControl', ['$scope', '$http', '$rootScope',
	function ($scope, $http, $rootScope) {

	$scope.url = 'js/json/jsonOne.json';
	
	$http.get($scope.url).then(function(result){
		$scope.instances = result.data;
	})

with the only difference being the word "jsonOne" changing out for, like, "jsonBeta" "peteStinks" and so on. Is there any way of just kind of making a directive that supplies an attribute to the controller, so I could change the scope URL to 'js/json/' + variable + '.json' and only have one of these things cluttering up my code? I'm feeling pretty confident with making directives in general lately, but I have no idea if this is even possible.

# ? Oct 31, 2014 21:36

NtotheTC: Dec 31, 2007

You can specify the controller for the directive using require:

code:

app.directive('myDir', function() {
  return {
    require: '^theControl',
    scope: {
      jsonVar: '@'
    },
    link: function(scope, element, attrs, ctrl) { //ctrl is your controller
      ctrl.variable = scope.jsonVar;
    },
  };
});

I dislike doing this, I personally like the controller to modify the scope of the directive not the other way around. But I'll be honest everyone has a different way of doing things and I'm really not sure mine is the best, so if someone has a better way of solving this I'd be interested too.

# ? Oct 31, 2014 22:57

SuicideSnowman: Jul 26, 2003

You could call a controller function from the directive, either setting the URL or directly calling the function that performs the $http.get:

code:

var app = angular.module('myApp',[]);

app.directive('myDirective', function() {
    return {
        scope: { 
            ctrlFn: '&ctrlFn'
        },
        link: function(scope, element, attrs) {
            scope.ctrlFn();
        }
    }
});

function MyCtrl($scope) {
    $scope.setUrl = function(url) {
        console.log('js/json/' + url + '.json');
    }
}

code:

<div ng-controller="MyCtrl">
    <div my-directive ctrl-fn="setUrl('jsonOne')"></div>
</div>

# ? Nov 2, 2014 06:16

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

If I'm using a Backbone.Router for a single page app, how do I handle redirecting them to the login page if they hit a route that they needed to be authed for?

# ? Nov 3, 2014 23:43

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Ember just announced its roadmap for v2.0. I love Ember, but I only write toy apps so I'm not really qualified to preach. Still, I like their "pave the cowpaths" approach to adding features. I also like how the tooling and documentation are integral parts of the development cycle, and their commitment to minimizing breaking changes. The TL;DR seems to be "aping cool features from React, avoiding the Angular 2.0 clusterfuck."

# ? Nov 4, 2014 00:07

Skiant: Mar 10, 2013

Kobayashi posted:

Ember just announced its roadmap for v2.0. I love Ember, but I only write toy apps so I'm not really qualified to preach. Still, I like their "pave the cowpaths" approach to adding features. I also like how the tooling and documentation are integral parts of the development cycle, and their commitment to minimizing breaking changes. The TL;DR seems to be "aping cool features from React, avoiding the Angular 2.0 clusterfuck."

I think there's a lot of debate regarding the Angular 2.0 syntax presented at ng-europe, they might actually make it much less confusing and esoteric.

# ? Nov 4, 2014 08:24

Pollyanna: Mar 5, 2005; Milk's on them.

Yeoman doesn't seem to be able to locate my generators. I ran yo and selected generator-front-end-basic, which responded with this:

code:

[?] Here's what I found. Install one? generator-front-end-basic
generator-front-end-basic@0.1.0 /Users/rebecca/npm/lib/node_modules/generator-front-end-basic
&#9492;&#9472;&#9472; yeoman-generator@0.14.2 (stuff)


I just installed your generator by running:

    npm install -g generator-front-end-basic

...but it doesn't actually seem to be installed.

code:

Rebeccas-MacBook-Pro-2:flux rebecca$ yo front-end-basic
Error front-end-basic 

You don't seem to have a generator with the name front-end-basic installed.
You can see available generators with npm search yeoman-generator and then install them with npm install [name].
To see the 0 registered generators run yo with the `--help` option.

After some fuckery with figuring out where everything is installed, I discovered that it works just fine if I run it in /Users/rebecca/npm/lib/node_modules:

code:

Rebeccas-MacBook-Pro-2:flux rebecca$ cd /Users/rebecca/npm/lib/node_modules
Rebeccas-MacBook-Pro-2:node_modules rebecca$ yo front-end-basic

     _-----_
    |       |
    |--(o)--|   .--------------------------.
   `---------�  |    Welcome to Yeoman,    |
    ( _�U`_ )   |   ladies and gentlemen!  |
    /___A___\   '__________________________'
     |  ~  |
   __'.___.'__
 �   `  |� � Y `

[?] Author Name: (myself <myself@foo.com>)

What's going on here? Is this a directories issue or is something else the problem?

# ? Nov 6, 2014 17:58

HaB: Jan 5, 2001; What are the odds?

Pollyanna posted:

Yeoman doesn't seem to be able to locate my generators. I ran yo and selected generator-front-end-basic, which responded with this:

code:

[?] Here's what I found. Install one? generator-front-end-basic
generator-front-end-basic@0.1.0 /Users/rebecca/npm/lib/node_modules/generator-front-end-basic
&#9492;&#9472;&#9472; yeoman-generator@0.14.2 (stuff)


I just installed your generator by running:

    npm install -g generator-front-end-basic

...but it doesn't actually seem to be installed.

code:

Rebeccas-MacBook-Pro-2:flux rebecca$ yo front-end-basic
Error front-end-basic 

You don't seem to have a generator with the name front-end-basic installed.
You can see available generators with npm search yeoman-generator and then install them with npm install [name].
To see the 0 registered generators run yo with the `--help` option.

After some fuckery with figuring out where everything is installed, I discovered that it works just fine if I run it in /Users/rebecca/npm/lib/node_modules:

code:

Rebeccas-MacBook-Pro-2:flux rebecca$ cd /Users/rebecca/npm/lib/node_modules
Rebeccas-MacBook-Pro-2:node_modules rebecca$ yo front-end-basic

     _-----_
    |       |
    |--(o)--|   .--------------------------.
   `---------�  |    Welcome to Yeoman,    |
    ( _�U`_ )   |   ladies and gentlemen!  |
    /___A___\   '__________________________'
     |  ~  |
   __'.___.'__
 �   `  |� � Y `

[?] Author Name: (myself <myself@foo.com>)

What's going on here? Is this a directories issue or is something else the problem?

I am completely spitballing, here, but usually when you do any sort of npm install -g you need to sudo it, or it will permission error all over the place.

If you see any red text when installing - do it again, via sudo

# ? Nov 6, 2014 18:23

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Kobayashi posted:

The TL;DR seems to be "aping cool features from React, avoiding the Angular 2.0 clusterfuck."

I appreciate that they openly give props to Angular and React, and don't speak of "other frameworks", for example.

# ? Nov 6, 2014 18:30

NtotheTC: Dec 31, 2007

Angular 2.0 is going "full mobile" right? With browsers as an afterthought? I'm not sure how I feel about that

# ? Nov 6, 2014 19:49

Pollyanna: Mar 5, 2005; Milk's on them.

HaB posted:

I am completely spitballing, here, but usually when you do any sort of npm install -g you need to sudo it, or it will permission error all over the place.

If you see any red text when installing - do it again, via sudo

Doesn't quite explain (i zoned out and didnt finish this part of the post. ignore me)

i noticed that my npm is running from /usr/local/bin/npm, but npm config get prefix was set to /Users/rebecca/npm. I changed it to /usr/local/lib/node_modules/npm. Now the Backbone generator is getting installed to /usr/local/lib/node_modules/npm/lib/node_modules/generator-backbone... and I have a feeling that means it's the wrong directory :gonk:

What directories am I expected to have for Yeoman?

edit: I ultimately removed everything npm/node related from my computer and reinstalled using Homebrew. Everything works now!

Pollyanna fucked around with this message at 20:22 on Nov 6, 2014

# ? Nov 6, 2014 19:55

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

So ES6 modules are in strict mode by default, right?

That means that in a file like this:

JavaScript code:

import cheek from "buttock";

var butt = function () {
	return cheek(2):
};

export default butt;

...the butt function is also in strict mode, right?

Because JSHint is complaining to me about missing "use strict" in the function. I have the esnext-option set to true.

# ? Nov 6, 2014 20:17

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Okay, so running the latest jshint (2.5.10) from the command line seems to work as expected, but the one bundled with Idea (2.5.6) doesn't work :mad:

e: Nope, that wasn't it. Even version 2.5.6 works from the command line. :confused:

e2: enabled "use config files" and now it works even in Idea :iiam:

Wheany fucked around with this message at 19:38 on Nov 7, 2014

# ? Nov 6, 2014 20:36

Adbot: ADBOT LOVES YOU

# ? May 17, 2024 08:31

Okita: Aug 31, 2004; King of toilets.

Just thought I'd share something for people who don't like the RequireJS AMD style:

Check out grunt-concat-in-order.

You can basically include comments at the top of your JS files listing dependencies and it will generate a dependency graph and concat your JS src files in the correct order.
To enable this mode you need to set the options in your gruntfile a certain way. It's described at the bottom of the npm readme page for the package.

The result is way more readable code:

code:

/**
 * @depend Graphics.js
 * @depend StateManager.js
 * @depend States/Boot.js
 * @depend States/Title.js
 * @depend States/MainMenu.js
 */

var SmifUI = SmifUI || {};
(function () {
    var core = Class.extend({
        init: function (canvas, fps) {
            this.graphics = new SmifUI.Graphics(this, canvas);
            this.states = new SmifUI.StateManager(this);

            this.states.add(new SmifUI.States.Boot(this.states, "boot"));
            this.states.add(new SmifUI.States.Title(this.states, "title"));
            this.states.add(new SmifUI.States.MainMenu(this.states, "mainmenu"));
        },
        start: function () {
            this.states.load("boot");
        }
    });

    SmifUI.Core = core;
})(SmifUI);

# ? Nov 11, 2014 15:35

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

«‹›235 »