Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »

leftist heap: Feb 28, 2013; Fun Shoe

NtotheTC posted:

I don't do much javascript/front-end stuff, but I was watching Ember.js vs angular.js and at the start, the Ember guy talks about server-side programming adding "unavoidable latency" to web applications and touting Ember.js as a replacement. maybe I'm missing something but how exactly can you replace server-side code with a javascript library? Surely even if you use Ember to get data from the server, there will still be latency in displaying it, coupled with the fact that now you're using loving javascript to manipulate the data.

I can see the benefits of both those libraries when it comes to bindings, they both look quicker and easier to use than jQuery, but really what is their role in the grand scheme of things?

Well, "loving JavaScript" is pretty darn fast these days. Fast enough that it's probably going to be faster than even the round trip to a server for even fairly complex tasks.

For my last couple projects I moved a ton of the validation and business logic onto the client layer, and the server layer became a pretty dumb REST service.

# ? Sep 2, 2013 16:24

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 03:55

NtotheTC: Dec 31, 2007

I'm not familiar with how validation works in the case of a .js framework. If you're using ember.js say to do validation on the client side in the browser, and the user has control of their browser, what's to stop them bypassing your validation and getting malicious data into the (now completely un-validated) dumb REST backend?

# ? Sep 2, 2013 16:35

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

NtotheTC posted:

I'm not familiar with how validation works in the case of a .js framework. If you're using ember.js say to do validation on the client side in the browser, and the user has control of their browser, what's to stop them bypassing your validation and getting malicious data into the (now completely un-validated) dumb REST backend?

Dude, you are totally forgetting the first rule of web programming: Always trust the client. Wai

# ? Sep 2, 2013 18:31

abraham linksys: Sep 6, 2010

NtotheTC posted:

I'm not familiar with how validation works in the case of a .js framework. If you're using ember.js say to do validation on the client side in the browser, and the user has control of their browser, what's to stop them bypassing your validation and getting malicious data into the (now completely un-validated) dumb REST backend?

You don't use a completely dumb REST backend. You use server-side validations as usual.

For example, Firebase has a security rules DSL to do validation/authorization with minimal overhead: https://www.firebase.com/docs/security/security-rules.html

# ? Sep 2, 2013 19:01

smug forum asshole: Jan 15, 2005

NtotheTC posted:

what's to stop them bypassing your validation and getting malicious data into the (now completely un-validated) dumb REST backend?

"dumb" as in "not completely dumb, but dumb enough that some significant work can/should be pushed to the front-end."

# ? Sep 3, 2013 05:57

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Does anyone here have an opinion about TypeScript?

One of the C#-centric guys here is pushing it pretty hard as a 'better' way to write JavaScript, but I'm skeptical because I think he just doesn't want to learn JS proper and because another guy on the team told me he got some actually wrong output from the TS compiler, though I didn't see this myself to confirm it. Oh, and this guy also thought Dart was pretty great, soooo, yeah.

# ? Sep 3, 2013 15:59

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

TypeScript'a a superset of Javascript, so trying to use it to avoid learning JS would be rather foolish.

It's one of the better compiles-to-JS langauge, and if you're writing a lot of JS and don't like CoffeeScript-style languages I would strong recommend it.

# ? Sep 3, 2013 16:02

Quebec Bagnet: Apr 28, 2009; mess with the honk
you get the bonk; Lipstick Apathy

As a C# guy, my opinion of TypeScript is that it is awesome. It's definitely had some growing pains but the designers have been very straightforward with what is broken and how they're going to fix it. It's pretty solid now, they're preparing for a stable 1.0 release.

As Plorkyeran said it's a strict superset of JavaScript. You can start using it today with your existing code and migrate to TS as you feel comfortable.

# ? Sep 3, 2013 16:20

leftist heap: Feb 28, 2013; Fun Shoe

smug forum rear end in a top hat posted:

"dumb" as in "not completely dumb, but dumb enough that some significant work can/should be pushed to the front-end."

Exactly. Basically the back-end validation is just enough to ensure business rules aren't broken. I don't worry about input that might cause, say, a constraint violation exception in the database or something like a number format exception. If you're bypassing the client side validation and shooting random bits of JSON at the server I have no problem serving you a big fat 400 error.

Munkeymon posted:

Does anyone here have an opinion about TypeScript?

