Live data from Hacker News

FOAM: New JavaScript Framework by Google Engineers

github.com

81–90 of 115 posts

Re: FOAM: New JavaScript Framework by Google Engineers

#83
post #78

Earlier quoted context omitted.

Immediate shader mode is fairly stateless, pixel and vertex shaders are as functional as one can get. Let's not talk about the fixed function APIs that no one uses anymore.

I'm not sure what you mean by "immediate shader mode". Even direct state access mode is tweaking knobs in a state machine that can have very strange side effects if you don't re-set the state every time (and that's antithetical to pure functional programming). When not using DSA--I mean, just grep for "bind" in any OpenGL codebase...

The hardware has state that is exposed more or less directly, but texture management is all just plumbing and easily wrapped. Most of my experience is with directX though, which seems to have a much cleaner API.

Anyways, immediate mode UIs abound for game stacks given the ease at which they can be mapped to the GPU directly.

Re: FOAM: New JavaScript Framework by Google Engineers

#84
post #78

Earlier quoted context omitted.

I'm not sure what you mean by "immediate shader mode". Even direct state access mode is tweaking knobs in a state machine that can have very strange side effects if you don't re-set the state every time (and that's antithetical to pure functional programming). When not using DSA--I mean, just grep for "bind" in any OpenGL codebase...

The hardware has state that is exposed more or less directly, but texture management is all just plumbing and easily wrapped. Most of my experience is with directX though, which seems to have a much cleaner API. Anyways, immediate mode UIs abound for game stacks given the ease at which they can be mapped to the GPU directly.

DirectX still uses stuff like ID3D11DeviceContext::PSSetShaderResources to set application-global state that's required to do anything. It is fundamentally stateful and non-pure. I'm not sure why you're trying to argue this point.

Re: FOAM: New JavaScript Framework by Google Engineers

#85
post #59

Earlier quoted context omitted.

I'd love to see a mature app written this way (and I mean that genuinely, without sarcasm) and look at their project timeline, war stories, etc. My gut feeling is that the 'frameworks are for prototypes, libraries are for production' camp is closest to the money, but (a) I have no actual data and (b) different approaches to frameworks will have different outcomes.

Just compare number of well-known production apps written using React & Angular.

How? Where can I see such a comparison? Is it obvious to you which there are more of? It isn't to me.

Re: FOAM: New JavaScript Framework by Google Engineers

#86

Earlier quoted context omitted.

They probably have rights to the project under the respective contracts they have with the employees. That aside, having " by ((Google(|rs))| )" in the title has generally been a reliable filter for projects that do not stand on their own merit, and this one seems to be no exception.

Exactly. Everyone should ask himself/herself "would this be newsworthy if they didn't name-drop Google?".

As an experiment, I deliberately avoided adding "by Google" or similar when first submitting FOAM to HN while it was being tweeted about after yesterday's EmpireJS talk: https://news.ycombinator.com/item?id=9442943

Over on /r/javascript, my plain titled link has 2 points/23 comments while the "from Google" submission has 44 points/65 comments.

Not of much use for direct comparison purposes (GitHub repo links vs. project site links, different times of day, weekend vs. weekday etc.) but mildly interesting.

Re: FOAM: New JavaScript Framework by Google Engineers

#87

Earlier quoted context omitted.

Crockford talks about the bad features added to ES6, one of them class which he said is most requested by Java developers programming javascript.At the end of the talk he show way how to move out of classes/new in javascript https://www.youtube.com/watch?v=PSGEjv3Tqo0&feature=youtu.be...

Can you give a short gist of why they're bad and why should one move out of classes/new? What is the alternative?

its mostly because of 'this' . as per the example above, you can prevent this by doing something like that.. freeze/seal

Re: FOAM: New JavaScript Framework by Google Engineers

#88
post #82

> FOAM is a full-stack Reactive MVC Meta-Programming framework. 5 years ago I would have thought that this would have been the title of the tech section of Onion article ...

[deleted]

Well I'll sheepishly raise my hand and say I don't have a bloody clue what the sentence is trying to say.

Individually, the words make sense, but after trying to parse the combination I feel like I have less information than when I started.

Re: FOAM: New JavaScript Framework by Google Engineers

#89
post #3

One thing you notice right off the bat: Its very slow. It takes about 2s on my machine to load the TodoMVC example. Thats about as long as it takes to load my GMail inbox. Thats pretty horrible for whats supposed to be the "Hello World" of JS frameworks. I didnt dig in what actually takes so long, but it seems like it has still some way to go. I find it interesting that after Angular this would the second (3rd if you…

Yeah, based on the Chrome network panel it is loading all the unminified view files separately. They should definitely combine and minify all the files to prevent a bad first impression.

Re: FOAM: New JavaScript Framework by Google Engineers

#90
post #74

Earlier quoted context omitted.

Can you give a short gist of why they're bad and why should one move out of classes/new? What is the alternative?

From the video: function constructor(spec) { let {member} = spec, {other} = other_constructor(spec), method = function () { // accesses member, other, method, spec }; return Object.freeze({ method, other, }); }

That looks pretty interesting and flexible on one hand, on the other, I don't see why it's better than classes. Is it just more explicit?
Post reply on HN