Live data from Hacker News

JavaScript: The Right Way

jstherightway.org

51–60 of 136 posts

Re: JavaScript: The Right Way

#51
post #50

Is there a "too clever" mentality in frontend web dev culture of late? An overly fragmented workflow toolset? Not sure the cause, perhaps the influx of engineering "computer science disciplined" brains into the frontend world. Or a panicked competitive race to achieve a nirvana dev environment. Or a tendency to think that workflows for large websites with countless modules is the best workflow for a one-page web app.…

> Just using plain JS with Jquery, and perhaps some additional smaller specific plugins/libraires, is enough to do a lot of cool stuff if we're talking "javascript" projects. Then just get a good editor and off you go.

These new tools and frameworks are becoming numerous and popular precisely because for large, complicated front-end applications you can't just get away with using "plain JS with Jquery" without it becoming an unmaintainable mess and writing boilerplate DOM manipulation code all over the place. The only people I meet who have an aversion to these modern JS frameworks are front-end devs who refuse to learn them or server-side devs who hate javascript.

Re: JavaScript: The Right Way

#53
This is JavaScript: The Infinitely Many Ways. Shouldn't the right way remove at least a few options from the table?

I've found a sweet spot for myself, at least for single page apps which is what I work on most of the time. jQuery, Require.js, text.js and JSLint. r.js for building release versions. Those, along with a small "view" class I wrote whose constructor takes an html string, finds all elements with a data-vid attribute and adds properties to itself pointing at those elements. Markup is kept in bite-size html files, loaded by require during development but compiled into the single js file for release. Also, I can't remember the last time I used a jQuery selector.

Re: JavaScript: The Right Way

#54

Hey guys! I see there's a lot of great suggestions and critics here! Since it's an open source project, you can feel free to open a pull request telling which resource you think it's better to be there, or which one should be removed. As well help me correct the grammar errors. I'm from Brazil, and my english is not that good. I'm really glad about all the opinions, and for sure the site will be improved from now on.…

Hey William, nice initiative.

Your page is split in half on the iPhone, check it out. Cheers.

Re: JavaScript: The Right Way

#56
post #26
post #24

Earlier quoted context omitted.

If in doubt, just use Javascript without anything. Maybe add jQuery. All those frameworks may be nice, but as soon as the tools get a distraction, I think it is useful to step back. And JS doesn't really need anything to be useful.

I'd say underscore needs to be there too

These days, think Lodash is the better pick.

Re: JavaScript: The Right Way

#57
post #8

Nice, I like what you're trying to do, but things like "Backbone.js: The most popular JS client-site framework" worry me. Most people I talk to avoid Backbone nowdays in favour of the other popular frameworks. Also: some descriptions appear to be lacking/missing & you definitely should mention Grunt under "Helpers". At least it's a GH repo and I assume you'll accept PR's? ;)

What are the reasons these people cite for not using Backbone?

As someone who lives and breathes Backbone at the moment, I think its biggest problem is that the framework itself provides not nearly enough guidance to write maintainable and testable code, nor does its documentation. It's not nearly clear how to start your app in a sensible way, where to put stateful non-view, non-model logic, and how the pieces should all communicate. So, you start cobbling your Backbone app together, making architectural decisions as best you can, and then months later, you realize you've created an unmaintainable mess. I've had this experience coming into two large projects so far.

I'm sure everyone's second Backbone app looks a lot better than their first, but it's still an underdesigned framework, IMO. I think Marionette does a lot of good in terms of adding those missing structures and best practices, though. And I'm also intrigued by the idea of replacing views with React components.

Re: JavaScript: The Right Way

#58
post #37

Earlier quoted context omitted.

Plain javascript is nice, but if you're talking about getting a single bit of code to work in N many browsers, the "frameworks" start becoming less optional.

Actually the frameworks don't help in that regard. They are meant for organizing your code, they don't offer any special compatibility. jQuery does that.

and underscore. not for DOM, but for some functional compatibility (map, forEach, etc). Plus, it's convenience methods quickly become indispensable.

_(fn).bind(this), anyone?

Re: JavaScript: The Right Way

#59
post #50

Is there a "too clever" mentality in frontend web dev culture of late? An overly fragmented workflow toolset? Not sure the cause, perhaps the influx of engineering "computer science disciplined" brains into the frontend world. Or a panicked competitive race to achieve a nirvana dev environment. Or a tendency to think that workflows for large websites with countless modules is the best workflow for a one-page web app.…

I think that's a naive way of thinking about the problem. Do people write rich server-side web apps in Plain Ol' Python? Of course not. Why reinvent the wheel?

For a tiny app, sure, maybe it's not so bad to just use jQuery. But if you're working on something with a very rich front-end architecture, a framework gives you a very necessary...er...framework to use to eliminate boilerplate and organize your work. Not only that, but you get to minimize your code debt to your actual business logic, not the plumbing.

Re: JavaScript: The Right Way

#60

Having recently started getting into Javascript, I have to say it is the most confusing ecosystem ever. Learning the basics of the language is easy enough, but as soon as you start trying to create a non-trivial application, bam, you're hit with information overload - X framework, Y library. It's different from Python, Ruby et all because at least with them, there are good consistent popular choices that you can rely…

Basically it boils down to what you want to do. If you know you’re replacing many parts of your page with data you have to load, use a framework like angular, backbone, ember, … If you visualize data, use d3. If you need to animate some UI elements but don’t need much else, use jQuery. Else use plain JS, maybe with some shortcuts like function $(sel) { return document.querySelector(sel) }. maybe with underscore.js if…

browserify, +1.
Post reply on HN