One of the C#-centric guys here is pushing it pretty hard as a 'better' way to write JavaScript, but I'm skeptical because I think he just doesn't want to learn JS proper and because another guy on the team told me he got some actually wrong output from the TS compiler, though I didn't see this myself to confirm it. Oh, and this guy also thought Dart was pretty great, soooo, yeah.

I would push back pretty drat hard on any X-to-JS tool if I had any say in the matter. It's been my experience that people who don't want to learn JS and instead suggest "Hey we can just use this language that compiles to JS. It's just like JS, but it includes all the trappings I need to feel comfortable in a language!" are bad people.

# ? Sep 3, 2013 17:53

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Where does this whole "I don't want to learn JS" perception come from? I know JS well, and that's why I don't want to use it given other options. ClosureScript and Dart are the only compiles-to-JS language I've seen that even pretend to try to be usable by someone who doesn't already know JS.

# ? Sep 3, 2013 19:29

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Plorkyeran posted:

Where does this whole "I don't want to learn JS" perception come from? I know JS well, and that's why I don't want to use it given other options. ClosureScript and Dart are the only compiles-to-JS language I've seen that even pretend to try to be usable by someone who doesn't already know JS.

Because TS lets you hide all the prototypal inheritance mechanisms under a class and interface veneer that C#/Java/C++ people can understand without having to know what's actually going on. It seems to replace boilerplate A with boilerplate B because we have tools that can work with boilerplate B without a lot of modification and people who don't want to understand how A works, anyway.

I'm already imagining having to have an argument about something like this:

code:

function printTheThing(thing: string){
    // blah blah blah
}
//is significantly worse than:
function printTheThing(thing: any){
    thing = thing.toString();
    // blah blah blah
}

Which pure, well-written JS would just pave right over as being obvious.

It helps to have worked with these guys and see how they think, but I'm worried that they're going to try to turn anything they touch into (strongly-typed everywhere no exceptions) C#Script and get offended when I point out that it'd be less annoying for everyone else if they'd just let go a little bit.

Other than all that, it does actually look pretty nice

# ? Sep 3, 2013 20:07

Deus Rex: Mar 5, 2005

Munkeymon posted:

I'm already imagining having to have an argument about something like this:
code:
function printTheThing(thing: string){
    // blah blah blah
}
//is significantly worse than:
function printTheThing(thing: any){
    thing = thing.toString();
    // blah blah blah
}

in what possible universe is the first way significantly worse than the second? the second will throw runtime errors on anything which does not have a toString() method. Catching errors at compile time is always better :ssh:

Deus Rex fucked around with this message at 20:18 on Sep 3, 2013

# ? Sep 3, 2013 20:14

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Deus Rex posted:

in what possible universe is the first way significantly worse than the second? the second will throw runtime errors on anything which does not have a toString() method. Catching errors at compile time is always better

In the universe where any caller to that function might have to explicitly call toString instead of letting the display code do it in one place for everyone. The universe we currently exist in, in other words.

What universe do you exist in where people are removing the toString function from JS objects? Sounds like a terrible place :P

I'll grant that it wasn't a terrific example, but in a language without function overloading, type checking arguments can and will lead to annoying poo poo that I don't want to deal with.

# ? Sep 3, 2013 20:27

Deus Rex: Mar 5, 2005

Munkeymon posted:

In the universe where any caller to that function might have to explicitly call toString instead of letting the display code do it in one place for everyone. The universe we currently exist in, in other words.

What universe do you exist in where people are removing the toString function from JS objects? Sounds like a terrible place :P

I'll grant that it wasn't a terrific example, but in a language without function overloading, type checking arguments can and will lead to annoying poo poo that I don't want to deal with.

Okay, so make a structural type that checks for a method toString of type string, and use that in the function argument.

# ? Sep 3, 2013 20:38

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Deus Rex posted:

Okay, so make a structural type that checks for a method toString of type string, and use that in the function argument.

Yes, I get that that would work, but thing: string is something I can easily see my coworkers doing and then getting defensive about when I call them on it and some part of me wants to make them use JS as ~~god~~Eich intended to avoid the whole issue.

# ? Sep 3, 2013 22:20

Deus Rex: Mar 5, 2005

Munkeymon posted:

Yes, I get that that would work, but thing: string is something I can easily see my coworkers doing and then getting defensive about when I call them on it and some part of me wants to make them use JS as ~~god~~Eich intended to avoid the whole issue.

