Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript: The Right Way

jstherightway.org

Post reply on HN
Print view View original

71–80 of 136 posts

Re: JavaScript: The Right Way

#71

Post by marknutter »

Silhouette wrote: post #66
marknutter wrote: post #51

Earlier quoted context omitted.

> 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 bec…

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. That's a rather negative view, and I don't think it's entirely realistic. I am involved with multiple long-running web proje…

> We know that some are merely short cuts aimed at people who now work in front-end development but whose backgrounds aren't necessarily in programming and who haven't yet developed their general software development skills in that way; there's nothing wrong with that, of course, but such tools have no (or negative) value to those who have moved beyond the level where they are helpful.

No, they are aimed at people who have worked in front-end development for a long time and whose backgrounds are in programming precisely because they are sick of reinventing the wheel every time they start a new project and are able to understand the technical value behind concepts modern frameworks give us like dependency injection, unit/e2e testing, modularity, and separation of concerns. The myth that front-end developers are not "necessarily from a programming background" is poisonous thinking and it unfortunately usually comes from older programmers or non-front-end developers; the very people who could help guide the front-end world into maturity.

Re: JavaScript: The Right Way

#72

Post by test1235 »

TheZenPsycho wrote: post #29
manish_gill wrote: post #23

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…

There's a lot of choices, and that's not a bad thing necessarily. Javascript is in a heavy growth period right now. But I totally get the choice overload thing. There's a lot of people interested in javascript from all different areas of computer land, and they all have different ideas of what "best" is, and they all want to make javascript more like lisp, or more like ruby, or more like java, or more like c# or more…

If you're starting out from new, I'd argue you can make do with the templating in underscore instead of adding another library.

http://underscorejs.org/#template

Re: JavaScript: The Right Way

#74

Post by Silhouette »

marknutter wrote: post #71
Silhouette wrote: post #66

Earlier quoted context omitted.

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. That's a rather negative view, and I don't think it's entirely realistic. I am involved with multiple long-running web proje…

> We know that some are merely short cuts aimed at people who now work in front-end development but whose backgrounds aren't necessarily in programming and who haven't yet developed their general software development skills in that way; there's nothing wrong with that, of course, but such tools have no (or negative) value to those who have moved beyond the level where they are helpful. No, they are aimed at people wh…

sick of reinventing the wheel every time they start a new project and are able to understand the technical value behind concepts modern frameworks give us like dependency injection, unit/e2e testing, modularity, and separation of concerns.

You write as if we didn't understand the technical value of those things before a couple of years ago when the current crop of JS frameworks arrived, and as if using one of those frameworks is somehow necessary to achieve them.

In reality, everything you mentioned has been widespread in other software development fields for decades. It's stuff the junior guy on the team learns in his first few months.

Moreover, I think there is a reasonable argument that of your chosen examples, testing is the only one that has sufficiently common requirements for building large but general tools to be worthwhile. The other design principles are valuable, but how best to use them will be highly project-specific, and therefore any widely useful framework will tend to be over-engineered and over-generalised for most applications. See also the Java nightmare I mentioned previously, the trend toward lightweight frameworks on the server side, etc.

Edited to add:

The myth that front-end developers are not "necessarily from a programming background" is poisonous thinking and it unfortunately usually comes from older programmers or non-front-end developers; the very people who could help guide the front-end world into maturity.

There is a difficulty in the industry that significant numbers of people are coming into this kind of front-end development from some sort of HTML/CSS and/or design background. They used to use a bit of JS here and there that they copied off a demo site to get their buttons to animate, and now they're being asked to move into more of a mainstream programming role, but neither they nor the people asking them necessarily appreciate what that involves.

That's not anyone's fault. It will be fixed over time as the industry matures, both because knowledge will spread and because more specialised roles than "front end developer" will probably evolve. But right now, today, it is the situation in large parts of the industry.

Re: JavaScript: The Right Way

#75

Post by Silhouette »

acjohnson55 wrote: post #59
exodust wrote: 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…

Do people write rich server-side web apps in Plain Ol' Python?

Perhaps not, but plenty of us write them using a lightweight framework like Flask rather than heavyweights like Django, and even in a relatively mature field like ORMs, there are downsides to using them that sometimes outweigh the advantages.

For a tiny app, sure, maybe it's not so bad to just use jQuery.

I've got ~100,000 lines (before minimising etc.) and ~5 years of successful maintenance "just using jQuery" for one web app that I can quickly check from here that is still going strong. I think most of us would agree that's not a tiny single page application.

Re: JavaScript: The Right Way

#77

Post by revskill »

Javascript is the bare tool, in order to build abstraction, you need science, i mean something like algorithmic way in rendering view with framework like React framwork, it makes sense because it makes all developer around it thinks in the same way. It's the right way to do all successful thing.

Re: JavaScript: The Right Way

#78

Post by usablebytes »

Excellent work there. I always wanted to work on such a public collection but kudos to these guys on making it a reality. I've used/read-about/tried-out most of the stuff listed there and appreciate the hardwork that has gone into putting all of it together.

I think Polymer (Google) and Brick (Mozilla) deserves a mention there as Web Components have a very high possibility of becoming the ultimate way for the future of web development.

Re: JavaScript: The Right Way

#79

Post by mcdougle »

sjs382 wrote: post #61
TheZenPsycho wrote: post #29

Earlier quoted context omitted.

There's a lot of choices, and that's not a bad thing necessarily. Javascript is in a heavy growth period right now. But I totally get the choice overload thing. There's a lot of people interested in javascript from all different areas of computer land, and they all have different ideas of what "best" is, and they all want to make javascript more like lisp, or more like ruby, or more like java, or more like c# or more…

And definitely replace jQuery with Zepto (which is more-or-less a drop-in replacement), if you have control of the client (non-IE) or especially are working in mobile.

I've not heard of Zepto. Out of curiosity, why use it over jQuery?

Re: JavaScript: The Right Way

#80

Post by SkyMarshal »

sjs382 wrote: post #61
TheZenPsycho wrote: post #29

Earlier quoted context omitted.

There's a lot of choices, and that's not a bad thing necessarily. Javascript is in a heavy growth period right now. But I totally get the choice overload thing. There's a lot of people interested in javascript from all different areas of computer land, and they all have different ideas of what "best" is, and they all want to make javascript more like lisp, or more like ruby, or more like java, or more like c# or more…

And definitely replace jQuery with Zepto (which is more-or-less a drop-in replacement), if you have control of the client (non-IE) or especially are working in mobile.

I wouldn't say "definitely". Even Foundation has gone back to jQuery.
Post reply on HN