Wait.... Have I got this right?
Instead of using cloud services.. You use the client's computer to run software?
My god.. How did he ever think of this idea. He truly is the reincarnation of Steve Jobs.
Well-funded Meteor poised to impact web development
The developers behind the Meteor open source project say they want to revolutionize how applications are built, and they've just been handed a whopping $11.2m in Series A funding to do it. Meteor is an open source platform for building web applications with rich user interfaces that run on the client rather than the server – …
-
Wednesday 25th July 2012 21:41 GMT BlueGreen
security may be the killer
(puts on paranoia hat)
I'm not going to knock this idea but I disable js, cookies, flash, java and anything else because I don't trust people to get it right. If you rely entirely on client-side js then you eliminate its use people like me (vanishingly few, it must be said) but unless you really, really get it right, you risk putting a lot of people at risk and blowing your reputation (and entire business). Unless your framework can somehow prevent the developers from making stupid mistakes then it will have such mistakes and the whole technology may look bad. And who's to say your framework is itself decently secure?
I don't trust people to get it right because wherever you look there's evidence of negligence and bad practice at every level.
I also wonder about percieved speed. Worked briefly with ajax and was shocked at how slow it was. Was a while ago though.
Tangentially to this, much as I like js and think it's pretty good in its way, we really do need a new browser language, properly typed and much more static, to get decent performance without JIT and whole-program analysis (and not even possible then if someone's fiddled with eval or done something complex with conditional .prototype weirdness, to name a couple). It may make static analysis for security purposes easier as well.
-
Thursday 26th July 2012 08:56 GMT Anonymous Coward
Re: security may be the killer
@BlueGreen
"Tangentially to this, much as I like js and think it's pretty good in its way, we really do need a new browser language, properly typed and much more static, to get decent performance without JIT and whole-program analysis"
How about Dart? I agree it is still in its early days and may not see wider adoption, but is it any good?
-
Thursday 26th July 2012 21:11 GMT BlueGreen
Re: security may be the killer
Wotcha.
I'm not familiar with dart so I had a quick look on wiki <http://en.wikipedia.org/wiki/Dart_%28programming_language%29>. They had an interesting section there on criticisms which I'll let you read, but this kind of thing:
"Static type annotations do not affect the runtime semantics of the code. Instead, the type annotations can provide documentation for tools like static checkers and dynamic run time checks."
makes me very uneasy as it's exactly what I don't want. Obligatory static type checking is vital IMO for performance and safety. Per wiki again:
"Dart programs run in one of two modes. In "checked mode", which is not the default mode and must be turned on, dynamic type assertions are enabled. These type assertions can turn on if static types are provided in the code, and can catch some errors when types do not match. For example, if a method is annotated to return a String, but instead returns an integer, the dynamic type assertion will catch this and throw an exception. Running in "checked mode" is recommended for development and testing. [it continues] Dart programs run by default in "production mode", which runs with all dynamic type assertions turned off. This is the default mode because it currently is the fastest way to run a Dart program."
No, no, no no no no.
I'd say an evolution of JS might be politically and language-istically the only way forward. IMO again.
-
-
Wednesday 25th July 2012 22:00 GMT batfastad
There is no Gozer only XUL
So how does the web application actually get to the client if the HTML is never transmitted over the internet? CDROM in the post?
Also without some sort of server-side processing are they suggesting that JavaScript directly sends data to a database? So you would leave your database daemon port open to the internet and JavaScript connects, authenticates and runs queries? I'm not sure they've thought this through.
Though if they could make the web interface of Twitter not bloated and generally terrible then that would be super! If Twitter exposed an XMPP interface for tweets then that would be great as I wouldn't have to use the web interface. I'm aware of people running Twitter-XMPP gateways but they're always a bit clunky.
I'm going to go a bit ranty here so I don't know where I'll end up...
Firefox (and Thunderbird, Mozilla addons etc) are built using JavaScript and XUL (an XML language that describes a Mozilla interface) and quite a few years ago there was an example out there of someone using remotely-hosted XUL to query the Amazon API and return results to search for books/CDs etc. It was very cool. And it really made me realise how poor HTML/CSS actually is for building UIs in the corporate landscape. I would have loved to be able to develop intranets using server-generated remote XUL code.
The downsides of remote XUL were: i) there was no official water-tight spec, since ii) only Mozilla programs ever needed to run it, iii) it relied on JavaScript to send data to and receive data from the server, iv) there were quite a few bugs when running remote XUL as it was never really recommended/supported. If there had been a form action="" method="" equivalent in XUL then that would have been such an elegant way of building consistent interfaces for corporate and intranet applications.
For describing complex interfaces XUL is pretty much good to go. Look at the Options dialogue box in Firefox and imagine if that was replicated in HTML/CSS. I built a really good private test one evening on one intranet project, where you could query the server using a search plugin and my PHP code returned invoice information in XUL. The XUL code for 10+ intranet screens and dialogue boxes was returned using a single HTTP request. Now I know you can do that easily with DOM manipulation using jQuery and other libraries. But XUL was designed for this from the ground-up (apart from the remote part). My demo looked the part and was snappy to use, just like I'd written it in a client-based language like C / C++ or whatever MS are calling their client language these days.
It just seems like alot of the new "HTML5" technologies are trying to bolt features on to a language that isn't quite fit for full client-side use. And these features already exist in numerous client-side programming languages, or can be easily built using the bare-bones of the language itself. I wouldn't be surprised if you see websites written (designed) entirely in SVG code and JavaScript in a few years because of the inherent limitations of HTML/CSS.
Recently Mozilla disabled remote XUL by default in FF, needing it to be whitelisted. It could have been glorious :(
-
Wednesday 25th July 2012 22:11 GMT batfastad
Re: There is no Gozer only XUL
... Still ranting... Just going to add, of course, HTML was designed to format documents, pages of text etc. Never to create full UIs or applications/games. There are impressive examples of people using HTML to do those things. But think of how much easier it would be if there was a standard remote interface language that you could build a kiosk client application around, using the server-side technology/database of your choosing. XUL could have been that.
-
-
Wednesday 25th July 2012 23:22 GMT Anonymous Coward
@bluegreen
Depends on how it is implemented of course but isn't that everywhere? Unless you set specifics for domains then you must have a hard time on the web. Q? What about internal home networks are you as diligent? Fair play to you if you are. Ajax is fine IMO, prevalent on the web google auto suggest?? Again depends on implementation, for example google disables auto suggest for larger lists.
@batfastard - neat summary, but to be fair W3C are big cogs that have to turn other big cogs such as Apple, MS each with their own interests that is why HTML 5, 6 . . . 7 are slow to deliver what is needed. I now get tired of the need to learn a new syntax, idiosyncrasies of languages so I feel sorry for people who have invested time in Flash, Silverlight, . .. . they just want to create solutions not hit problems. I agree that svg canvas is hard work and the likes of
http://alteredqualia.com/canvasmol/
are hard work when trying to make cross browser. I.E. 9? In Public and Private organisations - what market do they have?
-
Thursday 26th July 2012 21:20 GMT BlueGreen
@AC 25th July 2012 23:22
JS is everywhere, lamentably, but quite a lot works without it. If I have to turn it on for practical reasons such as buying something online (very rare due to same paranoia) I'll run it in a VM, and then I'll drop the webmaster a note saying "please don't". But as I said, much still works.
'internal home network'? It's basically a couple of client machines. Nothing that requires or allows internal browsing, unless I've misunderstood you.
> ...prevalent on the web google auto suggest?? Again depends on implementation, for example google disables auto suggest for larger lists.
Try disabling it then using google. It works fine, just rather old-fashioned. And google gets none of my data except IP addy + user agent string. Google's actually one of the better companies for having stuff degrade gracefully if js is disabled. MS may be the utter worst.
-
-
Thursday 26th July 2012 07:42 GMT Anonymous Coward
I actually tried it...
... and it works as advertised. I'll have to see if they have a package for a decent tool kit like qooxdoo. Then it will be quite attractive. I still prefer to write server code in C++. Why waste CPU cycles? This is my only beef. For apps that need to be deployed quickly and maintained by a few (one?) people, it'll be useful.
-
-
Thursday 26th July 2012 17:30 GMT Oninoshiko
Re: DB client in the browser?
A PROPER database does enforcement, bounds checking, and insures consistancy across tables, atomicy of operations, and permissions checking. It's just ashame that most web-devs have no idea how to use their systems, and so are always reimlementing DB features poorly in their code.
-
-
Thursday 26th July 2012 11:48 GMT Stretch
nothing should ever be based on javascript. horrible slow ancient legacy garbage. They'll probably insist on everything being JSON too. Useless pathetic stripy jumper wearing "creative" people thinking they can code.
But gz on scamming 11million quid out of the ill-informed "investors" (read "suckers"). Should fund their crapple-habit for a few months.
-
Thursday 26th July 2012 11:56 GMT MacroRodent
Don't get it
How is this different from writing a client- server PC application in any old language like we did already in late 1980's / early 1990's?
Javascript? Cross-platform? If the second is the goal, it seems Java applications already were there. Quick throwaway applications? See Visual Basic and similar dumbed-down IDEs.
There must be some kind of Wheel of Reincarnation operating here.
-
Thursday 26th July 2012 13:01 GMT Kubla Cant
Idiot
"The challenge of writing applications that run mostly in the browser, DeBergalis says, is that the application code is running on a system that is far away from the data it needs."
No it isn't. Transport to and from from a server and processing and persisting data on the server are the easy part, relatively speaking. They're both problems for which a wide variety of solutions has been offered.
In most of the applications I've been concerned with in {mumble} years of development, the UI has consumed well over half the resources. Rich browser applications are the worst. The browser offers a rather meagre API. Javascript is a language that has just managed to get itself taken seriously by exploiting a few bizarre features, but it still isn't what you'd call industrial strength. The main selling point is that HTML+Javascript applications can be easily distributed.
Oh, and when did anyone but a rank amateur last send HTML with data?
-
Thursday 26th July 2012 13:02 GMT t_lark
"How is this different from writing a client- server PC application in any old language like we did already in late 1980's / early 1990's?"
-Servers could not push to clients easily
-firewalls broke those applications
-deployment from web interface not hard disk
-scalability
This tech is probably nothing that revolutionary, but a load of existing components put into one coherent framework with a single language to serve both ends. I am somewhat interested, but google app engine is just too cheap that it keeps making me come back.
-
Thursday 26th July 2012 22:32 GMT Michael Wojcik
"How is this different from writing a client- server PC application in any old language like we did already in late 1980's / early 1990's?"
-Servers could not push to clients easily
Not true of some protocols in use as far back as the "late 1980s" (and earlier); and still true of HTTP. So no win for Meteor there.
-firewalls broke those applications
The only special benefit of HTTP, in regard to firewalls, is that typically there are already rules to pass it. Firewalls don't "break" HTTP-based applications because the firewalls are already deliberately broken for HTTP-based applications. And the idea of using HTTP to get around firewalls is certainly not new - it was the primary motivation for (god help us all) SOAP, back in 1998.
-deployment from web interface not hard disk
So what? And there were plenty of network-deployed applications back in the late 1980s and early 1990s.
-scalability
Nonsense. I worked on distributed apps circa 1990 that supported thousands of users on the hardware of the time (including over slow sync and async links). There's nothing magically "scalable" with Meteor or any other web-based approach; we've just thrown a shitload more resources at them.
(Also, can I note in passing that the meteor.com web site is horrible? Yes, yes I can.)
-
-
Thursday 26th July 2012 13:21 GMT Irongut
So this uses javascript thus ignoring the faster, better languages on your client platform like C, Java, etc. Creates web apps so ignoring the native widgets, look and feel, etc of the client platform in favour of a crappy web UI. And, it runs entirely on the client so it ignores the normal advantages of a web application.
So where's the advantage? All it does is pick the worst parts of each technology.
-
Monday 30th July 2012 19:18 GMT Jean-Luc
Errr... security, anyone?
>faster, better languages on your client platform like C, Java, etc.
Yes, because we all know how secure it is to run Java from the web.
A browser is, justifiably, though not always sufficiently, paranoid about its JavaScript execution and can be made more so by NoScript or the like.
I can't vouch for the other benefits of Meteor, but anyone who tells me my browser should execute arbitrary code is daft.
This topic is closed for new posts.
Biting the hand that feeds IT