Point taken. I prefer to write TS to interfaces rather than primitive types whenever possible. But I've only ever written toy projects in TS, never anything substantial. Truthfully I don't know if the static typing becomes a PITA on larger projects, but my experience with static/dynamic typing in general is that the opposite is true. Plus you can always just : any everything :haw:

# ? Sep 4, 2013 00:15

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

I've been looking at this for an hour and I'm having trouble clarifying just how document.height vs scrollHeight versus $('html').Height etc. and how they work. I'm trying to set a div's height to be the total height of the page as it contains a background element (linear gradient, to right, etc.). And it seems I'm getting wildly different results. This is basically how my function is set up:

code:

$(function () {
    var TotalHeight = $(document).height();
    $('#testgrad').css({ 'height': (TotalHeight) + 'px' });
});

I'm pretty sure this is firing after page load, since I'm actually calling it with require.js after a 15ms delay.

testgrad being my gradient div. If I use $(document).height(); as in the example above, on some pages I'll get pretty close to the 'real' (e.g. visible, scrollable) height and on others I'll a few thousand pixels extra. What seems to be happening is if the length is > 4338 pixels, it mostly works. If the height is < 4338 pixels, it always returns 4338 regardless of how much content is present.

When using document.body.scrollHeight; it works most of the time, but is also fixated on 4338. The bizarre thing is it 'works' with pages that don't work with (document).height() above, but will still report far too large a height (usually 4338) on others.

The impression I'm getting is 4338 is some magic number specific to my layout that is getting shoved in there when when jquery can't figure it out/it's trying to access the height before the browser has finished rendering. I thought it might be absolutely positioned elements but after running a relatively comprehensive script from this SO question (near the bottom):
http://stackoverflow.com/questions/16928101/finding-the-full-height-of-the-content-of-a-page-document-that-can-have-absolute

I get even worse results (value returned is much too small). I'm also clearing my floats appropriately. Regardless of my actual application (e.g. stretching the div), is there a 'right' way to access the height that I'm missing out on?

EDIT-And once again, as soon as I post the question I figure it out. It seems no matter what I do with delays it wouldn't get the right values, but putting the call to grab (document).height in (window).load seems to have fixed it instead of document.ready.

Scaramouche fucked around with this message at 00:57 on Sep 5, 2013

# ? Sep 5, 2013 00:26

Bognar: Aug 4, 2011; I am the queen of France; Hot Rope Guy

Is this really something that can't be done with css and position: fixed?

http://jsfiddle.net/mnha3/

Edit: I think I misunderstood, you're trying to do the whole page and not the whole window. Still, though, can it not be done with CSS instead?

Bognar fucked around with this message at 01:29 on Sep 5, 2013

# ? Sep 5, 2013 01:26

MrDoDo: Jun 27, 2004; You better remember quick before we haul your sweet ass down to the precinct.

I have been fiddling around with JS MVCs these days. Primarily Ember and have been really liking it so far. I took a look around it noticed questions on MVCs were being asked in here. Would anyone else find merit in creating a separate thread to discuss them?

# ? Sep 7, 2013 02:47

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

MrDoDo posted:

I have been fiddling around with JS MVCs these days. Primarily Ember and have been really liking it so far. I took a look around it noticed questions on MVCs were being asked in here. Would anyone else find merit in creating a separate thread to discuss them?

I just started toying around with Ember myself, working through the "getting started" tutorial. It'd be great if there were more beginner tutorials, because for a total neophyte, that poo poo's complicated.

# ? Sep 9, 2013 21:43

BusError: Jan 4, 2005; stupid babies need the most attention

Kobayashi posted:

I just started toying around with Ember myself, working through the "getting started" tutorial. It'd be great if there were more beginner tutorials, because for a total neophyte, that poo poo's complicated.

I just finished watching PeepCode's Ember tutorial this weekend and thought that it did a great job of getting the core concepts into my brain. It's slightly outdated now that 1.0 is out, but the concepts all still apply as far as I can tell. Downside is it's $12, but I've got a PeepCode subscription so that didn't matter

# ? Sep 9, 2013 23:03

leftist heap: Feb 28, 2013; Fun Shoe

I'd love to hear some thought's on Ember from someone with significant Angular experience. I'm really growing to hate Angular.

# ? Sep 9, 2013 23:20

MrDoDo: Jun 27, 2004; You better remember quick before we haul your sweet ass down to the precinct.

rrrrrrrrrrrt posted:

I'd love to hear some thought's on Ember from someone with significant Angular experience. I'm really growing to hate Angular.

This video does a fairly decent side by side example of Ember vs Angular. It does seems to play up Ember a bit, but that might be because the person presenting the "Angular side" doesn't sell it very well.

Kobayashi posted:

I just started toying around with Ember myself, working through the "getting started" tutorial. It'd be great if there were more beginner tutorials, because for a total neophyte, that poo poo's complicated.

Check out the updated video by Tom Dale on Embers getting started page if you haven't already. I felt it did a much better job coming at things fresh than the other one did.

# ? Sep 9, 2013 23:45

leftist heap: Feb 28, 2013; Fun Shoe

I took a skim through that video. It looks like they're essentially building a toy example. It's really not much of an app if you don't have to write your own directives.

# ? Sep 9, 2013 23:57

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

we've switched to angular at work and although I've managed to avoid having anything to do with it i am finding it really hard to believe that the building of webpages needs to be this complex.

or at least it sure seems complex for something that should be pretty straightforward.

# ? Sep 10, 2013 04:53

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

maybe it's not really complex idk

# ? Sep 10, 2013 04:54

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

MrDoDo posted:

This video does a fairly decent side by side example of Ember vs Angular. It does seems to play up Ember a bit, but that might be because the person presenting the "Angular side" doesn't sell it very well.

Check out the updated video by Tom Dale on Embers getting started page if you haven't already. I felt it did a much better job coming at things fresh than the other one did.

Well, I'm not an engineer by trade, so I may be way off, but I'm having a really hard time building up my mental model of how an Ember app is supposed to be structured. I'm used to explicitly declaring variables and hooking everything up manually. Ember seems to provide a lot of scaffolding by default, which I take to be the point, but which can also be magically overridden by following the right naming convention. So for someone new like me, it's hard to follow what's going on when the examples are littered with nouns that vary in capitalization (Todos vs. todos) or pluralization (Todo vs. todos), all of which are that way for some specific reason. Maybe it's just me, though.

# ? Sep 10, 2013 05:18

leftist heap: Feb 28, 2013; Fun Shoe

rotor posted:

we've switched to angular at work and although I've managed to avoid having anything to do with it i am finding it really hard to believe that the building of webpages needs to be this complex.

or at least it sure seems complex for something that should be pretty straightforward.

Which parts do you find complex? Not that Angular isn't complex, but some of its complexity is "justified" (in that it's an attempt to reduce the incidental complexity of lower level forms of JS web development) while some of it is Angular's own incidental and baked in complexity (such as the directive model or its ridiculous scoping rules).

Lots of things seem straightforward but quickly become complex at any reasonable scale. My experience with JS-heavy front-ends is that a few straightforward jQuery DOM manipulations very quickly turns into a hot mess of selector spaghetti (but hey, I'm also open to the idea that I'm the hot mess). Angular isn't great -- maybe not even good -- but it's at least an attempt at organizing JS webapps into a set of coherent units.

# ? Sep 10, 2013 06:11

The Insect Court: Nov 22, 2012; by FactsAreUseless

rrrrrrrrrrrt posted:

Which parts do you find complex? Not that Angular isn't complex, but some of its complexity is "justified" (in that it's an attempt to reduce the incidental complexity of lower level forms of JS web development) while some of it is Angular's own incidental and baked in complexity (such as the directive model or its ridiculous scoping rules).

Lots of things seem straightforward but quickly become complex at any reasonable scale. My experience with JS-heavy front-ends is that a few straightforward jQuery DOM manipulations very quickly turns into a hot mess of selector spaghetti (but hey, I'm also open to the idea that I'm the hot mess). Angular isn't great -- maybe not even good -- but it's at least an attempt at organizing JS webapps into a set of coherent units.

Here are my rules of thumb to keep in mind while first learning to use angular:
- Use factories. Don't bother learning the differences between factory/service/provider.
- Keep controllers simple. People new to angular seem to want to write huge controllers that have a lot of model logic in them, refactor that stuff into a factory.
- Keep controllers simple. Scope inheritance means the controller of a view defined inside another view has access to the parent controller's scope, a hierarchy of small controllers is better than one huge one.
- Don't share state by sticking stuff on root scopes, use a factory instead.
- Forget about directives.

# ? Sep 10, 2013 11:15

BusError: Jan 4, 2005; stupid babies need the most attention

