Wayland and Weston 0.99.0 snapshots released
Posted Oct 17, 2012 9:45 UTC (Wed) by ms (subscriber, #41272)
I wonder therefore how much further we're going to go down the whole "let's support JS everywhere" route before we finally realise what an awful mistake the whole thing's been and how we really need to slowly migrate away to better designed technologies. Yes, HTML and CSS are fine for simple web pages. But if you want to go down the whole one-page-app route and actually treat the browser as a real programming environment, they're absolutely not fit for purpose.
Once that's been solved, I wonder if anyone will think JS should live on, eg in Gnome Shell support. Are there actually technical reasons to prefer JS over, say, lua, or even LISP (see StumpWM for example).
Posted Oct 17, 2012 10:40 UTC (Wed) by Jonno (subscriber, #49613)
If I sat down today to build a technology for doing cross platform app development I would likely come up with some XML-ish declarative GUI customizable using something CSS-ish. In (X)HTML, almost all elements in the body are interchangeable, they just come with different default style sheets, and while I would certainly have defined a different set of elements with different default style sheets compared to (X)HTML, the principle would be the same. And I would of course use a different scripting language, probably Lua and/or Scheme, possibly Java (as scripts, using BeanShell, not as compiled jars).
Posted Oct 19, 2012 7:55 UTC (Fri) by jezuch (subscriber, #52988)
I did my engineering thesis in this, way back before it went dead ;) It was pretty cool, especially the CSS-like declarations and binding expressions, but the implementation was *horrible*.
Posted Oct 17, 2012 10:41 UTC (Wed) by union (guest, #36393)
The only toolkit that comes close is QT, because you can use QML witch is close to web technologies.
Posted Oct 17, 2012 11:55 UTC (Wed) by ms (subscriber, #41272)
IMO, your last statement, "it suddenly becomes decent language (at least for frontend)" is key - yes, if you are just doing inversion of control, and just wiring simple actions off elements, then JS is fine. As soon as you start doing anything heavier, it becomes horrific. However, it's not clear to me where the problems are JS's own fault and where they're library/implementation issues. For example, the CPS mess that results due to a lack of threading: as soon as you start doing any real IO, any semblance of control flow you thought you had has rendered your code to a mess of spaghetti. But the ECMAScript 5 spec is, IIRC, silent on the issue of threading and IO in general. The many definitions of bottom (false, undefined, null), the endless variations of implementations, the endless duck typing and random heuristics and general lack of any degree of confidence that different libs will actually work together - there is no static way of validating that one library will not do things that are thoroughly incompatible with other libraries. NodeJS certainly exacerbates these problems to the Nth degree, but they're there in the browser too.
The issue about learning the language "properly" is that it's difficult to when certain aspects of the language (e.g. the "new" operator) were put there deliberately to "lower the learning curve" but serve merely to confuse. As you say, if you know what to stay away from then it perfectly fine, but then the same is said of Perl. And complex Perl might actually be more readable than complex JS! Once you have learnt the language properly, you realise how significant the lack of sensible language features really is; the threading issues in particular. Promises and friends help to a degree, but really you just can't write large maintainable code bases that do anything particularly complex. Now if you thus treat JS as a DSL for the browser, that might be ok, provided you don't try and do anything too complex in the browser (though the C-like webGL is clearly complex from the exact opposite end of the spectrum!). But firstly people want to do more and more in the browser, and secondly, JS keeps being used as a more general purpose language outside of the browser, which just strikes me as odd.
HTML is fine as a document structuring DSL when you actually get to use it for that, but most new single-page-apps start with a blank HTML file just loading scripts, and all DOM elements are constructed programmatically from the JS. Programmatic construction of GUIs is (IMO) a poor idea at best because it tends to put off anyone with any actual design skills from being involved. Graphical design of GUIs makes a whole lot more sense, at least to me, though I'm aware this is another can of worms that I don't really want to open! I remember in the 1990s writing applications under RISC OS. The graphical GUI designer, !WinEd (http://www.riscos.info/index.php/WinEd) was superb and I have not worked with anything that makes GUI design so intuitive and simple since (having done bits or more from ncurses, Java Swing/AWT and Java SWT, and HTML/CSS/JS amongst others).
Posted Oct 17, 2012 12:39 UTC (Wed) by drag (subscriber, #31333)
Posted Oct 17, 2012 12:50 UTC (Wed) by ms (subscriber, #41272)
Posted Oct 17, 2012 12:56 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
Posted Oct 17, 2012 13:01 UTC (Wed) by drag (subscriber, #31333)
Worse is better.
Why is windows dominate on the desktop? Why did Unix beat out other much better optimized systems? Why did Linux become the most popular posix-y system when it's full of so many idiosyncrasies and the BSD OSes were technically superior for many years early on and were just as free?
The answer is that implementation differences in technology pale in importance when compared to external factors and realities.
The corollary to this is that technical superiority isn't going to do much for you in terms of marketability nor usefulness for your target users and developers. Ignore external realities at your peril.
Posted Oct 17, 2012 11:10 UTC (Wed) by canatella (subscriber, #6745)
- development cycle is easy and the tools are there,
- css is way more flexible then having to spec all padding and margins in code,
- graphical designer can focus on ui design, you focus on code.
2 years ago I was cursing against it but now, with html 5, they're actually making developers life simpler. There is still the problem that you have to design the look of your application while using toolkits you don't have to but then there exists design that you can reuse and it might also be considered as a plus by some.
Posted Oct 17, 2012 11:41 UTC (Wed) by nye (guest, #51576)
I generally agree that JS gets a bad rap, but there are problems with it that go beyond problems with any particular implementation - some part of the language itself are distressingly bad.
The exact behaviour of its semicolon insertion, in particular, is unforgivable.
Posted Oct 19, 2012 8:10 UTC (Fri) by jezuch (subscriber, #52988)
I don't know. I never had to think about it while writing code. For me this means that it's rather decent.
Much, much, MUCH worse is how all numbers are half-float, half-integer (with limited precision, IIRC). That's just... unspeakable.
But, other than that, I rather like this little bugger.
Posted Oct 17, 2012 12:08 UTC (Wed) by Lennie (guest, #49641)
The web has one dominant scripting language, as you probably know pretty much every part of computing always gravitates to adopting one or very few system languages, desktop operating systems and word processor document formats, routing protocols and so on. Or in this case scripting language.
The developer which needs to implement the embedding obviously can see the advantage (easier and uses less memory and maybe even a little bit less CPU time).
Posted Oct 17, 2012 12:35 UTC (Wed) by drag (subscriber, #31333)
I don't care one what or the other what language they have used.
They have chosen it because it is very popular language that is familiar with the largest number of possibly interested people, it's standardized, and ties into other technologies they are leveraging.
The point is that it's completely scriptable, so whatever type of window manager functionality you want you can spend your time concentrating on writing the functionality rather then writing a window manager.
But to each their own. If you want to write a new one from scratch then go for it.
Posted Oct 17, 2012 19:38 UTC (Wed) by raven667 (subscriber, #5198)
Posted Oct 17, 2012 21:03 UTC (Wed) by dgm (subscriber, #49227)
Posted Oct 17, 2012 23:41 UTC (Wed) by man_ls (guest, #15091)
Of course it is possible to do aberrations against Nature in it, but that is true of all languages. Lua is a bit horrible too once you get to meta-tables. The object model in particular is awful; the good thing is that you can build your own with a few lines of code.
Posted Oct 18, 2012 22:27 UTC (Thu) by alonz (subscriber, #815)
Posted Oct 19, 2012 0:17 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
Posted Oct 22, 2012 3:32 UTC (Mon) by cmccabe (guest, #60281)
I agree that duck typing is one thing that ECMAScript got right. However, Golang (Google Go) is able to do this without giving up static typing. I think that's the way to go... no pun intended. :)
Posted Oct 22, 2012 7:52 UTC (Mon) by man_ls (guest, #15091)
For some applications a single-process server may not be right, but for the rest convenience usually trumps performance. (Witness MongoDB beating Riak or Cassandra.) Amazon rents cheap two-core servers, very convenient to run node.js on. In fact node.js uses two cores: one for receiving requests and another for servicing them.
There are a couple of ways around a single-process server on a multi-core machine. One is to run many stateless node.js processes on a server. Another is to modify the V8 engine to run many threads in the same process and synchronize them; it is a more definitive solution, even though the engineering costs may be high. I don't doubt that Google can make it if they try.
Posted Oct 22, 2012 7:53 UTC (Mon) by man_ls (guest, #15091)
Posted Oct 25, 2012 9:34 UTC (Thu) by cmccabe (guest, #60281)
Personally I find the claims of "orders of magnitude faster than other traditional servers" pretty hard to swallow, but such claims are also "traditional" in their own way, so who am I to complain? :)
> For some applications a single-process server may not
> be right, but for the rest convenience usually trumps
> performance. (Witness MongoDB beating Riak or Cassandra.)
It doesn't really make sense to compare Cassandra to MongoDB and Riak, since traditionally Cassandra is used with a much weaker consistency model.
Posted Oct 25, 2012 9:38 UTC (Thu) by man_ls (guest, #15091)
Posted Oct 30, 2012 15:55 UTC (Tue) by cmccabe (guest, #60281)
Note to nitpickers: a lot of these datastores can be configured to run in different consistency modes. For example Riak has last_write_wins, and Cassandra has the ability to do quorum writes, etc. In general, though, if you find yourself obsessing over these settings, you might just be using the wrong datastore for the job. They have different design goals.
To come back to your particular situation, denormalizing the data that you store in MongoDB is a choice that you have made. You could do the same thing with SQL, or any other strongly consistent data store.
On the other hand, you could say that the limtiations MongoDB forced you to go down this path, since it doesn't support SQL-style transactions, foreign keys, and so forth. That's a fair point.
Posted Oct 22, 2012 3:18 UTC (Mon) by cmccabe (guest, #60281)
Rather than "using scripting to make something do whatever," why wouldn't I just write my own window manager?
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds