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

Frameworkless JavaScript

moot.it

Post reply on HN
Print view View original

181–190 of 190 posts

Re: Frameworkless JavaScript

#181

Post by jheriko »

mattmanser wrote: post #113
jamesbritt wrote: post #99

Earlier quoted context omitted.

On the other hand, now that I have had the experience of leading teams of JavaScript developers, I know first hand the value of building a project on top of a common base that is readily familiar, well documented and easy to pick up by outsiders. Yes, but choose wisely. :) Back in the late '90s I worked for a company that had their own home-grown Java Web application framework. It was conceptually clean, ran fast, an…

I worked somewhere with a similar brilliant framework. It was so much easier, etc., etc. Similar sort of genius auto-loading thing. XML/XSLT. Could slap stuff together fast. I could make those XSLTs sing man. I made a pivot table out of XSLT, no shit. It was amazingly fast compared to the IE7 javascript engine. Orders of magnitude on masses of data, it actually was amazing. Know how many times Ive used my crazy mad X…

> And when they left your company, those talented developers suddenly found themselves 3-5 years behind people who would previously have been their equal.

Domain specific knowledge doesn't cause this. If you are limited by how much of it you have or don't have then you have a long way to come as a programmer... having used a language or framework before is only really useful so that you don't get snagged by gotchas or weird and wonderful eccentricities of the framework or language.

In reality getting employed is more difficult without experience on a CV, but if you are intelligent and can get an interview its not usually a problem - smart people know, or can be taught quickly, the lack of value specific experience has in most contexts (i.e. anything where you aren't just urgently crunching something out of the door). :)

Re: Frameworkless JavaScript

#182

Post by Aardwolf »

As nice as the frameworkless javascript of that website may be, I had to turn off javascript to properly read the content of that website, because otherwise it made the page title flash in a distracting way to say "Someone is writing...".

Re: Frameworkless JavaScript

#183

Post by antihero »

acdha wrote: post #151
antihero wrote: post #69

Earlier quoted context omitted.

The magic of CDNs is caching. So, if you are using, for instance, the URL "//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has already visited a bunch of sites which are using that URL for their jQuery (highly likely), it means that there is no re-download because the browser already has the DNS and JS cached. Perhaps one extra hit to check for a 302 (and sometimes not even), so the thing about CDNs…

> So, if you are using, for instance, the URL "//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has already visited a bunch of sites which are using that URL for their jQuery (highly likely), it means that there is no re-download because the browser already has the DNS and JS cached. Have you actually measured this? I've found that the results are lot murkier because not every site uses the same CDN…

Ok, but trade that off against the latency for sending cookies and whatnot, and I think the difference is likely trivial.

If we look at the headers for jQuery 2.0.3, we get Expires:Thu, 31 Dec 2037 23:55:55 GMT, which means that it will not expire.

You make a good point in the fact that mobile won't have so much room to cache, however, I'd imagine this will increase as devices get more space and whatnot - in Android 4.4 with the latest Chrome Beta, I tried a few sites I'm using CDN on and got 304 for pretty much all CDN'd stuff:

http://files.blackflags.co.uk/officenumbers.herokuapp.com.ha...

So what I'm saying really is I think that whilst you have good arguments, I think that things are continuing to get better and better :)

That said, once everyone's on LTE, perhaps we don't even have to care ;)

Re: Frameworkless JavaScript

#185

Post by sreyaNotfilc »

peterhunt wrote: post #103

These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas. This type of thinking is going to hold back frontend web development as a whole unless we address it. Disclaimer: I am on the React team. "API first" -- just layer your API on top of whatever you're using to implement it…

"By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app."

Boom Baby!

Sorry, I just love how you picked up on that. Yeah, lets complain about size of our code, but hey look at my pretty high-res image!

"The lady doth protest too much, me thinks".

Anyway, at the end of the day its about creating an experience that gets the job done (and ultimately get more $$$ in your pocket). Many of the problems I see (here and in the office) are debates on which framework is the best for this and that. Though those are good debates to have, one shouldn't sacrifice the end goal for the "proper" software solution.

Jobs said it best here... http://www.youtube.com/watch?v=FF-tKLISfPE