rotor posted:

we've switched to angular at work and although I've managed to avoid having anything to do with it i am finding it really hard to believe that the building of webpages needs to be this complex.

or at least it sure seems complex for something that should be pretty straightforward.

It sounds like you're saying client-side MVC frameworks as a concept are too complex, which is true if you're doing something simple but becomes not true as whatever you've got running in the browser gets more and more desktop-app-ish.

Same as on the server: Rails (or whatever else like it) is more complex to use than just slapping out a couple lines of PHP if you're doing something really simple, but as soon as your app gets a little complicated, the extra help from the framework is usually worth the extra scaffolding.

But if you're talking specifically about Angular and not about the concept in general, you could be right. I haven't used it, only watched a couple screencasts.

# ? Sep 10, 2013 15:28

leftist heap: Feb 28, 2013; Fun Shoe

The Insect Court posted:

Here are my rules of thumb to keep in mind while first learning to use angular:
- Use factories. Don't bother learning the differences between factory/service/provider.
- Keep controllers simple. People new to angular seem to want to write huge controllers that have a lot of model logic in them, refactor that stuff into a factory.
- Keep controllers simple. Scope inheritance means the controller of a view defined inside another view has access to the parent controller's scope, a hierarchy of small controllers is better than one huge one.
- Don't share state by sticking stuff on root scopes, use a factory instead.
- Forget about directives.

If you forget about directives, what do you do when you want to customize behavior? Or have you been happy with the built in directives? I'm on my second reasonably large application with Angular and I can't imagine not writing custom directives. Actually, I can, it just involves a LOT of scope listeners bound in controllers.

# ? Sep 10, 2013 15:42

Quebec Bagnet: Apr 28, 2009; mess with the honk
you get the bonk; Lipstick Apathy

I've been using Angular for the past 8 months or so on a large client project. The documentation sucks and the most helpful comments on it are "for a clearer explanation, see this Google Groups post/SO answer/blog post/etc". A lot of things are non-obvious and poorly explained, and the in-documentation examples and source code often don't follow their own structure guidelines which made understanding how to build my project extremely challenging.

That said, after figuring it out, I think the concepts of how it organizes modules and directives have serious merit. This is so much nicer than writing jQuery selector and callback soup. Then again, I'm a C# guy writing web apps to fill in a jack-of-all-trades developer role, and having actual structure makes the mental shift from .NET land a lot friendlier. You could build structure yourself, sure, but Angular makes getting there a lot faster. (disclaimer: Angular is only one of two JS application frameworks I've used)

Don't create a page and manipulate it with JavaScript. Instead, create components, and compose a larger application from them. The fact that it's using HTML for the UI should be incidental.
Delegation, delegation, delegation. Create services, define directives, break things up.
DI is brilliant and I'm very happy we have it on the client side now. It Just Works (tm).

# ? Sep 10, 2013 16:59

DholmbladRU: May 4, 2006

Does anyone have experience with google maps api?

I am developing a visualization based off google maps. There are a few requirements the most complicated being rendering different areas on a google map. I need to render a few different sets of polygons based on zoom so maybe country, state, zip etc. It seems as if I will need an array of latitudes/longitudes which outline each of these areas. Are there any resources for these?

I see something called fusion tables which allow users to implement kml shapes on the map. However those dont seem to meet my requirements as I will need to add thresholds to each polygon which is rendered.

Lastly would it be a bad idea to render a large number of polygons. Would you expect me to run into issues? Lets say I render all 50 states, would this cause problems?

This will all be done on the fly and rendered programatically. I will be building these polygons to be renderd based on the contents of a report so what I am rendering can change with each execution.

# ? Sep 10, 2013 17:00

IT Guy: Jan 12, 2010; You people drink like you don't want to live!

Can anyone tell me if there is js library out there that achieves what is currently happening on The Verge: http://live.theverge.com/apple-iphone-5s-liveblog/

I'm specifically talking about the live feed polling and updating.

# ? Sep 10, 2013 18:44

hedgecore: May 2, 2004

RE: MVC-esque JS frameworks above... I've been using backbone.js at a new gig. I have some experience with MV* architectures so the concepts weren't lost on me, but it SEEMED bloated for work.

My first week of thoughts were:
- It's way too complex to justify any benefits that come out of this
- It's not opinionated at all, so I see a thousand ways I can do this but I don't know which one is best
- Marionette? What's that?
- Is the jQuery/selector soup really that bad 99% of the time?

