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

Enough with the JavaScript already

fr.slideshare.net

Post reply on HN
Print view View original

151–160 of 231 posts

Re: Enough with the JavaScript already

#151

Post by tnuc »

andrenotgiant wrote: post #140

Many sites already use Google's hosted javascript libraries for JQuery, Prototype, etc... Could Google reduce load time in Chrome by building these into the browser, so that anytime they see the include pointing to Google CDN, they just skip it and let the pre-included library take its place?

The number and versions of these libraries is just immense.

A lot of what the early versions of these libraries used to do is now handled by upgraded versions of javascript.

Adding JQuery etc. to the browser is a short term fix, that would become a problem further down the track.

Re: Enough with the JavaScript already

#152

Post by dragonwriter »

jiggy2011 wrote: post #149
Slackwise wrote: post #26

Earlier quoted context omitted.

Not just the DOM, HTTP as well. We're shoehorning state into a stateless system, and inventing new crap like WebSockets to overcome limitations of a system designed for document retrieval. The web has turned into the biggest hack ever.

I don't see the point of websockets, why not just let the browser make normal outbound TCP connections?

I think the main points WebSocket vs. unrestricted TCP sockets is:

1. Support for a browser-appropriate security model (origin-based)

2. Not requiring extra work to pass through HTTP-friendly (and everything-else-hostile) firewalls.

Re: Enough with the JavaScript already

#153

Post by olalonde »

andrenotgiant wrote: post #140

Many sites already use Google's hosted javascript libraries for JQuery, Prototype, etc... Could Google reduce load time in Chrome by building these into the browser, so that anytime they see the include pointing to Google CDN, they just skip it and let the pre-included library take its place?

A non negligible downside is that it would give some libraries an "unfair advantage" which might harm innovation.

Re: Enough with the JavaScript already

#154

Post by WiseWeasel »

hobs wrote: post #60
chewxy wrote: post #55

Earlier quoted context omitted.

I work in advertising. I have seen Ghostery rack up close to 300 trackers before. Piggybacked pixels... they're everywhere

How does one even collect the data from 300 trackers?

Your 300 affiliate marketing partners run software from their affiliate network which automatically analyzes their tracking pixel server logs to determine how far the traffic they steered made it through your purchase process based on the pixels they requested (unique for each page) and the unique ID in their cookies. Then, their affiliate network collects the sales commissions and pays out the affiliate partners.

Re: Enough with the JavaScript already

#155

Post by dccoolgai »

flyinRyan wrote: post #126
dccoolgai wrote: post #119

Earlier quoted context omitted.

Try this: date.toLocaleDateString("en-US", {month: "numeric", day: "numeric"});

I want a specific format to our proprietary systems. In C# I can just say "date.Format("dd.MM.YYYY")" or what ever I want.

Granted that's a bit tidier than doing this in JS:

var myProprietaryDateFunction = function(dt) { return dt.getDate()+'.'+dt.getMonth()+'.'+dt.getFullYear(); };

But in JS, you can pass that function around like a village bicycle -when I think back to my C# days, it makes me wonder how I ever did without functions as first class objects and a slew of other really great things about JS. A lot of those things are brainbangers at first, to be sure - but when you finally grasp them (for me, at least) you start to see that the things that make JS "ugly" to the novice are the same things that make it powerful and elegant in the hands of a master. To each his own - and there are things I do really miss about C# from time to time... but for me, I am all too happy trade the tidier date.Format() for the more powerful underlying functional constructs any day.

Re: Enough with the JavaScript already

#156

Post by andrenotgiant »

tnuc wrote: post #151
andrenotgiant wrote: post #140

Many sites already use Google's hosted javascript libraries for JQuery, Prototype, etc... Could Google reduce load time in Chrome by building these into the browser, so that anytime they see the include pointing to Google CDN, they just skip it and let the pre-included library take its place?

The number and versions of these libraries is just immense. A lot of what the early versions of these libraries used to do is now handled by upgraded versions of javascript. Adding JQuery etc. to the browser is a short term fix, that would become a problem further down the track.

I agree about the short term fix thing.

What I meant was, "_Would_ it actually save any time to do this." not "They should do it."

I am curious if there would be any speed gains, not just in data transfer but in javascript initialization and execution.

Also, it would be an interesting "aspirational algorithm" if they only did this for the best/latest versions of these libraries, encouraging developers to stay up-to-date.

Re: Enough with the JavaScript already

#157

Post by tracker1 »

A few points of contention... First, it doesn't seem like TFA is opposed to JS, as the linkbait title would seem, but the overhead of some sites/libraries.

I think that jQuery is probably a bit larger than it may need to be. Most of this is to work around edge cases or missing features in supported browsers. I think that the biggest issue may well be cost(s), and trust. It would be entirely possible to have a jQuery-like framework that would bring in only those shims as needed as part of loading from a central source. Unfortunately, that has costs in terms of both maintenance as well as deployment/cdn. It's probably not worth it.

Second, you are getting a lot of unused features with most frameworks (like jQuery), however this can be mitigated by using a common CDN, where caching helps a lot. Using the google, or ms cdn for jquery is a no brainer for a public facing application. I think that jQuery is too useful to just be replaced with one-off components.

As to jQueryUI, when you compare what it does with other toolkits, it's actually very impressive. Just look at the load size for the JS for Bootstrap for example... and bootstrap doesn't do all that jQueryUI does.

More and more frameworks have checkbox build options to give more fine grained builds specific to your needs with less overhead. Also, as pointed out in a few slides, you can load certain scripts and features as an on demand or post-load approach.

For example ALL my scripts tend to be at the bottom before the closing body tag (unless it's a single page application). Even then, the analytic scripts are last... imho the page being served to the user is the most important thing... it should be mostly functional without JS. And in terms of scripts, in the larger sense analytics are pretty low pecking order... when you have 10k users an hour, missing 2-3 analytics loads is no big deal.

Re: Enough with the JavaScript already

#158

Post by tracker1 »

jgeerts wrote: post #117
city41 wrote: post #98

Earlier quoted context omitted.

What's stopping you from only using the "good parts" in your own code? How is JS a bad tool? It runs reasonably fast, works everywhere, is a small, simple language that's surprisingly powerful. What if Eich had been influenced by C instead of Lisp when creating JS? All things considered, it could have been way worse than it is, and the truth is JavaScript lets you get in there and do good stuff. Not sure why we are s…

I think a lot of experienced developers are only using the good parts, it's difficult to learn but it can indeed be a very beautiful language when you use it with modules/jsLint/jsHint.

Agreed... I only had to do a couple tweaks to my jshint rules (I prefer comma first, and a few other things)... but it wasn't hard to get used to at all.

Testing is another point... having JS tests can help a lot, though my opinions of TDD aren't as strong as many.

Re: Enough with the JavaScript already

#159

Post by gsnedders »

kenster07 wrote: post #121

One can do a great many things with disciplined Javascript, and I shudder to think what Twitter was trying to do on their front-end that caused a 5x increase in load time compared to server-side template-rendering. That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice…

Basically, what Twitter did was load a bare wireframe that loaded JS, and then that made a request to the server to get the content. If you cut out the second request, you've instantly saved the latency before that second request is even made, as well as the extra roundtrip time.

Re: Enough with the JavaScript already

#160

Post by tracker1 »

stiff wrote: post #78
ebbv wrote: post #40

JavaScript is a tool. Once it becomes trendy idiots will always abuse a tool. It's not JavaScript's fault people are bad at web design and development. If it wasn't fucked up JavaScript these people were contacting you about it'd be something else, be glad you have a job.

We are all abusing the technologies originally developed for hypertext documents (HTTP, HTML, CSS, JavaScript) for building applications. If you today started working on a set of standards for handling what people currently build on the web proposing those technologies would be completely ridiculous, so ill suited are they for this job. And JavaScript is probably the worst of all, it is designed badly enough that the…

See CommonJS and/or AMD combined with a build tool Grunt...

You have component options around, mostly pretty new for building modular JS and building them for use in the browser as a single download. RequireJS in particular goes a long way towards helping with browser development. AMD lends itself more towards the browser, but there are build tools for CommonJS style modules as well.

If I were starting today, I'd probably have a reduced subset of what HTML is, with extension points for form inputs. The issue is that extensible/modular, skinnable and a centralized authority are points of contention for application building. I really liked Silverlight as a concept, I thought the package system was well thought out.

What I really didn't care as much for is how verbose XAML is. I can say most of the same about Flex+ActionScript. The problem is neither of these formats were open enough for browser vendors to simply have built-in support for them as a specification.

Post reply on HN