Re: Frameworkless JavaScript

#186

Post by tim333 »

bad_user wrote: post #130
kllrnohj wrote: post #125

Earlier quoted context omitted.

> "Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it I would disagree with this within reason. Code reuse affects YOU the developer. Byte size, however, affects your USERS . Things that impact your users are far more important than things that affect your development zen. Obviously the two are not entirely independent and a ba…

Code reuse or the lack thereof also affects the users, because there is more potential for bugs. Reinventing the wheel may be warranted, the end result may actually be more stable depending on who works on that wheel reinvention, but lets not kid ourselves - every line of code written increases the potential for bugs and there's nothing that affects the user experience more than a broken app. Besides, bytes count is…

> E.g. when importing a library like JQuery, you're paying for a lot of crap in it that you don't need.

Although a plus of something like jQuery, if you get it off google's cdn, is that probably most users will already have it sitting on their disk so you they won't actually need to download it. It gets cached by default for up to a year.

Re: Frameworkless JavaScript

#187

Post by acdha »

antihero wrote: post #183
acdha wrote: post #151

Earlier quoted context omitted.

> So, if you are using, for instance, the URL "//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has already visited a bunch of sites which are using that URL for their jQuery (highly likely), it means that there is no re-download because the browser already has the DNS and JS cached. Have you actually measured this? I've found that the results are lot murkier because not every site uses the same CDN…

Ok, but trade that off against the latency for sending cookies and whatnot, and I think the difference is likely trivial. If we look at the headers for jQuery 2.0.3, we get Expires:Thu, 31 Dec 2037 23:55:55 GMT, which means that it will not expire. You make a good point in the fact that mobile won't have so much room to cache, however, I'd imagine this will increase as devices get more space and whatnot - in Android…

> So what I'm saying really is I think that whilst you have good arguments, I think that things are continuing to get better and better :)

Yeah, I don't want to come across as a complete downer on this – the situation is easily better than it's ever been with CDNs becoming not just available but cheap, distributed DNS a turnkey service, etc. etc. Working on a global website for awhile has definitely reminded me that performance / reliability work hits diminishing returns unless you have have near-Google budget.

> That said, once everyone's on LTE, perhaps we don't even have to care ;)

Didn't we used to say that about 3G? ;)

https://docs.google.com/presentation/d/1IRHyU7_crIiCjl0Gvue0... does look appealing, though

Re: Frameworkless JavaScript

#188

Post by bad_user »

tim333 wrote: post #186
bad_user wrote: post #130

Earlier quoted context omitted.

Code reuse or the lack thereof also affects the users, because there is more potential for bugs. Reinventing the wheel may be warranted, the end result may actually be more stable depending on who works on that wheel reinvention, but lets not kid ourselves - every line of code written increases the potential for bugs and there's nothing that affects the user experience more than a broken app. Besides, bytes count is…

> E.g. when importing a library like JQuery, you're paying for a lot of crap in it that you don't need. Although a plus of something like jQuery, if you get it off google's cdn, is that probably most users will already have it sitting on their disk so you they won't actually need to download it. It gets cached by default for up to a year.

Sure, didn't mean to pick on JQuery, it was a random example and indeed, Google's CDN link is so popular that many users have it cached.

Re: Frameworkless JavaScript

#189

Post by mattgreenrocks »

collyw wrote: post #98
Zelphyr wrote: post #48

Earlier quoted context omitted.

You touch on the one things that frameworks are actually good for: prototyping. Unfortunately they're never just used for that purpose. The prototype and all the framework cruft is then called "the product" and used as such. And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how…

Prototypes always end up in production, framework or not.

I've seen this happen over over to the point where work prototypes are not terribly removed from production code.

I prototype slower, but nobody cares.

Re: Frameworkless JavaScript

#190

Post by collyw »

mattgreenrocks wrote: post #189
collyw wrote: post #98

Earlier quoted context omitted.

Prototypes always end up in production, framework or not.

I've seen this happen over over to the point where work prototypes are not terribly removed from production code. I prototype slower, but nobody cares.

I just try to write production quality prototypes these days. Django is a godsend for writing maintainable solid agile database applications.
Post reply on HN