This is the book that did it for me:
http://addyosmani.github.io/backbone-fundamentals/

Then after my first project:
- I wrote a goddamn ton of code and tweaked it a thousand times until I had very few well thought out lines
- There's no point in half assing it
- Building some of these elements kind of makes sense, but this is so heavy
- I think I like underscore.js?
- Was the jQuery/selector soup really that bad?

Now that I just finished my second project:
- Ok, that was way easier, everything makes a lot more sense and I know when to use which Marionette views
- underscore.js is amazing I want it all of the time
- Why on earth was I ever tying data to DOM elements
- It still seems like everything takes 2-3 times as long to set up and write
- I think I replaced $.ajax() correctly using models
- I even used models/collections in a logical way that wasn't tied to a REST API
- I am only going to use this on huge webapps where I am concerned about memory leaks/performance

I am not 100% sure how I feel about backbone.js in general, but I am certainly no longer intimidated by it.
Highly recommend using Marionette, RequireJS, Handlebars, and all that underscore.js has to offer you.

# ? Sep 11, 2013 02:33

The Insect Court: Nov 22, 2012; by FactsAreUseless

rrrrrrrrrrrt posted:

If you forget about directives, what do you do when you want to customize behavior? Or have you been happy with the built in directives? I'm on my second reasonably large application with Angular and I can't imagine not writing custom directives. Actually, I can, it just involves a LOT of scope listeners bound in controllers.

You can get pretty far with the built-in directives, I find. Writing new directives becomes important in larger and more complicated applications, but if the goal is to learn angular and get a simple project or two under your belt, learning the intricacies of writing new directives isn't particularly useful. There's a perception that angular has a very steep learning curve, but just understanding the basics of factories, scopes, and DI allows you to start to get useful stuff done with it.

# ? Sep 11, 2013 03:31

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

What kind of web apps do you guys use MVCs for?

I'm finishing up working on an app for retailers to do inventory control which seems like kind of a big deal but I'm still not sure it would be that much more efficient/effective to use an MVC versus mimicking MVC architecture using jQuery and a basic javascript object data model. I'm also coming at this from a distinctly not CS background so maybe I'm just Doing It Wrong.

# ? Sep 11, 2013 04:47

leftist heap: Feb 28, 2013; Fun Shoe

I don't think using a JS MVC framework is really about being more efficient. Kind of the opposite really. Doing things the "Angular way" is almost always a lot more work than doing things the straight jQuery way, but the end result is (hopefully) easier to understand, reuse and maintain. If you're a disciplined coder and you use straight jQuery in a disciplined way, then it might seem like overkill. If you've ever worked with jQuery soup then it's going to seem like a godsend.

It's a lot like, say, dependency injection in Java. It's going to look unnecessary and overly complicated until you start to consistently run into the problems it attempts to solve. If you never run into those problems (or you just don't recognize them as problems!) then just consider yourself lucky!

# ? Sep 11, 2013 06:01

etcetera08: Sep 11, 2008

rrrrrrrrrrrt posted:

I don't think using a JS MVC framework is really about being more efficient. Kind of the opposite really. Doing things the "Angular way" is almost always a lot more work than doing things the straight jQuery way, but the end result is (hopefully) easier to understand, reuse and maintain. If you're a disciplined coder and you use straight jQuery in a disciplined way, then it might seem like overkill. If you've ever worked with jQuery soup then it's going to seem like a godsend.

It's a lot like, say, dependency injection in Java. It's going to look unnecessary and overly complicated until you start to consistently run into the problems it attempts to solve. If you never run into those problems (or you just don't recognize them as problems!) then just consider yourself lucky!

That's efficiency, just not upfront. You will (hopefully?) spend a lot more time working on your app post-launch than pre-launch, so cost saving at that stage is much more important.

Kind of just arguing semantics, since you basically just said that though. :V

# ? Sep 11, 2013 16:18

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 03:55

Uziel: Jun 28, 2004; Ask me about losing 200lbs, and becoming the Viking God of W&W.

What's the "best" javascript/html IDE right now? I have an upcoming Javascript/HTML5 class starting in a few weeks so I'm looking around. I'm a Visual Studio person and I think Jetbrains is awesome but I see that they have WebStorm for $29 under academic. Is this the best option or is there something out there free that will suit my needs?

# ? Sep 14, 2013 16:18

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »