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

161–170 of 231 posts

Re: Enough with the JavaScript already

#161

Post by gsnedders »

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?

Because: we want a message-based protocol, and we want to make it (comparatively) hard to launch a DDOS attack using visitors to a website.

Re: Enough with the JavaScript already

#162

Post by metaphorm »

I'm really perplexed by one of the central complaints in this slide deck. JS load time is just not a serious problem in my experience. The use of CDN's and the browser cache has made loading scripts almost irrelevant in terms of page performance. Its a problem for first time visitors who have a cold cache. And then it amounts to adding an additional 1-2 seconds of load time once and only once on their first visit. I really don't get bent out of shape by that. I'd be worried if that 1-2 second overhead was incurred with every single page load with every single user. that's just now what happens though.

Re: Enough with the JavaScript already

#163

Post by [deleted] »

nine_k wrote: post #67
chewxy wrote: post #47

Earlier quoted context omitted.

It does not however, preclude the possibility that the tool is in fact a bad tool, and that the tool is bizarrely the only tool we have. They say poorly skilled people blame their tools, and that highly skilled people who know their tools well, will know how to use it well. That being said, see that circular saw over there that will occasionally bounce and cut off its user's fingers? I'm not gonna use it, no matter h…

Fortunately, JS is not the only tool we have. JS is a relatively fine compile target , and with asm.js, a pretty fast one. So pick your favorite among CoffeeScript, TypeScript, Dart, GorillaScript, Elm, ClojureScript, etc, or try compiling your favorite language using LLVM. Let a compiler take care of all the numerous rough edges raw JS has.

[deleted]

Re: Enough with the JavaScript already

#164

Post by tomjen3 »

chewxy wrote: post #57
marknutter wrote: post #49

Earlier quoted context omitted.

People don't use javascript because it's a beautiful, well thought out language. They use it because it runs everywhere .

Here's the painful part: Douglas Crockford wrote a book called Javascript, the Good Parts. If Javascript were limited to The Good Parts alone, it has the potential to be a beautiful well thought out language. It would be quite close to a beautiful well thought out language

Yeah, he did. As a javascript developer I wouldn't limit myself that much though - he considers using ++ a sign of bad code.

Re: Enough with the JavaScript already

#165

Post by [deleted] »

chewxy wrote: post #57
marknutter wrote: post #49

Earlier quoted context omitted.

People don't use javascript because it's a beautiful, well thought out language. They use it because it runs everywhere .

Here's the painful part: Douglas Crockford wrote a book called Javascript, the Good Parts. If Javascript were limited to The Good Parts alone, it has the potential to be a beautiful well thought out language. It would be quite close to a beautiful well thought out language

[deleted]

Re: Enough with the JavaScript already

#166

Post by wasd »

cliveowen wrote: post #11

I wonder if there'll ever be an alternative to Javascript. I'm not talking about those things that eventually get translated to Javascript, I'm talking about a native platform well thought-through and based on a typed language that isn't a mess. Yeah, I know: it's not Javascript that's broken, it's the DOM. I'd argue that both should be replaced by something else, otherwise the future will be 90% native mobile apps,…

Isn't this the objective of Dart?

Re: Enough with the JavaScript already

#167

Post by romaniv »

dccoolgai wrote: post #155
flyinRyan wrote: post #126

Earlier quoted context omitted.

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

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.

C# has delegates, events, lambda function, properties and async function as language constructs. This is as "first class" as it gets. It also has LINQ.

Re: Enough with the JavaScript already

#168

Post by joshuacc »

krosaen wrote: post #28

It's not really an either or thing. You can go too far with client side rendering. But progressive enhancement can only bring you so far in delivering an interactive experience - it's typical that his example is a simple tabs implementation - of course that's easy to do without much js. That's why I like knockoutjs - it makes it easier to sprinkle in the data-bound rich interactive UI to the pieces of your page that…

Angular is also quite good about allowing you to enhance only parts of server-rendered pages.

Re: Enough with the JavaScript already

#169

Post by jiggy2011 »

dragonwriter wrote: post #152
jiggy2011 wrote: post #149

Earlier quoted context omitted.

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.

I assume you would apply the same origin policy to the connections.

The firewall point is good, although I don't understand why you would want to block general TCP connections but not websock.

Post reply on HN