Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Famo.us: Do We Really Need Another JavaScript Framework?

Soulskill posted about 4 months ago | from the let's-create-a-javascript-framework-to-find-out dept.

Programming 104

An anonymous reader writes Front-end developer Jaroen Janssen has a post about Famo.us, "a custom built JavaScript 3D rendering and physics engine meant as a replacement for the standard layout engine of the browser." The engine effectively replaces a big chunk of HTML5 in order to render more efficiently by using technology based on WebGL. Janssen questions whether the world really needs another JavaScript framework: "Is it a bad thing that Famo.us replaces major parts of HTML5? To be honest, I'm not sure. As a Front-end developer I have to admit it makes me slightly uneasy to have to use a custom API instead of 'standard' HTML5. On the other hand, like almost everyone that makes web apps for a living, I have been terribly frustrated by some of HTML5 limitations, like slowness and browser incompatibilities. Either way, it might be a good thing to try a fundamentally different approach so I'm keeping an open mind for now.

Famo.us chases another holy grail, namely the 'write once, run anywhere' dream. Instead of having to write different code for different platforms, like iOS and Android, developers can write one application that works and looks as good on all platforms, in theory anyway. This of course saves a huge amount of time and resources. Unfortunately, this idea is not without its problems and has never really worked very well with earlier attempts like Java-applets, Flash and Silverlight. In the end native applications have so far always been faster and slicker and I'm pretty skeptical Famo.us will be able to change this."

cancel ×

104 comments

Sorry! There are no comments related to the filter you selected.

VRML (5, Funny)

Anonymous Coward | about 4 months ago | (#47384951)

The world is now ready for VRML.

Re:VRML (3, Insightful)

Cryacin (657549) | about 4 months ago | (#47385253)

A lot of the goals of famo.us seem to overlap with another technology. Fla.sh!

Ducks, but it's true.

Re:VRML (1)

Concerned Onlooker (473481) | about 4 months ago | (#47387147)

Who cares? As long as it's written in coffeescript I'm in.

Re:VRML (1)

Jane Q. Public (1010737) | about 4 months ago | (#47387607)

At least coffeescript is pre-semi-compiled.

Javascript faster than HTML? Really? I'd like to see that against my HTML-only page.

Not Ready Yet... (3, Interesting)

jklappenbach (824031) | about 4 months ago | (#47384971)

Until 3D rendering is on par in terms of efficiency with 2D graphics, you'll see a rebellion against WebGL for general purpose websites. This is because mobile devices are drained of charge in minutes instead of hours when the silicon to handle 3D activates.

Re:Not Ready Yet... (1)

K. S. Kyosuke (729550) | about 4 months ago | (#47385089)

Why should the usage of 3D units be significantly more inefficient? In modern 3D APIs, you generally pay for what you use, and I don't quite see why it should be vastly more inefficient especially if the hardware and drivers provide things like render-to-texture etc. That is, unless you have OpenVG in silicon. But if you *do* have OpenVG in silicon, why not simply have multiple backends?

Re:Not Ready Yet... (1)

phantomfive (622387) | about 4 months ago | (#47385533)

Why should the usage of 3D units be significantly more inefficient?

I don't think it's a matter of what should be, it's a matter of what is. And right now, the way phone CPUs are designed, they can shut down sections of themselves in order to save power. However, they don't have the fine granularity to be able to 'turn on' and 'turn off' only certain APIs, you either get the GPU on or you don't.

In the future, of course, anything is possible.

Re:Not Ready Yet... (1)

K. S. Kyosuke (729550) | about 4 months ago | (#47385783)

However, they don't have the fine granularity to be able to 'turn on' and 'turn off' only certain APIs, you either get the GPU on or you don't.

That's quite lousy, especially in the light of the fact that for simpler processing units, we can design them in a way to let them consume as much power as they need without any (or very little) need for SW support. But I wouldn't lose my hope just yet.

Re:Not Ready Yet... (1)

tepples (727027) | about 4 months ago | (#47385129)

WebGL doesn't work at all on iOS anyway apart from iAds.

Re:Not Ready Yet... (1)

rescendent (870007) | about 4 months ago | (#47385437)

Is confirmed for and demonstrated on iOS 8

Re:Not Ready Yet... (1)

binarylarry (1338699) | about 4 months ago | (#47385283)

Really fucking wrong, almost all of the 2D is accelerated by the same apis (and use 3d apis underneath).

Re:Not Ready Yet... (1)

TheRaven64 (641858) | about 4 months ago | (#47388433)

That's true on the desktop, but absolutely untrue on mobile devices. You typically have an OpenVG accelerator in the SoC that uses a lot less power than the GPU (or is part of the GPU, but uses a lot less power than the 3D mode).

Re:Not Ready Yet... (1)

gbjbaanb (229885) | about 4 months ago | (#47385625)

3d is more accelerated than 2d - its faster simply becuase the graphics cards practically only do 3d stuff now. 2d, there for desktop windows as almost an afterthought.

Some systems (eg Direct2d) are built on top of 3d graphics stacks, you just have a flat projection and no depth co-ordinates to give the impression of a 2d graphics surface.

So you see WebGL is significantly faster than HTML drawing, which is why it might be a good thing overall... the problem comes with replacing a well known standard with god-knows-what graphics drawing. Hopefully it'll settle down, and maybe one day we'll get a C-style logic that draws WebGL graphics in a browser as a standard.

And then someone will replace it with something else.

Re:Not Ready Yet... (1)

snemarch (1086057) | about 4 months ago | (#47385977)

Some systems (eg Direct2d) are built on top of 3d graphics stacks, you just have a flat projection and no depth co-ordinates to give the impression of a 2d graphics surface.

Do keep in mind that you're talking about one specific technology stack here.

So you see WebGL is significantly faster than HTML drawing, which is why it might be a good thing overall...

Really? I might be misunderstanding things, but the general browser engine is going to be C/C++ code, whereas all the famo.us stuff will be javascript. Sure thing, JS engines have become a lot more performant lately, but they still don't beat native code.

But sure, if you offer more limited layouting, you might be able to outperform the native browser engines with JS+WebGL. HTML+CSS is a pretty horribly bloated beast.

Re:Not Ready Yet... (1)

ChunderDownunder (709234) | about 4 months ago | (#47386213)

Do keep in mind that you're talking about one specific technology stack here.

Java2D has long been 3D-rendered using OpenGL or Direct3D. X.org's Glamor aims to unify 2D with OpenGL.

Re:Not Ready Yet... (1)

gbjbaanb (229885) | about 4 months ago | (#47387831)

true, but all those HTML elements tend to get laid out in increasingly complex divs, with a whole heap of CSS added.

I was really referring to the javascript "controls" that are html elements with a huge heap of javascript behind them providing functionality.

I'd like to see webgl + native code running in the browser as a standard, probably based on a superset of C so anything else can be implemented in it.

Re:Not Ready Yet... (1)

znrt (2424692) | about 4 months ago | (#47386557)

the problem comes with replacing a well known standard

which standard? html5 isn't a standard at all, let alone well known. it's a wannabee. besides, famo.us doesn't seem to seek to *replace* anything, it's just another option for an area currently lacking good enough support or standard.

with god-knows-what graphics drawing.

if it works crossbrowser i can't possibly see a problem with it, just as with any other lib you are free to use or not.

Re:Not Ready Yet... (0)

Anonymous Coward | about 4 months ago | (#47388523)

which standard? html5 isn't a standard at all, let alone well known. it's a wannabee.

Oh? You'd better tell these [w3.org] guys [whatwg.org] to stop work then.

Re: Not Ready Yet... (0)

Anonymous Coward | about 4 months ago | (#47387791)

Famo.us does NOT use WebGL! Only pure HTML5.

Re: Not Ready Yet... (0)

Anonymous Coward | about 4 months ago | (#47389235)

Mod parent "uninformative."

From the Fam.ous site:

"What is Famo.us? Famo.us is the only JavaScript framework that includes an open source 3D layout engine fully integrated with a 3D physics animation engine that can render to DOM, Canvas, or WebGL."

Let the free market decide (3, Insightful)

penguinoid (724646) | about 4 months ago | (#47384985)

The web developers and users will quickly decide if people want this technology. The more options the better I say; the inferior ones will fade on their own.

Re:Let the free market decide (0, Insightful)

Anonymous Coward | about 4 months ago | (#47385659)

Yay, more options. Since the DOM is so slow and sucks so much, I'm going to make a Javascript library that parses HTML and CSS and converts them into canvas drawings. This portable HTML implementation will solve all our cross-platform issues because it will render everything the same in every browser. Will can finally simplify HTML and drop every tag except canvas and maybe the audio tag. My library will ensure a lush and consistent user experience across all devices. Everyone knows Javascript has been getting faster and faster while HTML hasn't been sped up in years. My library will draw faster than the browser can parse HTML because Javascript is so fast.

For marketing and business users, my library will help ensure your safety. Since any text is drawn in pixels and not included as character data, your users will no longer be able to illegally take text from your website and reuse them elsewhere as their own work. If you need to make a sudden change to your site to prevent a consumer lawsuit, have no fear. No one will have an archive of your site as attempting to store every viewable section as a video would take up far too much space. Everyone knows images can be photo-shopped. No one will trust a screenshot of your site.

For tech-savvy users, fear not. You'll still have your freedom. There already exists a Chrome addon that uses OCR to extract text from images. I'll expand on that extension and create one for each browser. If you really want to copy those lyrics or news articles you can.

It'll take me a couple years to build the library, but that's ok. It'll need the next-gen power of future computers and cell phones. There's no reason to design for the current gen as that'll be all old and outdated and stuff. My library will be free so don't worry about ads. I'm funding development through my new invention. Instead of throwing away water bottles and filling landfills with toxic batteries, I've developed a hand-held gas generator with a micro-USB output. Simple fill up your old water bottle with gasoline, screw on the generator, plug-in your next gen smart phone, and now you can spend all afternoon browsing the web. With my library, it'll look the same as if you were on a desktop, but better!

Sadly, I actually expect such a library to be created and used if it hasn't been made already. I truly hate web development and how software engineering and computers in general seem to be progressing backwards.

Do we need HTML+Javascript at all? (3, Interesting)

Anonymous Coward | about 4 months ago | (#47384997)

- inferior paradigm;
- Inferior performance;
- Inferior UI experience;
- Inferior security;
- Inferior privacy;
- Inferior development environment; ...

Honestly, it's just the mainframe game of the '60s, plus all the guys who realise they can make a lot of money by pretending that dumb terminals are an advance on autonomous desktops belonging to and being controlled by the user.

Re:Do we need HTML+Javascript at all? (1, Insightful)

Anonymous Coward | about 4 months ago | (#47385073)

Do we really need more than 5 computers?

Re:Do we need HTML+Javascript at all? (2)

K. S. Kyosuke (729550) | about 4 months ago | (#47385113)

Do we really need more than HTML5 computers?

FTFY.

Re:Do we need HTML+Javascript at all? (0)

Anonymous Coward | about 4 months ago | (#47385175)

That's pretty much where we're heading with the whole cloud thing, yes: 5 computers and a billion dumb terminals.

Re:Do we need HTML+Javascript at all? (1)

tepples (727027) | about 4 months ago | (#47385255)

How would one go about running a video game on a dumb terminal? Cellular networks don't have enough throughput to support a lot of OnLive/Gaikai style streaming, and plenty of games are too twitch-sensitive for cellular Internet latency to keep the game enjoyable.

Re:Do we need HTML+Javascript at all? (1)

snemarch (1086057) | about 4 months ago | (#47386011)

How would one go about running a video game on a dumb terminal? Cellular networks don't have enough throughput to support a lot of OnLive/Gaikai style streaming, and plenty of games are too twitch-sensitive for cellular Internet latency to keep the game enjoyable.

"Nobody wants to play those games". Like, nobody would want to play anything with an inferior non-DRM experience. Catch my drift?

Re:Do we need HTML+Javascript at all? (0)

Anonymous Coward | about 3 months ago | (#47396097)

Most games can be played over streaming networks and those that can't are an extreme niche compared with the broader scope of computing in general.

How about 5 computers and a billion smart terminal (1)

Rob Y. (110975) | about 4 months ago | (#47388283)

There's a class of application that will never make sense to be stand-alone, and for those apps, the cloud is probably the best paradigm. But the current state of HTM5/Javascript calls for a cloud with a ton of application logic running in the browser. I'd much rather see a single app running in the browser that isolates all the front-end specifics and makes it really easy to write fully server based apps that use the browser as a universal delivery system - and nothing else. Sure, you're not going to write video games that way. But I'm talking about apps that handle data input and output with a robust widget set that doesn't need to be programmed on the front end. A smart terminal that lets you generate, say, data to be displayed in a grid on the server and just send it to the terminal for display and manipulation.

I wrote something just like that a long time ago - though it doesn't run in a browser - so the smart terminal requires Windows or WINE to run. That no longer cuts it, but as a proof of concept it works really well (and is still in use). The data grid, for example takes grid layout instructions and a file in a 'CSV with flags' format that is produced on the server for display (and editing) in the terminal. Besides making the app easy to implement and debug, that level of abstraction has some nice side benefits. 'Printed' reports come for free, because the data and the instructions for laying it out in a grid are generated separately from the display logic, and it was easy to implement a printing module that takes that same info on the server side and uses it to generate a PDF or XLS file for download and native display/printing. I guess it's essentially splitting the MVC model so that only the View part (the part that has to run on the client) runs on the client.

I can't be the only one that's done something like this - but I'm curious why I don't see anyone trying to adapt that model as a browser-based application platform. Just because Javascript lets you write application code that runs in the browser, that doesn't mean it's a good idea - or that the end result is easy to write, debug and support. The browser's a really smart terminal, but maybe it would make sense to write a browser application that turns it into a somewhat dumber terminal - that only does terminal-like stuff.

Re:Do we need HTML+Javascript at all? (1)

Anonymous Coward | about 4 months ago | (#47385107)

Yes because the mobile experience where every single website is replaced by a crapp is sooo much better.

Re:Do we need HTML+Javascript at all? (3, Insightful)

scamper_22 (1073470) | about 4 months ago | (#47385391)

It's not what we need. We've always had what we need.
It's about getting everyone to use the same thing.

Basically we have debates on screen layout, networking... other APIs. We've been building such APIs for decades.

It is just hard to get everyone to use the same API.

We need HTML+javascript, because for whatever reason that worked to get the world moving. Maybe it would have better if the web just ran off perl scripts or python scripts or QT application or TCL or whatever, but it didn't.

It began as a markup language (more to display documents like Word). Then it moved to become dynamic pages. Again like adding VBScripting to Word. Now we keep hacking and putting stuff on top of it to make it a full fledged programming environment.

We can hope for niceness, but this seems to be repeated over and over and our field. Yet, somehow, things get made.

Re:Do we need HTML+Javascript at all? (1)

phantomfive (622387) | about 4 months ago | (#47385537)

Whether we need it or not, it's what some people want, and what others are willing to build. So whining about it at this point isn't going to do anything.

The alternative is Flash, so Javascript+HTML isn't really that bad, considering what could be.

Re:Do we need HTML+Javascript at all? (1)

Assmasher (456699) | about 4 months ago | (#47385587)

This, a thousand time this.

Why don't browser makers get together and throw out the entire existing paradigm of horrific compromises and agree on completely fresh start with both language and UI framework.

Throw out HTML, throw out CSS, throw out JavaScript. Take the best *ideas* from them all, use C# (nothing to do with Microsoft though) and create a common framework on all platforms embracing those *ideas* and use OpenGL as the composition engine.

Re:Do we need HTML+Javascript at all? (0)

Anonymous Coward | about 4 months ago | (#47385617)

They're working on it ... but not together.

Re:Do we need HTML+Javascript at all? (1)

AuMatar (183847) | about 4 months ago | (#47385627)

Don't use C#. Write a bytecode platform that anything can port to- Javascript, C, C++, C#, Java, Python, etc. Then developers can use what they want. Using C# is almost as big a failure of an idea as using Javascript.

Re:Do we need HTML+Javascript at all? (1)

Assmasher (456699) | about 4 months ago | (#47385837)

Using C# is almost as big a failure of an idea as using Javascript

Would you care to explain any of your reasons why? It seems to be vastly superior for client side work in comparison to everything else right now. I wouldn't use it on the backend (that's still C++ territory in my opinion), but it and/or Java work well on the web services side of the backend.

Writing a bytecode platform is exactly what using C# would do in any case (I guess I should have been clearer.) I don't care if the actual language on top is exactly C#, or something else, just let it compile to a bytecode platform that takes all the best of Java, C#, and other THICK CLIENT application languages because the state of the world today is that people are trying to write thick client applications in the web browser using languages never intended to be used in such a fashion.

Re:Do we need HTML+Javascript at all? (2)

bbn (172659) | about 4 months ago | (#47387317)

You like C#, I like Scala and the next guy over likes Haskell. Trying to force everyone to use one language that fits all is one of the big fails of JavaScript.

Language development is an ongoing research area. You can not just freeze time and say we will use this one for the rest of time.

This is why we now have a host of languages that compiles to JavaScript. I use Scala-JS that will convert my Scala to JavaScript. But this is horrible inefficient and limiting.

The correct solution is PNaCl: http://en.wikipedia.org/wiki/G... [wikipedia.org]

Portable Native Client is a LLVM based byte code language, that is designed to be a target for other programming languages. You can compile your beloved C# to PNaCl, someone can compile his C++ and I can compile my Scala. And it is almost as fast as if you used machine code as target.

Re:Do we need HTML+Javascript at all? (-1)

Anonymous Coward | about 4 months ago | (#47386155)

Unfortunately, OpenGL is getting left badly behind now. Microsoft recognise you can't get peak performance out of it and write Direct3D. Sony recognised the same, and write LibGCM. Now OpenGL's biggest user - Apple also recognise that and have written Metal. Unless the OpenGL ARB pull their finger out, they're going to be left in the dust.

Re:Do we need HTML+Javascript at all? (2)

Jeremi (14640) | about 4 months ago | (#47386467)

Throw out HTML, throw out CSS, throw out JavaScript. Take the best *ideas* from them all, use C# (nothing to do with Microsoft though) and create a common framework on all platforms embracing those *ideas* and use OpenGL as the composition engine.

I'd try to explain the problems with this line of thinking, but I think xkcd [xkcd.com] does a better job.

Re:Do we need HTML+Javascript at all? (0)

Anonymous Coward | about 4 months ago | (#47385899)

Except in 2014 it's cheaper to host your own "mainframe" (i.e. a web server) than it is to actually purchase a full-blown desktop computer.

You can lease a VPS for like $10/month or less, giving you 24/7, always on publishing capability to run your HTML application.

"belonging to and being controlled by the user"? (2)

jeffb (2.718) (1189693) | about 4 months ago | (#47386031)

Sure, having desktops "controlled by the user" has worked out just swell for the last 30 years or so. If you want to make sure a system stays at peak performance, doesn't get infected, and keeps up with bug fixes, put it "under the complete control" of someone who thinks a "buffer overflow attack" means someone pouring too much cleaning solution into a floor polisher.

Re:"belonging to and being controlled by the user" (0)

Anonymous Coward | about 4 months ago | (#47386731)

Sure, having has worked out just swell for the last 30 years or so.

"under the complete control" ? Of who, the mega corporations? The NSA?

"Belonging to and being controlled by the user" -- HA HA HA HA HA .

If you want to make sure a system stays at peak performance, doesn't get infected, and keeps up with bug fixes, put it "under the complete control" of someone who thinks a "buffer overflow attack" means "this backdoor was placed here for NATIONAL SECURITY"

HA HA HA "controlled by the user" -- where have you been the last 30 years? Please, share us the details of your homebrew machine, the "jeffb 8000".

Re:Do we need HTML+Javascript at all? (2)

diamondmagic (877411) | about 4 months ago | (#47386139)

HTML is accessible and portable. Any device can read it. The most common use-case by far is graphically rendering it in a Web browser, which can be done on a desktop or mobile device; also rendering to printed pages, or multi-channel audio. And of course, spiders/robots.

In short, Web browsers are only one kind of user-agent. HTML is accessible and satisfies the needs of all user-agents.

If you don't use the features of HTML that allow you to do this (such as link relations), you may as well just publish from Photoshop to a JPEG.

Re:Do we need HTML+Javascript at all? (1)

Anonymous Coward | about 4 months ago | (#47386325)

Apps running in a pretty secure sandbox, which a runtime on everyone's machines.
Which is cross platform?
Where the source is almost always understandable / editable at the client.
That also has a vibrant open source community building libraries for it.
That simple enough that a new person can at least build a page in the first day of learning it.

Sounds like a success to me.

Do we need html + javascript? no, but we don't have anything better that people agree on.
Silverlight? Flash? Applets? downloaded exe's? ActiveX? History is littered with failed replacements.

You can complain that it is bad, but the real trick is to build something better that people agree with.

Re:Do we need HTML+Javascript at all? (1)

devent (1627873) | about 4 months ago | (#47387539)

- Superior Advertisement
- Superior punishing of unnecessary updates
- Superior tracking of users
- Superior copy protection

And those are the only points a company is interested in.

Re:Do we need HTML+Javascript at all? (0)

Anonymous Coward | about 3 months ago | (#47395865)

- inferior paradigm;

Compared to what?

- Inferior performance;

Compared to what?

- Inferior UI experience;

Compared to what?

- Inferior security;

Compared to what?

- Inferior privacy;

Compared to what?

- Inferior development environment; ...

Compared to what?

Nothing is perfect, we know that, but you could post your response in reference to just about anything, because you give no specifics, no reasoning and suggest no alternatives.

Superiority complexes. (5, Funny)

Anonymous Coward | about 4 months ago | (#47385005)

This is basically a waste of time. What they should be doing is working with the browser vendors and standards committees to improve HTML5, not making their own inferior and heavyweight solution to add to the slow-down of the Internet.

A lot of devs don't even realize how efficient and quick modern browsers are, because they're too busy complaining and trying to solve perceived problems using these kinds of crappy replacement stacks. What's the point in having a standard framework if everyone tries to write a "Flash" to replace it? It's inane.

Especially since a lot of effort has gone into making specs that are as efficient as possible and avoid a lot of problems you don't see immediately; several of these frameworks have serious performance issues that can't be rectified without the browsers themselves re-writing a lot of code. I utterly fail to see the need for this. Stop trying to replace standard technology with inferior solutions already.

Re:Superiority complexes. (1)

Anonymous Coward | about 4 months ago | (#47385039)

A lot of devs don't even realize how efficient and quick modern browsers are,

+5 funny. Would laugh again.

Re:Superiority complexes. (0)

Anonymous Coward | about 4 months ago | (#47385147)

A lot of devs don't even realize how efficient and quick modern browsers are,

+5 funny. Would laugh again.

+5 funny. Would laugh again.

Re:Superiority complexes. (0)

Anonymous Coward | about 4 months ago | (#47385567)

This is not reddit. There is no karma train.

Re:Superiority complexes. (0)

Anonymous Coward | about 4 months ago | (#47386331)

We are running olap cubes in the client, with 50,000 rows which are processed and presented almost instantly.
The browser runtimes are a beast. don't kid yourself otherwise.

Re:Superiority complexes. (0)

Anonymous Coward | about 4 months ago | (#47386767)

They are definitely beasts. Slow, bloated beasts.

Re:Superiority complexes. (1)

K. S. Kyosuke (729550) | about 4 months ago | (#47385155)

"Heavyweight"...that's perhaps partly disingenous. Whatever code an app writer would use for an application probably would never reach the complexity level of an HTML5 browser. Furthermore, stuff like CSS3 allows for a number of desirable layout options, and browsers tend to be *generally* fast, but where's the guarantee that everything complicated you might want to create with CSS3 is going to be fast on browser X? It isn't there, of course, you have to be aware of what changes to the style or the DOM tree formatted with such and such complex styles are going to be handled efficiently, and which won't. Going to a lower level, while allowing for as smart or dumb a layout engine as the devoper can come up with removes these implementations, which, admittedly, contain a lot of useful domain knowledge transformed into working code. But couldn't these implementations work like libraries today, for those who want them, especially in the light of the fact that Google's Chrom/Blink aims to push more and more browser functionality into JS heap/code?

Myself, I still want my DynaBook OS instead.

Re:Superiority complexes. (0)

Anonymous Coward | about 4 months ago | (#47386357)

Heavyweight is definitely true. Users have to download the framework to run your app, it's not built into the browser. And adding another layer on top of already-iffy browser implementations is only that much less efficient and merely adding another layer to obfuscate things.

If browser vendors are finding it possible to push more and more of their browser into the JS layer, and it's still running efficiently enough on lower-end devices, then I fail to see the problem. If I can develop an app to run on an underpowered handset on FirefoxOS, which is basically running a lot of JS to run my JS, then I fail to see the problem. However, running my code on someone else's framework on top of JS/HTML5? That's ridiculous. Maybe in 10-15 years, but right now it's a waste of resources that's little more than a thought experiment at best.

Nobody should be forcing users to suffer abysmal performance on their devices just because some dev was too lazy to learn and test HTML5 with minimalist frameworks, and came up with some replacement for HTML5 that runs in HTML5.

Re:Superiority complexes. (0)

Anonymous Coward | about 4 months ago | (#47386743)

Heavyweight is definitely true. Users have to download the framework to run your app, it's not built into the browser. And adding another layer on top of already-iffy browser implementations is only that much less efficient and merely adding another layer to obfuscate things.

Which make one wonder. If JS is so standardized, why can browsers not officially ship with various JS libraries pre-installed?

Why is there not a package manager (for lack of a better word) for such things? Because the browser vendors will never agree and get along with eachother?

Hate JS as much as the next guy, but this seems an OS (browser in this case) problem.

Everything they ditched by calling the browser the OS they will have to reinvent, no surprise. Tell me how this is wrong and just "the old way" of thinking. I am not against alternatives, just calling it how I see it.

Re:Superiority complexes. (2)

drinkypoo (153816) | about 4 months ago | (#47385561)

This is basically a waste of time. What they should be doing is working with the browser vendors and standards committees to improve HTML5, not making their own inferior and heavyweight solution to add to the slow-down of the Internet.

Irony: suggesting a waste of time as the antidote for a supposed waste of time. Historically, the way things get into the spec now and not next decade is that someone just does them and the community decides what's good.

Re:Superiority complexes. (0)

Anonymous Coward | about 4 months ago | (#47386343)

If you consider "HTML5" a waste of time, then what they're doing is just that much more of a waste of time. Historically what happened was that the browser vendors implemented stuff, the others followed suit, and the spec got written to reflect that. This is not the same thing. This is people using the spec implementations to run their own platform on top of that platform. And worse, it can't simply be shoehorned into the existing platform because it's attempting to be a replacement. Good luck getting anyone else to adopt that - it's like how Google is asking for others to implement Dart or use their VM, and if nobody's biting on Google's stuff then they certainly won't accept some patchwork Javascript framework that's horribly inefficient.

Re:Superiority complexes. (1)

drinkypoo (153816) | about 4 months ago | (#47387803)

And worse, it can't simply be shoehorned into the existing platform because it's attempting to be a replacement.

The wonderful thing about standards is that there are so many of them.

it's like how Google is asking for others to implement Dart or use their VM, and if nobody's biting on Google's stuff then they certainly won't accept some patchwork Javascript framework that's horribly inefficient.

It is in fact nothing whatsoever like that. This is a technology that you can use right now. And if it becomes highly successful, then it's likely that web browsers will come to look more like it, if not adopt it wholesale.

Re:Superiority complexes. (0)

Anonymous Coward | about 4 months ago | (#47389349)

You saying it doesn't make it true. Dart is also a technology that can be used right now, and actually is. But neither are being adopted by browser vendors. Neither technology seems likely to be highly successful, and variants on them have been around for years.

Likewise, that "wonderful thing" line about standards might sound pretty, but it's basically irrelevant in the web space. There are lots of standards, but whatever the browser vendors are willing to implement goes in. Just having one company and a few users doesn't mean you're going to be a standard everyone adopts. The fact that someone like Google can't entice others to adopt a Javascript replacement (ie, something everyone says they actually want) means this has a snowball's chance in hell, comparatively.

Re:Superiority complexes. (1)

drinkypoo (153816) | about 4 months ago | (#47389501)

The fact that someone like Google can't entice others to adopt a Javascript replacement (ie, something everyone says they actually want)

Who is this 'everyone'? Seems like mostly people incapable of contributing to such an effort. And you can't use dart right now without compiling to javascript anyway, so you can only half-use it. This is just based on what's there already, and if it's used, then presumably people will spend effort accelerating it.

HTML5 & JS should just crawl away and die (1, Insightful)

Viol8 (599362) | about 4 months ago | (#47385109)

If you want fast 2D or 3D graphics you DON'T code them in an interpreted script language welded onto a markup language pushed well beyond its sell by date running in a bloated client which in turns runs on the OS. If web devs want to climb out of the web playpen and do grown up programming then learn a grown up language such as Java or C++.

Re:HTML5 & JS should just crawl away and die (1, Troll)

narcc (412956) | about 4 months ago | (#47385165)

LOL!

Too funny. It's like you're a time-traveler from 2005.

Re:HTML5 & JS should just crawl away and die (1)

Threni (635302) | about 4 months ago | (#47385397)

Yeah, there are loads of really good examples on the web of HTML5 and JS providing fast, standards-based 3D.

Loads of them.

Re:HTML5 & JS should just crawl away and die (1)

narcc (412956) | about 4 months ago | (#47385507)

My sarcasm detector is going off, so forgive this reply if I'm off:

There really are tons of "good examples of on the web of HTML5 and JS providing fast, standards-based 3D." Do a quick search.

Re:HTML5 & JS should just crawl away and die (1)

gbjbaanb (229885) | about 4 months ago | (#47385671)

but if your browser+js+html5 is so good at providing fast, standards-based 3D... why can't it run Crysis?

Re:HTML5 & JS should just crawl away and die (0)

Anonymous Coward | about 4 months ago | (#47387813)

Because good != great. Just give it five years.

Re:HTML5 & JS should just crawl away and die (4, Insightful)

TrollstonButterbeans (2914995) | about 4 months ago | (#47385421)

You aren't right in a technical sense on this at all. It scary what Javascript and WebGL can do and the speed of it, but what is really scary is what a mess Javascript is in 2014 --- makes Perl look like BASIC. No need to obfuscate Javascript in 2014. Also I'm not sure if technologies like NaCL and WebGL should be in the future --- I guess, but it will be coming.

But more to the question, what kind of web is this leading to ...

I used Adblock and Flashblock right now just to have a half-way decent experience on the internet to avoid a ghastly internet flash ads from downloading untold GBs of data/video/audio to annoy me without a way to mute it.

The internet is a train to nowhere and no one is driving it, big corporations will turn it into a minefield of advertising (which is FINE, by the way) but rip apart everything good (involuntary flash ads, bandwidth, speed, shitty cross-domain javascript, DRM, turn web standards into circuses) to get there.

Steve Jobs back 3 years did a rant again Flash, which at the time and still now embodies the villanous nature of plug-ins.

And with WebGL and video streaming and DRM in HTML5 --- your internet may get turned into a turdball --- just to waste everyone's bandwidth to show ads you will never click.

Re:HTML5 & JS should just crawl away and die (3, Informative)

iONiUM (530420) | about 4 months ago | (#47385751)

but what is really scary is what a mess Javascript is in 2014 --- makes Perl look like BASIC. No need to obfuscate Javascript in 2014.

I've been working in software development for about 15 years now, and I've worked professionally with all the majors (C++ a bit, Java, PHP, Perl, VBScript which was awful, C# extensively which I like a lot). For the last few years I've been tasked with writing a very large client-facing web application, where my team was mostly responsible for the front-end (JavaScript/HTML/CSS) that communicates with a large RESTful service provided by another team. This included writing an API in JavaScript with documentation.

The first thing I did was set ground rules on how my team should program in JavaScript, the structure we would use, how we would use the functional language to maximize its abilities and have some class-like things (properties, inheritance, etc.) too. Now we have a full blown web-app with a JS front end with over 900 JavaScript files (when in debug) that are very nicely sorted and categorized, full class/inheritance structures, and many other things. We use Visual Studio 2012/2013 with a few custom JavaScript extensions, and along with Chrome's debugger, it is more than manageable. But we also don't need to target any old browsers. Nothing pre-HTML5.

I'm not saying JavaScript is the best language in the world or anything like that, it definitely has its problems, and it certainly doesn't fit as a choice in many situation. But programming for it these days is not the nightmare it once was (assuming you don't need legacy browser support), and in many cases, it's actually rather refreshing after 13 years of strictly typed non-functional languages, because you can do some interesting things.

900 javascript files? (0)

Anonymous Coward | about 4 months ago | (#47386241)

you've failed at life

Re:HTML5 & JS should just crawl away and die (2)

phantomfive (622387) | about 4 months ago | (#47386309)

The first thing I did was set ground rules on how my team should program in JavaScript, the structure we would use, how we would use the functional language to maximize its abilities and have some class-like things (properties, inheritance, etc.) too. Now we have a full blown web-app with a JS front end with over 900 JavaScript files (when in debug) that are very nicely sorted and categorized, full class/inheritance structures, and many other things.

This sort of thing demonstrates that the quality of the programmers matters much more than the language.

Re:HTML5 & JS should just crawl away and die (1)

iONiUM (530420) | about 4 months ago | (#47389129)

Yes I agree 100%. Languages and platforms are a tool, what matters is the person choosing and using them.

Re:HTML5 & JS should just crawl away and die (1)

narcc (412956) | about 4 months ago | (#47387385)

, full class/inheritance structures, and many other things.

Total fail. Javascript is not Java, C#, etc. Google "prototype-based programming" or put your ACM DL subscription to good use.

You made an awful lot of extra work for yourself.

Re:HTML5 & JS should just crawl away and die (1)

iONiUM (530420) | about 4 months ago | (#47389125)

Using prototype is part of the approach of our inheritance pattern, which is based off a methodology from John Resig.

The only person who failed here was you, for trying to be a smart ass. There are many people who are good at coding aside from you, and probably many who are better, or at the least, not a dumbass.

Re:HTML5 & JS should just crawl away and die (1)

narcc (412956) | about 4 months ago | (#47390507)

There are many people who are good at coding aside from you, and probably many who are better, or at the least, not a dumbass.

I'm sure there are.

which is based off a methodology from John Resig.

But, it's obvious that you can't identify them.

Resig falls squarely in to the "incompetent" category, by any measure.

Re:HTML5 & JS should just crawl away and die (4, Funny)

Alain Williams (2972) | about 4 months ago | (#47385931)

It means that there is yet another web site that I arrive at at see an empty page or maybe a few items scattered apparently at random. I surf with javascript switched off by default. Most sites should work without javascript, OK some fancy features might be missing but I should generally see the page. Those that do not: I might look to see what javascript to enable, but all too often they are trying to pull in javascript from 1/2 dozen sites - so I guess a couple and then give up and go elsewhere.

Javascript should be used to make a page look nicer, not to make it work at all. Insisting on javascript is like insisting on flash.

I accept that a few special pages really do need special effects that need javascript, but not many of them.

Re:HTML5 & JS should just crawl away and die (1)

Nemyst (1383049) | about 4 months ago | (#47386827)

Are you out of your mind, or just completely out of touch? Did you miss the dozens of times the Java plugin was disabled by most web browsers due to vulnerabilities? And you want to have web development be made with THAT?

But then you go on about C++... Like having arbitrary machine code be run by your browser is a good idea. You're well on your way towards designing the most security-averse system thinkable, and that's quite the achievement considering how bad the current system is. In web development, you want simple, relatively fast languages that can be JIT'ed efficiently while always running in a sandbox on a virtual machine. Javascript is far from perfect, but it fits that description much better than Java or C++.

Also, interpreted Javascript stopped being a thing something like a decade ago by now. I'd recommend you catch up on the tech a bit before badmouthing it.

Re:HTML5 & JS should just crawl away and die (1)

Viol8 (599362) | about 4 months ago | (#47387495)

I didn't mean run java or C++ in the fucking browser you knobend. I meant to code standalone apps!

Re:HTML5 & JS should just crawl away and die (0)

Anonymous Coward | about 4 months ago | (#47388555)

Language bigot.
http://blog.mwootendev.com/2011/09/confessions-of-programming-language.html

Re: HTML5 & JS should just crawl away and die (0)

Anonymous Coward | about 4 months ago | (#47389969)

JavaScript hasn't been interpreted since 2008

WARNING: Slashdot Beta on the rise again (1)

Anonymous Coward | about 4 months ago | (#47385143)

Over the last week, reading as an AC, I have been forced to the Beta site well over 50% of the time.

It looks like Dice are building up to having another go at forcing Beta on us.

One interesting piece of information: I have _never_ been forced to Beta while browsing from an Android tablet using the Android supplied browser.

In case you are reading this Dice, been forced to Beta at the rate I am is _really_ pissing me off. :-( :-(

Re:WARNING: Slashdot Beta on the rise again (0)

Anonymous Coward | about 4 months ago | (#47385685)

Check your cookies. If they're automatically being cleared or forgotten then, by default, you're back on Beta.

Being Famo.us sucks! (0)

Anonymous Coward | about 4 months ago | (#47385159)

When we were growing up our parents somehow made it clear that being famo.us was good. And I mistakenly thought that if I was famo.us then everyone would love me.
-- Ellen DeGeneres

The worst thing about being famo.us is the invasion of your privacy.
-- Justin Timberlake

Being famo.us is just like being in high school. But I'm not interested in being the cheerleader. I'm not interested in being Gwen Stefani. She's the cheerleader, and I'm out in the smoker shed.
-- Courtney Love

Re:Being Famo.us sucks! (0)

Anonymous Coward | about 4 months ago | (#47385189)

That Courtney Love quote reads like it was written by some edgy 13 year old on Tumblr.

Why YES! (-1)

Anonymous Coward | about 4 months ago | (#47385161)

We really need to reinvent the entire browser in javascript. And the OS. And the hardware, why not. In a framework.

Yo dawg (-1)

Anonymous Coward | about 4 months ago | (#47385181)

I herd you like frameworks so I put frameworks inside your frameworks so you can iterate whilst you masturbate!

Bullwinkle (1)

techno-vampire (666512) | about 4 months ago | (#47385235)

This has been tried and tried and tried and it's never worked. And yet, here we have Jaroen Janssen crying, "This time, for sure!"

It's Jeroen Janssen, not Jaroen Janssen (0)

Anonymous Coward | about 4 months ago | (#47385287)

It's Jeroen Janssen, not Jaroen Janssen

Angular (2)

cablepokerface (718716) | about 4 months ago | (#47385345)

Nope, not after AngularJs you don't. Not another framework needed. After huge loads of jquery before I ever knew what a client-side architecture was, and then knockout and backbone. I found my home with Angular. I know that will be developed and fine-grained further by both professionals AND the community.

And it already kicks ass. Pretty sweet...

Re:Angular (0)

Anonymous Coward | about 4 months ago | (#47386337)

Meteor is also very very nice. Ember with htmlbars also looks like it will be good.
It's nice to have choice, and it is nice people are building new things. I doubt that AngularJs is the end of needing frameworks :) - it IS nice though.

We need something... (4, Interesting)

shic (309152) | about 4 months ago | (#47386095)

I come from a background of systems-level software... server-side and thick client, predominantly. I've recently been looking at in-browser Javascript again - and recognise that it has come a long way in recent years. JQuery is nifty; Backbone useful; Angular is neat... but they lack a certain je-ne-sais-quoi.

In one sense, I love the flexibility of dynamic programming with Javascript - but, on larger projects, this benefit becomes a burden. What I'd really like is a Javascript-like language - that compiles to efficient Javascript - where I get to structure my application; enforce type constraints at compile-time; provide test-time assertions... etc... and allow me to implement my Javascript application as a collection of independently tested components. Client-side libraries are going in the right direction - but remain an evolutionary step away from where, I think, web-technology deserves to be.

Javascript has come a long way - but the journey isn't over yet... IMHO.

Re:We need something... (1)

McLoud (92118) | about 4 months ago | (#47388031)

What I'd really like is a Javascript-like language - that compiles to efficient Javascript - where I get to structure my application; enforce type constraints at compile-time; provide test-time assertions... etc... and allow me to implement my Javascript application as a collection of independently tested components.

So you want Ceylon then?

Re:We need something... (0)

Anonymous Coward | about 4 months ago | (#47388423)

Doesn't sound like it. I'm not as familiar with Ceylon, but glancing over it, it looks like another statically typed language that can also compile to JavaScript. The OP sounds like he just wants JavaScript with the niceties that we expect from a modern language. One example would be TypeScript [typescriptlang.org] , a superset of JavaScript that compiles down to standard js.

Re:We need something... (0)

Anonymous Coward | about 4 months ago | (#47388421)

Typescript.

Re:We need something... (1)

El Royo (907295) | about 4 months ago | (#47389701)

This doesn't address your compile-to-JavaScript/type-safety issues but for a component-based approach to producing JavaScript apps, take a look at http://enyojs.com./ [enyojs.com.]

doesn't even work (0)

Anonymous Coward | about 4 months ago | (#47386593)

I checked it out, out of morbid curiousity. The demo pages don't even display on Firefox 30 for Linux, which is a pretty common browser. Not display incorrectly, just nothing shows up at all when you click the different demo previews. pretty pathetic. Also I didn't see anything 3d in there at all.

By Neruos (0)

Anonymous Coward | about 4 months ago | (#47386667)

JS frameworks are a dime a dozen, it's like everyone and their grandmother is making one in some form. What really is having is all these JS wrapper modules (frameworks) are allowing developers/programmers, do front-end and now back-end (mongoDB/NodeJS) all with-in JS. As a consultant, it's actually pretty awesome. Because I get tons of work stepping in and fixing things when the "companies dev team" can't figure it out as they all built X years and X products around JS frameworks.

Keep it up script kiddies, you're making me rich!

Re:By Neruos (0)

Anonymous Coward | about 4 months ago | (#47386721)

Lol, ignore my drunk'n'ness. I'm all for JS frameworks, keep them coming!

hipster bro framework (1)

Anonymous Coward | about 4 months ago | (#47387367)

From what I've seem Famo.us is more Famo.us for it's ability to market to hipster cool developers than to normal web developers. When they tire of using Famo.us and something else more hip, cool, "bro" comes along they'll go with that. I mean really, who calls their framework "famous", except for wannabe hipster, cool, "bro" programmers? It only came out this year - I give it another 6 months to hit the peak hype cycle, then it's all downhill from there "bro".

Does the world really need another X. (0)

Anonymous Coward | about 4 months ago | (#47391641)

Yes, the world needs it. Always. Not because we couldn't get along without it, but rather, thinking that you already know enough or have discovered everything worth knowing is how innovation and advancement die.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?