Enough with the JavaScript already • Hacker News Board

Re: Enough with the JavaScript already

#141

Post by sker » Mon, Jul 15, 2013, 5:13 PM UTC

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.

Also, FunScript (F# to JS). http://funscript.info/

Re: Enough with the JavaScript already

#142

Post by krosaen » Mon, Jul 15, 2013, 5:15 PM UTC

jhh wrote: post #96

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…

have you actually done this? I was wondering if this is a feasible and good way to use knockout!

yeah, a good description in passing in terms of using a framework as an "island of riches" here:

http://blog.stevensanderson.com/2012/08/01/rich-javascript-a...

we use this technique at food52.com, e.g this content page cached uniformly, login system, recipe saving widget, comment system all done in ko.

http://food52.com/recipes/22888-yotam-ottolenghi-sami-tamimi...

more interactive / sophisticated uses of ko coming in our new shop soon for the cart functionality.

Re: Enough with the JavaScript already

#143

Post by tannerc » Mon, Jul 15, 2013, 5:15 PM UTC

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?

Great idea, why limit it to just Chrome? Of course, implementing something like this would require a number of additional updates.

And this still doesn't directly address the issue due to custom, large scripts for site-specific functionality.

Re: Enough with the JavaScript already

#144

Post by Domenic_S » Mon, Jul 15, 2013, 5:19 PM UTC

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.

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

Re: Enough with the JavaScript already

#145

Post by cromwellian » Mon, Jul 15, 2013, 5:20 PM UTC

On many sites, the (cached) load of 500k of gzipped JS is dwarfed by the amount of HTML, CSS, and images loaded.

Re: Enough with the JavaScript already

#146

Post by carlosdp » Mon, Jul 15, 2013, 5:21 PM UTC

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?

This shouldn't be necessary. Google's CDN (afaik) sets proper cache headers so that the first time you download a specific version of a library, your browser should cache it until it expires. (correct me if I am wrong)

Re: Enough with the JavaScript already

#147

Post by joshuak » Mon, Jul 15, 2013, 5:21 PM UTC

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?

I like this in principle. I think it should be abstracted out to a simple package system or something though. When you go to a sight that requires JQuery, your browser checks the sha256 hash or something against it's canonical list of published packages. If one is available it installs that one, or uses the one already installed. If the sha hash doesn't match it goes ahead and downloads the one from the site.

However, is transfer time really the biggest issue here?

Re: Enough with the JavaScript already

#148

Post by bradshaw1965 » Mon, Jul 15, 2013, 5:22 PM UTC

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.

The same comparisons were made when Flash was being misused. It doesn't take much to muddy an ecosystem. There were certainly other problems with Flash, but thinking that best practices for JS will filter through to most developers is unlikely.

Re: Enough with the JavaScript already

#149

Post by jiggy2011 » Mon, Jul 15, 2013, 5:23 PM UTC

Slackwise wrote: post #26

chii wrote: post #24

Earlier quoted context omitted.

The mistake, perhaps, is that people (us) are trying to shoe horn an application into a Document object model - its in the name for christ sakes! Document! Not application object model!

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?

Re: Enough with the JavaScript already

#150

Post by pjmlp » Mon, Jul 15, 2013, 5:27 PM UTC

nbevans wrote: post #84

pjmlp wrote: post #69

Earlier quoted context omitted.

Number 1 reason to uninstall applications on Play Store, executable size , Google IO 2013. Plus Mono does not save you from writing multiple UI code anyway.

Yes it does. Look at the MvvmCross project. Also struggling to verify that claim re. executable size, can you provide a link? Either way, average app size on Android seems to be around 3MB. A typical Xamarin-compiled app is around 4 to 4.5MB.

> Yes it does. Look at the MvvmCross project.

This is a cross platform implementation of the MVVM patterns, you still need to write the platform specific views.

And to be honest, given my experience on .NET enterprise projects, MVVM brings me back J2EE 1.4 memories.

> Also struggling to verify that claim re. executable size, can you provide a link?

Someone mentioned it to me on a Reddit discussion.

We have the policy to only use vendor supported languages, to minimize support issues and take advantage of performance.

I should add the mobile apps I was involved were games.