We’re at an inflection point in the practice of constructing software. Our tools are good, our server developers are happy, but when it comes to building client-side software, we really don’t know where we’re going or how to get there.
Happy times upstream · The art and science of building server-side code is just fine, thank you; the technology’s breadth and polish has been ramping for years and still is.
More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP.
More or less everything is built with an MVC-or-equivalent level of abstraction, and there are good frameworks to help us work sanely and cleanly. It’s a pity some people still build important apps in PHP and Spring, but those aren’t choices anyone is forcing them to make.
We still have angst over dynamic and static typing, but I think the trade-offs are reasonably well understood, and we have really good programming languages in each flavor. I use both, and in some cases the choice is obvious; check out the Bánffy-Bray criteria.
Concurrency · Functional Programming is getting a foothold on the mainstream, because if you care about performance you care about concurrency, and ordinary humans can’t do concurrency at scale (or really at all) if they’re sharing mutable objects.
A lot of people love Erlang but not that many are using it in production even though it gets concurrency and failover profoundly right, because types and classes.
Clojure’s concurrency primitives are functional, efficient, and beautiful; but being a Lisp is a handicap (empirically I mean, even if unlike me you grant the ineffable wonderfulness of Lisp). Scala discards loads of Java ceremony and has a plausible actor model; but also way too much syntax.
NodeJS isn’t really functional, but if everything’s a callback and you’re single threaded, who cares? Anyhow, my biggest gripe with Node is the JS part at the end; more on that later.
Go has made a deep impression on me, even though it doesn’t make me smile, the way C and Java and Ruby and Clojure did successively over the years. My intuition is that its types offer enough object-flavored utility to get by. And my strong intuition is that Goroutines and typed pipes hit a huge 80/20 point, ushering developers smoothly into writing functional code just because it’s easy and straightforward and readable. The next substantial server-side piece of software I build will be in Go.
And hey, if none of the above quite gets us where we want to go, we’ve got Rust and Elixir and Dart looming over the horizon; none built by dummies.
Storage, oh yeah · The persistence options are so great now. I’ve been sort of cool to relational data stores for decades, particularly at runtime in performance-critical systems. But they have their place, and there are multiple good open-source ones.
And on the postrelational side things are just fine too. Options range from lightweight memory caches to things that can operate at behemoth scale. Like for example Cassandra; If you’ve heard any of the recent presentations by Adrian Cockcroft about what Netflix does with it, your mind will have boggled appropriately.
On top of which everyone’s internalized that disk is the new tape and is using it sensibly in that way.
On the other hand...
The client-side mess · Things are bad. You have to build everything three times: Web, iOS, Android. We’re talent-starved, this is egregious waste, and it’s really hurting us.
Mobile sucks · I’m going to skip the differences between Android and iOS here because they’re just not that significant in engineering terms. Anyhow, here’s the suckage.
First of all, you have to do your mobile development twice.
The update cycles are slow. Days in the case of iOS, hours for Android (compared to seconds for browser-based apps). What’s worse is that you can’t even count on people accepting the mobile-app updates you send them. Got a critical data-losing account-compromising privacy-infringing bug? Sucks to be you.
The devices are memory-starved, CPU-starved, and battery-starved.
There are loads of form factors and it’s getting worse.
You don’t get a choice of languages; if you hate both Java and ObjC, get another job.
Unit testing is a bitch.
Fortunately for your users but unfortunately for you, the UX-quality bar on mobile is high and there is no fast or cheap way through; it requires inspiration and iteration.
The right way to use the Internet is to click in the search box at the top of your browser and type in what you want, and find it, and click on it, and use it. But if the information or service or whatever that you’re looking for has been sucked into mobile, you have to install the app, which means another level of search in the mobile-app store, where search isn’t nearly as good as what Google and Bing provide.
You can’t make money. Seriously, Apple is always talking about the billions and billions they pay out of the app store, so why is it that I don’t know anyone who’s making serious money on mobile apps?
Of course, the HTML5-rocks crowd is at this point rolling their eyes and pointing out that if everyone just built mobile web apps, then all these downsides (especially the first) would melt away.
Except for...
Browsers suck too · This is an unfashionable opinion, but I can’t see why it’s controversial.
JavaScript is horrible.
> [5, 10, 1].sort();
[ 1, 10, 5 ]
Et cetera. Thus Coffeescript and Dart and other efforts to route around TheElephantInTheRoom.js.The browser APIs suck too. Sufficiently so that jQuery (or equivalent) is regarded as the lowest level that any sane person would program to; in effect, the new Web assembler.
Thus, for actually building applications, you’re going to have to pick a higher-level framework. There are lots of them and they compete vigorously, it’s easy to poke around the Web and find knockouts and cage matches; one good high-level comparo is Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012) but wait it’s eighteen months old thus probably now wrong, which is a symptom of the problem. “What problem,”you ask, “choice is good, right?” It is, but this isn’t an orderly choice, it’s a Cambrian Explosion. I’m sure the software archeologists of 2113 will enjoy studying it, but it’s a problem.
(Oh, and also read Frameworkless JavaScript by Tero Piirainen.)
CSS sucks too. I’d explain why, except for Dan Cederholm wrote Why Sass? so I don’t need to. Also, check out Luke Page’s Less vs Sass vs Stylus; did I mention “Cambrian explosion”?
There’s no app store for your browser-based client with anything like the scale and size and polish of those for mobile apps.
OK, I know that at every big Web-centric conference, bright-eyed enthusiastic young true browser believers show you how HTML5 rocks and they can write apps that use the accelerometer and microphone and (wait for it) are indistinguishable from a mobile app!
Well, then why isn’t everyone just doing that? Hint: See the bullet points above.
When I said “Mobile sucks”, I wasn’t talking about engineering suckage; in fact, Cocoa Touch and the Android app framework are both very decent GUI-building platforms, embodying a lot of history and hard-won lessons. Crucially, for most of the things you’d want to put in a UI, there’s usually a single canonical solid well-debugged way to do it, which is the top result for the appropriate question on both Google and StackOverflow.
But look at all the energy going into browser tech; surely it’s going to catch up with mobile tech any day now? Maybe, except for the mobile frameworks are being polished and expanded by elite teams at Apple and Google, including some of the world’s best GUI engineers. So I’m sort of expecting the picture to remain fairly stable, going forward.
Diminishing returns · I’m an old guy, and I remember the first wave of Web apps going through, and a whole generation of Visual Basic and Motif and Java and Win32 clients being swept out with the trash, because people liked dealing with everything through a browser.
Of course, fifteen minutes later, software VIPs started saying how the browser’s interface was too dumb and insufficiently responsive and we’d have to find plan B, and I couldn’t help noticing that every one of those VIPs was trying to sell a proprietary plan B. Now we have Plan B and at least it’s right there in the browser, and standards-based.
But I’m still dubious. Yeah, I like it when the app is responsive to gestures, and objects slide in and fade out; but all that feels like icing on the cake, and I confess to wondering how far past the 80/20 point — a well-designed Web app with most of the logic on the server — the ROI stays positive. And I totally fucking hate having four independently-scrollable areas on the screen controlled by weird-looking JavaScript-genius-handcrafted scrollbars. And then I’ll be working with some fancy single-page app, accidentally hit the tab key and everything goes a little sideways. I hate it worse when a nontechnical friend or relative gets caught in this sort of strange loop and I have to try to explain what’s going on.
What’s next? · On the server side, no drama I think; everything gets smoother and better. These are the good old days.
On the client, I just totally don’t know. Historical periods featuring rococo engineering outbursts of colorful duplicative complexity usually end up converging on something simpler that hits the right 80/20 points. But if that’s what’s coming, it’s not coming from any direction I’m looking, so color me baffled. Maybe we’re stuck with clients-in-triplicate for the long haul.
Contributions
Comment feed for ongoing:
From: John Aho (Jan 08 2014, at 23:26)
I'm currently doing a rough survey of 400-500 javascript libraries and I'm struck by how much neat stuff is out there and how many people have reinvented the wheel.
Just doing a really rough survey of this many JS libraries is folly because I can't possibly hope to get a firm grasp of what they all do. I can pick through them looking for shiny things and that's what I've settled on.
[link]
From: Matthieu Riou (Jan 09 2014, at 00:26)
Working with many front-end and backend engineers over the year, I've grown the conclusion that while backend engineers are more Leonardos, while front-end engineers are more Michaelangelos. In other words, both great artists and engineers but one with a stronger scientific propensity and the other better artist. I know, this probably sounds like a simplistic cliche but I'm convinced there is some truth to it. And you have to say, the landscapes as you described them sort of corroborate that theory.
[link]
From: Paul Morriss (Jan 09 2014, at 02:25)
I wonder if people go for apps because they think they can make money out of them. I wouldn't know how to start selling an HTML5 app or how to do the equivalent of in-app purchases. I'm sure it's possible, but I wonder if others like me don't know either, so go for an app.
[link]
From: Blizz (Jan 09 2014, at 02:35)
I know people don't care about it, but you forgot about Apache Flex/Adobe Air.
[link]
From: Kew (Jan 09 2014, at 03:56)
> people still build important apps in PHP
It'd be fair to qualify that as "old-school bare PHP", because PHP does have a bunch of decent MVC frameworks, and the language itself has grown to have namespaces, closures, list comprehensions, etc., so it's quite possible to develop a really good application in PHP if you stay away from language's old sins.
[link]
From: Weland Treebark (Jan 09 2014, at 04:46)
Hi,
I posted this on HN as well (your post made the homepage), but I thought it would be nice to drag it here as well. I distiled it a little, if you don't mind (removed some of the not so nice language).
I think this paints a rather meagre picture not so much of software, as of software *development* in 2014:
> More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP.
A lot of things that shouldn't talk HTTP are expected to just because there's an army of programmers who don't know better. Also, it's actually hard to make things talk HTTP, partly due to HTTP itself. However, much of this complexity is hidden, leading many people to think that
> devices are memory-starved, CPU-starved, and battery-starved.
In what freezing hell is a dual-core, 1 GHz computer with gigabytes of RAM and tens of gigabytes of storage and 3D acceleration that can fit in my pocket memory-starved and CPU-starved?
The fact that so many applications perform computationally trivial things, but lag on such devices, has nothing to do with their processing power being low, and has everything to do with them being badly written. It takes a lot of effort to make an application lag on such a system.
I think this is, to a great extent, a product not so much of bad *application* programming per se, but a product of bad *framework* development. I don't mean just the latest programmer-facing JS framework, but the entire technological foundation. I find it utterly ridiculous that we have such things as Todo applications that need HTTP. They use a database on a server to save, what, tens of kilobytes, at best, eating battery like crazy because it needs a network connection for that. All this while running on a system that can locally store gigabytes of data.
And yes, I really believe this is a result of poor programming practice. No lead developer should consider such a tool to be of production quality. I agree that the technically better alternatives suck (you have to write the same application *at least* twice), but nobody ever said programming was either easy or non-redundant.
> Browsers suck too
Browsers are fine as long as you use them for what they are meant to be used: browsing HTML files. Seriously, browsers have been just fine and dandy since the days of Opera 6.
What does suck, indeed, is when people try to use tools that were meant to make HTML docs look nice to build an office suite. They inevitably end up with an office suite that sucks, but that's not the browser's fault.
[link]
From: Matěj Cepl (Jan 09 2014, at 05:06)
> There’s no app store for your browser-based client with anything like the scale and size and polish of those for mobile apps.
https://marketplace.firefox.com/ (or any other marketplace you build with the server freely available at https://developer.mozilla.org/en-US/Marketplace and yes there is also https://developer.mozilla.org/en-US/Marketplace/Monetization).
[link]
From: Ryan N. Bell (Jan 09 2014, at 06:12)
This is probably one of the better synopsis that I've seen since the Web 2.0 conferences I attended a decade ago. I was happy to see that a lot of the inferences I've made to the software engineering space lined up fairly well.
I do think that there's some opportunity in the mobile space with Xamarin and the MonoTouch and MonoDroid libraries, especially with the recent announcement about them partnering with Microsoft. However, it's still a very immature product and hasn't really developed great documentation or best practices except through third parties. Overall, though, I think it sets a good example of potential and reducing obstacles to successfully implement cross platform native applications.
[link]
From: Simon St.Laurent (Jan 09 2014, at 06:15)
Are you and front-end Web technologies ever going to be friends?
I think back to Wired 3.10, and I think through the whole SGML-for-the-Web dream, and I can't help but think you repeatedly missed one of the most visible 80/20 points in computing. It's proven itself more than good enough time and time again, but you keep wanting that extra 20% in various dimensions.
I'd like to suggest that you spend some time building web apps. Without frameworks, starting with HTML, then layering on CSS and JavaScript. You might be surprised by how much you accomplish, and how quickly the nits vanish from your focus.
(And if you wander into Web Components, you might even see how some of your visions for extensible vocabularies are coming to pass from a different direction.)
Thanks,
Simon St.Laurent
Web Grouch
[link]
From: Nils (Jan 09 2014, at 06:39)
Actually I was not excepting such negativism like "Browsers suck" and "Mobile sucks" but rather what technologies and languages I should learn.
In 2013 I learned Go and played a bit with JavaScript and Three.js (in addition to my day job as a C++ developer). What I really love about Go is the philosophy behind the language. Namely not making things unnecessary complicated. I could learn easily Go, thx to its 50 pages spec and simple convetion and became productive with it quickly. However when it comes to the tooling Go still has a long way to go. An IDE with refactoring support is missing, as well as a proper debugger (something like Visual Studio or Xcode has). Also if you try to build an app with a gui Go is probably not the language to choose, all you get are OpenGl bindings.
I don't completely agree with you part of "things that suck" especially for mobile you list: "The devices are memory-starved, CPU-starved, and battery-starved." That does not suck, it is just the way it is. I think also for the other points iOS development is just fine. Except that you could argue that "it sucks" that you are limited to C, C++ and Objective-C for iOS and other languages are not supported. Also "Fortunately for your users but unfortunately for you, the UX-quality bar on mobile is high and there is no fast or cheap way through; it requires inspiration and iteration." That simply is a challenge, not something that sucks ;)
I would reduce the suck part mostly that standards failed: For JavaScript alternatives exist, the W3C however failed to fix Javascript or provide ways for the alternatives to work on all browsers. (bytecode standard, for example?) And recently the MPAA joined.. Another commitee that failed IMHO is the C++ standards committee. They failed to address the most serious problems the language has, its compilation models. Header files are just a huge pita to deal with and are responsible for slow builds. Meanwhile all the commitee does is declaring things like boost::filesystem as a standard..
But now enough of the bitching ;) Question should be, can we do better? At the beginning you mentioned functional programming, but did not go into details (better abstraction, thinking in terms of data transformation, immutability, etc..) I am still unsure what to look into this year, but it will probably be Haskell or F# (you did not mention these, why?)
[link]
From: Mark (Jan 09 2014, at 06:54)
Given that
"JavaScript is horrible."
Followed by
"You’re going to have to pick a higher-level framework"
It seems odd to go look for the answer in an article about seven JavaScript-based frameworks.
I am convinced cross-compilation to JavaScript is the way to go for the foreseeable future. It has already been working very well for years with GWT, and with the smartest people from that community (with Google behind it) now putting their efforts into Dart, it will become even better.
[link]
From: Dennis Doubleday (Jan 09 2014, at 06:54)
Pretty good roundup. I'll ignore the gratuitous shot at Spring, which is perfectly good way to create modularized, unit-testable, server-side apps.
You maybe should have mentioned that there are noteworthy attempts to reduce the "need to write it twice" mobile apps problem. For example, Xamarin/Mono allows you to write-once mobile apps in C# that run on iOS, Android, and WP8.
Another approach that reduces the need to rewrite is WebView for the UI portion, the rest of the app native.
[link]
From: Paul W Homer (Jan 09 2014, at 08:16)
I agree with you on pretty much all our your points. Over the last couple of decades GUIs have gone from being expensive to being crazy expensive. They are prettier, but often way more disorganized and untrustworthy. Given all of the time spent, the number of programmers involved and the amount of stuff we know, I find it all rather disappointing. And yet I haven't seen any real plausible alternatives on the horizon either.
Paul.
[link]
From: Ben Aston (Jan 09 2014, at 08:40)
>> JavaScript is horrible.
>> > [5, 10, 1].sort();
>> [ 1, 10, 5 ]
If all it takes to dismiss an entire language is a single contrived example using sort then I'll give you a single counter example.
JavaScript is good.
> var numbers = [1, 4, 9];
> var roots = numbers.map(Math.sqrt);
/* roots is now [1, 2, 3], numbers is still [1, 4, 9] */
On the other hand JavaScript outstanding features such as supporting both object oriented and functional programming styles, all objects are maps, a has data-transfer format as part of the language (JSON), has a terse syntax, is performant, has outstanding features on the way (e.g. generators and array comprehensions) and is ubquitous (no small feature).
[link]
From: Seán Nealon (Jan 09 2014, at 08:53)
> ordinary humans can’t do concurrency at scale
> (or really at all) if they’re sharing mutable objects
Right, that's why databases remain unpopular.
[link]
From: Andy Edwards (Jan 09 2014, at 09:35)
I like how you didn't even mention desktop apps for the client side :
;) Obviously there are few desktop RIAs these days, but the desktop world is a mess too. Java failed to gain acceptance for cross-platform desktop apps, and I don't know if there's any favored cross-platform desktop language these days.
[link]
From: Andy Edwards (Jan 09 2014, at 10:00)
I think eventually the browser will become the home of all applications, except for extremely low-level ones. Many will be stored locally though instead of downloaded every time you visit a website. But I think (hope) a virtual-machine based language will be used instead of JavaScript. I also hope the DOM becomes less used in favor of apps doing everything in a canvas. Then we would have a real write-once, run anywhere language.
[link]
From: Peter (Jan 09 2014, at 11:34)
Puh, some interesting statements in the section about concurrency: First, Node.js isn't single threaded at all, second: I really don't see any constraints in using a object orientated approach to concurrency, objects can encaplusate resource access pretty well and object pools can do even more.The update cycles are slow. Days in the case of iOS, hours for Android ... well, yes, the deployment is obviously more time consuming. But how often do you deploy a web application to your production system? every minute? every hour? once a day? certainly not.The devices are memory-starved, CPU-starved, and battery-starved. Okay, so what about netbooks? Currently Android devices come with about 2GB RAM or higher and a 1Ghz cpu. This is fairly compareable to netbooks, I guess.You don’t get a choice of languages; if you hate both Java and ObjC, get another job. Not true for Android: Java, C++, meanwhile Python, PHP ... yes, on a Android Device. IOS at least gives you one alternative approach because C++ - code can be used within an Objective C appication. Also the ADF mobile adresses this problem where you can program in Java ... yes, also for IOS.
" I don’t know anyone who’s making serious money on mobile apps?" .... they are rich clients. The business mostly doesn't monitize the app directly rather then through In - App - Billings or through the service the app is using. Games for mobile device...See More
[link]
From: Dan Tao (Jan 09 2014, at 11:49)
Of course I'm going to be inclined to defend JavaScript, as someone who uses the language a lot (and enjoys it); I'll admit that. Very predictable on my part.
That said, even if I weren't, I think I'd be pretty disappointed by your single example of why "JavaScript is horrible." You say "more on that later" (on your gripe w/ NodeJS being the JS part) and then provide this one example, plus "Et cetera." Very hand-wavy.
I won't dispute that JavaScript has many rough edges; the built-in sort method is an obvious example. But focusing on details like this really misses the big picture, which is particularly surprising to me given how big-picture this post is. And to me, as far as languages go, JavaScript is way up there with the better ones.
If I may use an analogy: I could argue that the Taj Mahal is a horrible work of architecture by pointing to some crumbling bricks here and there and then adding "Et cetera."
I realize you're leaning on our collective understanding of the many inconsistencies and weird behaviors of the language; but in my experience all of these tend to be fairly esoteric details and poor arguments against the language as a whole.
Anyway, I also recognize the absurdity of me focusing on a small detail of your post, when my very objection is that you focused on a small detail of a language I happen to like. And yet here we are! Oh well :) I really did enjoy the post overall.
[link]
From: John Grant (Jan 09 2014, at 11:56)
I'm baffled there's no mention of the MV*, Google sponsored, JavaScript framework, AngularJS?
[link]
From: Gavin B (Jan 09 2014, at 12:31)
Javascript - go the whole hog:
The Full Stack!
End-to-End JavaScript: Node.js And MongoDB
http://coding.smashingmagazine.com/2013/11/21/introduction-to-full-stack-javascript/
[link]
From: Feretseer (Jan 09 2014, at 12:44)
Such a noob. I suggest you spend more time studying solutions instead of posting ridiculous blogs with incorrect information.
[link]
From: AlanL (Jan 09 2014, at 12:55)
> And I totally fucking hate having four independently-scrollable areas on the screen controlled by weird-looking JavaScript-genius-handcrafted scrollbars.
Your employer was of course one of the first egregious offenders in this regard, in the now-defunct RSS reader whose name I have already forgotten.
[link]
From: Luke (Jan 09 2014, at 13:59)
You mentioned Scala, Dart, Elixer and Rust, but you should also check out Ceylon:
http://ceylon-lang.org/
[link]
From: Tuukka Norri (Jan 09 2014, at 14:33)
What would you use instead of Spring?
[link]
From: John Dougan (Jan 09 2014, at 14:57)
On the somewhat-very-over-the-horizon front, I have some hopes for Newspeak with the Hopscotch GUI framework.
http://yowconference.com.au/slides/yow2013/Bracha-NextGenerationWebLanguages.pdf
[link]
From: Romario (Jan 09 2014, at 15:07)
Your comment about JavaScript being horrible
[5, 10, 1].sort();
[ 1, 10, 5 ]
is a bit judgemental.
We all know that JS uses dynamic typing i.e. values have no types attached to them. So we can't expect it to treat those numbers as integer because the array elements are treated as string by default. In order to treat them as integers, a hint from Flanagan's JS book:
[5, 10, 1].sort(function (a,b) { return (a-b);});
[link]
From: Graphik_mess (Jan 09 2014, at 15:52)
The client side sucks predominantly due to the use of Javascript. JS the language is often the first and only language that front end 'engineers' learn and thus they lack a deep and historical appreciation of the craft and art of writing software.
I am also convinced that there is a correlation between the programmer's IQ and the language they are using. I suspect that Javascript only developers have the lowest IQs of all programmers.
[link]
From: jeff Barbose (Jan 09 2014, at 16:24)
What you call a "mess" on the client side is your square-pegging the uniformity of the the backend services story into the amorphous-blob hole of client-side diversity.
There is no one-size-fits-all. Any attempt at grand unification always tends towards least common denominator (web apps included), and it's been shown again and again that no consumers really want that.
Apple, for example, can and does and must care about users, because they sell devices. And so exploitation of device hardware must be paramount. So, so long to least common denominator approaches or anything that doesn't give ready and full access to device hardware features.
[link]
From: Brendan (Jan 09 2014, at 17:15)
Is Go another PLOP (Place Oriented Programming) language? (see Rich Hickey's 2012 talk, "The Value of Values"). In particular, for a young person with relatively fresh brains and little or no historical programming lingo "baggage", why would Lisp (Clojure) be a handicap?
[link]
From: Tommy (Jan 09 2014, at 17:56)
Seems pretty spot on, though I don't get the pot-shot at Spring, and kinda resent it being lumped in with PHP. What exactly should we use instead?
[link]
From: Uday Subbarayan (Jan 09 2014, at 18:26)
a) Good summary
b) "More or less everything is expected to talk HTTP, and it’s really easy to make things talk HTTP."
Not any more...now we have websockets, sure it's an extension(for now) to HTTP but a different protocol.
Happy New Year.
[link]
From: Karl (Jan 09 2014, at 18:58)
In my opinion, concurrency on the client side has been pretty much "solved" since Grand Central Dispatch. If you really understand it, it's a fantastic way to do concurrency.
Essentially I view each GCD queue as an independent timeline. Operations that are scheduled on different timeline have no guarantees about synchronisation, so they may be executed in any order or concurrently on separate cores. It's quick and easy to schedule operations on to queues, and the system maintains the queue<->thread<->core relationships, so you don't have to bother with that.
Understand that, then learn about dispatch groups. You'll then have no problems recognising what can be made concurrent and you'll easily be able to do it for 99% of cases.
[link]
From: Jake Tracey (Jan 09 2014, at 19:24)
Fantastic post. I missed your writing.
I think you'll find that the majority of the issues you have with front-end will be worked out by the end of 2014, with new versions of CSS and ECMAScript becoming commonplace.
There's currently a few major front-end frameworks vying for the throne, and overall this semi-competitive approach leads to the best possible outcome.
I'm looking forward to the next 12 months!
[link]
From: Bill Strickland (Jan 09 2014, at 20:39)
Remind me again why anyone should care what a guy with a blog full of layout bugs that looks like something straight out of 1997 thinks about front end development best practices.
[link]
From: Noone Special (Jan 09 2014, at 21:05)
@Romario,
> We all know that JS uses dynamic typing i.e. values have no types attached to them. So we can't expect it to treat those numbers as integer because the array elements are treated as string by default.
This makes no sense, whatsoever. JavaScript was originally a poor-man's Scheme. If you look at Scheme, you'll see how completely wrong JavaScript got dynamic typing and numbers. The whole mess of == vs === should be proof enough that JavaScript needs a bullet to the head.
[link]
From: Troy (Jan 09 2014, at 21:18)
I really like Xamarin's story of bridging the ObjC/Java divide in mobile.
Haven't shipped anything with it but the idea of using a well-defined and relatively battle-tested language environment like C# 5/ Net 4.5 as the neutral meeting ground is fun (Xamarin is slipstreaming behind tons of stackexchange etc. C# content).
This summer I was playing around with Xamarin on Ouya, while it was too slow for this year's hw, I think this year's Ouya 2 will be performant enough.
Xamarin's really got the "One Ring" here, LOL. Microsoft could have it too if it were serious about re-creating Xamarin's cross-platform raison d'être.
[link]
From: James Katt (Jan 09 2014, at 23:16)
If you don't know anyone that makes money on iOS apps, then you simply are out of the loop.
Those billions that Apple is paying out to developers are going to many developers. They just don't know you nor you them.
[link]
From: jmarranz (Jan 10 2014, at 02:30)
I agree with your 80/20 point of view, JavaScript code maintenance can be a nightmare.
There're hybrid approaches like Twitter's to increase the 20% without converting your single page interface web app into a maintenance nightmare, hurt SEO and they say performance is better:
https://blog.twitter.com/2012/improving-performance-twittercom
The interesting part of Twitter tech is the previous version of twitter.com was heavy JS based client side calling to server using official Twitter REST APIs.
Technologies like ItsNat uses this approach to manage DOM in server side in Java (or other JVM lang) with the same W3C DOM APIs but generating the same JS code.
http://www.itsnat.org
[link]
From: Bjarke (Jan 10 2014, at 02:33)
While I agree with a lot of points, there are also some huge advantages on mobile. On web it would not make sense to limit yourself to one browser, but on mobile you an actually do something solely for iPhone, iPad, Nexus etc and still have a business. And then there is huge advantages, especially if you are building more complex apps. For one thing you get the entire payment workflow. And I can think of a bunch of companies making money on the app store. Evernote, Wunderlist, Filmic etc, etc.
[link]
From: Samo (Jan 10 2014, at 02:44)
Isn’t it a bit naïve to talk of the "client side" as if it were one, single thing?
The "server side" that is mentioned in this article is all well and dandy, but none of the technologies mentioned seem (to me—I might be wrong?) like distinctive platforms. It’s all a flavor of Linux, and as such it’s actually one, single environment. It’s not OS X server and it’s not Windows Server and rarely BSD or an even more obscure Unix variant.
Surely setting up and running the same "sever side" software and applications across all of the above mentioned platforms isn’t as trivial and easy as to be regarded as a "solved" problem, no?
So why are people _still_ considering a Windows Desktop, an Android Phone and an iOS Tablet as essentially the same thing? Because they all have a screen?
There never was any "unified" software platform that spanned as many different devices as people criticizing frontend tools would want, and it will be a long time until there is (I’m thinking Star Trek technology is here-time). Yes the tools suck, yes it’s still too frustrating to develop for, but it’s also unfair to compare it to an environment that is basically one operating system with a set of tools that have matured over the last decade, I think.
[link]
From: Ludovic Urbain (Jan 10 2014, at 03:13)
I'll stop at the first paragraph, no point in pointing out the many counts of wrongness in this post...
1. Server-side code is as bad as ever, and there is yet to be a reasonable server-side language that is not C (which is not reasonable, but at least not slow).
2. HTTP is retarded, it takes humongous messages just to send one json-encoded object/item/whatever, this is incredibly impractical for any kind of well-design web application.
3. MVC is a bad abstraction, for many reasons, I don't think anyone needs an explanation for that, suffice to say it's based on OOP to outline the insane bloat that goes with that design style. Separating views from moving parts is critical, but the MVC approach is just one bad OOP way to do it. Whatever is on that level of abstraction is definitely not enough abstraction for me.
4. Laughing about PHP is pointless. If you think Ruby or Java are better, you have missed the FP>OOP boat. If you think Python is better, well you're probably right. 30 years later, the only valid option for a high performance production solution is still called C.
When it comes to development languages for prototyping, Python and PHP are the best choices today, because both allow any programming style and are reasonably slow / simple / usable.
I would like it if people like you wouldn't lead astray those who understand even less than you do.
[link]
From: Chris (Jan 10 2014, at 04:05)
Qt QML works for iOS, Android, and others.
[link]
From: g (Jan 10 2014, at 04:52)
Romario, just to elaborate on Noone Special's remark:
You argue that it's perfectly reasonable that Javascript treats [1,5,10] as an array of strings because Javascript is dynamically typed "i.e. values have no types attached to them".
The first problem with this is that that just isn't what "dynamically typed" means.
Here's a short fairly representative list of dynamically typed languages. Common Lisp, Python, Ruby, Smalltalk. In *none* of these languages is it true that "values have no types attached to them".
Unsurprisingly, all of these languages do the right thing if you ask them to sort an array of numbers.
Dynamic typing isn't the same thing as no typing at all. It means, precisely, that types *are* attached to values -- as opposed to being attached to compile-time entities like variables and literal expressions, which is where the types live in a statically typed language.
But let's bypass the terminological issue and pretend you just wrote this: "We all know that in JS values have no types attached to them. So we can't expect it to treat those numbers as integer because the array elements are treated as string by default."
Now, actually even in JS values do have types attached to them -- JS distinguishes quite happily between, for instance, an integer and an array (even if the array contains just that integer and nothing else).
So let's amend your statement again: "We all know that JS treats numbers and number-like strings as equivalent. So we can't expect it to treat those numbers as integer because the array elements are treated as string by default."
At this point we do at last have a basically correct statement. But it's not a defence of JavaScript's behaviour any more.
Treating numbers and number-like strings as equivalent is *itself* a serious design flaw. The fact that JavaScript has that design flaw does indeed explain why it sorts an array of numbers the way it does, but doesn't *justify* its doing so.
It's like saying this: "Yes, my client did kill the deceased with a kitchen knife, but I must explain that he is a vicious killer with no sense of morals." It's an explanation, for sure, but it doesn't make the behaviour any better and shouldn't make anyone more inclined to accept it.
[link]
From: Mike (Jan 10 2014, at 06:09)
As much as Microsoft seems to be out of fashion these days, they got to where they are by providing the best RAD tools available, and have continued to do so, so I have to echo the sentiments of a few posters here that .Net and Visual Studio remain, by far, the best development environments in which I've ever worked. Microsoft may not be popular in mobile right now, and yes, mobile is "all that matters" </sarcasm>, but try to find a business outside of Silicon Valley that doesn't run Microsoft servers or Windows desktops. For many of us who are tasked with writing business software, Microsoft is still king.
[link]
From: Mike R (Jan 10 2014, at 07:25)
I really like the points you make in your article. However, the prevalence of foul language prevent me from sharing it with others. If you want your point to come across with other professionals, clean up your language and be professional.
[link]
From: Josh Brown (Jan 10 2014, at 07:35)
"Unit testing is a bitch." True, but I hate the fact that this is used as an excuse to not unit test at all. In fact, not all unit testing is awful - in the rare cases where mocking is unnecessary (such as when testing a model object), it's not so bad.
It's pretty bad now, but it's getting better...very, very slowly...
[link]
From: Mr. Nash (Jan 10 2014, at 10:28)
TIM BRAY - I WONDER IF YOU KNOW JAVASCRIPT AS WELL AS YOU think YOU DO.
[link]
From: Matt Wyman (Jan 10 2014, at 12:18)
You failed to talk about multi-platform solutions on mobile. Most of them are not very good but personally I've found Unity to do a great job at the problems you posed (UI disparity between devices/platforms and having one codebase between iOS and Android). There is obviously special programming for device specific features, but beyond that Unity tends to run the same on all platforms. When it doesn't do that out of the box, the large set of community plugins tends to have a reasonably priced solution ready to buy.
[link]
From: ben (Jan 10 2014, at 17:53)
Hmm. Spittle-flecked comments. There's a first time for everything.
…And a second thing. I figured I'd tag-team with Simon at some point, and this has become that point.
The technological disadvantage of Web platforms is that they're SUPPOSED to be accessible to everyone; in the interest of keeping the learning curve shallow, those same platforms are designed around compromises that purists find infuriating.
Boo. Effing. Hoo. If you want EVERYBODY to use your product or app or site or technology stack, then you're going to be spending a lot of time in the proverbial orbit of the lowest common denominator. Deal with it. Web developers have.
…And with respect to building stuff three times: horseapples! I'm one of those guys who figures that webapps are fine in lieu of platform-specific ones, a point that the proprietor's employer proves almost-elegantly.
Building iOS and Android apps because you want to charge for the app itself is a bit unimaginative; what you REALLY want is to make income from the content or task automation exposed therein. Make those easy enough to find/use. Make those valuable enough to, well, value. THEN you have options. Apple and Amazon and (again) Google have proven this, too.
…And you'll be able to stick with a single tech stack.
[link]
From: peter keane (Jan 10 2014, at 21:57)
Agreed re: the mess we are in on the client side.
While I have always believed that HTML(5)/CSS offered the ultimate answer, I'm starting think they (not javascript) are the problem itself. I can imagine a new sort of web browser that speaks HTTP (or some hybrid/combination of HTTP and Web Sockets) and deals *only* in JSON data. There'll be some sort of built in component renderer (essentially a GUI toolkit) with all of the various sorts of components necessary. The toolkit will be described in a standard analogous to HTML5 and will include lots of HTML-like components and interfaces to native functionality. Rather than mobile being a smaller version of desktop experience, desktop will simply be a somewhat larger version of the mobile experience. Mobile-first. It kind of saddens me, since my heart is w/ HTML (and REST, everything is a document, etc), but I sure would love an easier way to support all platforms (and we are not even close much less heading in the right direction).
[link]
From: Dave Walker (Jan 11 2014, at 06:39)
Thanks for the "mobile mess" and "mobile sucks" sections - I'll be quoting you in an argument to get some development work funded which should fix this...
[link]
From: kc (Jan 11 2014, at 07:44)
There are things happening on the web front - the biggest changes since dhtml/ajax in the early 2000's. They are:
- es6/es7
- Web Elements/Web Animations/Pointer Events/CSS Grid etc
The question is whether these technologies can give a 'fast and fluid' touch experience comparable to native ios/android/winphone8.
[link]
From: Christian Conrad (Jan 11 2014, at 14:54)
"And I totally fucking hate having four independently-scrollable areas on the screen controlled by weird-looking JavaScript-genius-handcrafted scrollbars."
Could you please, pleeease, mention this to your colleagues on the Google Plus project? Because a few months or so ago -- without any rational reason that I can discern -- they went and f***ed up G+ in precisely that manner.
[link]
From: Brian (Jan 11 2014, at 16:57)
Impedance mis-match is a concept from electrical/electronic engineering that describes why two (sub-)systems may have a power loss between them. As I apply it to software engineering, you have just such a loss when you transition from one framework to another. I also have to add, that any level of abstraction between the bits the computer operates on counts as a layer. As such, it should be no surprise that we need processors that operate at gigahertz speed to do the same things we used to do in C/assembly on megahertz devices in the past. Our layers are frittering away any advantages we should have achieved. Every once in a while we go out and stomp on the stack a few times (move from C++ preprocessor to native code, for instance) but in the end we do the same stupid thing and stack three more layers. Soap, lather, rinse, repeat.
I'm 54, been doing software for 45 years. My first computer occupied an entire floor. My smallest current device is a tablet. I don't do phones. And I'm just as comfortable with bits as with object-oriented, functional, or some of the really weird ones as each and everyone of them is some form of applied maths. Want to fix the problem? Stomp on some layers. Otherwise, putting on my economist hat, live within your means (engineering constraints).
[link]
From: Richard Gordon (Jan 12 2014, at 17:51)
As a long-gray-hair who punched paper tape and never shuffled cards on purpose, now conversant in uncounted web languages and dialects and with decades of sites under my belt, I believe we have, indeed arrived at the salad days where anyone can build a decent 1 page site, in browser, i.e. with universal platform availability, with performance, behaving like a native app or better. There are nuances and challenges. But the cause of greatest project complexity and delay is still the result of fuzzy thinking on the s/w specification front end.
[link]
From: Pumpkin Bug (Jan 12 2014, at 23:38)
Speaking of web standards, what ever happened to the great W3C promise of Scalable Vector Graphics (SVG)? Imagine if we could use SVG seamlessly for non-bitmapped graphics rendering on any device regardless of screen dimension, regardless of browser, regardless of OS, regardless of patents, regardless of egos. Tim Berners-Lee is indeed a Knight in shining armor.
[link]
From: Jason (Jan 13 2014, at 07:23)
@Pumpkin Bug - it was called Flash. It's still rather good at all those things you mentioned, both in browser and natively via Air. The sad part is, it's been rather good at all those things (and a tonne of other stuff) for a very long time now...
[link]
From: Ben (Jan 15 2014, at 09:27)
Can you trust a source who's website errors out in Internet Explorer and doesn't even load? Hyphenator.js breaks the page.
[link]
From: Jeff Lowery (Jan 17 2014, at 15:09)
I've written a few thousand lines of Node-js and JQuery javascript in the last year or so. It's tedious. Saw an Angular presentation recently and I wonder if that's where we're headed.
I've never been a big fan of frameworks, as I've not met one that didn't require a crafty hack to work around one limitation or other, which means breakage, especially when it comes time to update versions.
But... getting the selectors right in JQuery or handling anything massively async is confusing and trial-and-error. You get good at it, but then I was good at SQL, once.
I agree, though, with the Angular premise that you shouldn't have to walk the DOM to display/fetch info. You should just tag elements with the behaviors you want them to have, and feed the data to the behaviors. A bit of Model-View-Presenter in HTML.
But... that said, it's a two-month learning curve, and a frustrating one at that. Most small enterprises (like the little company I'm at) don't have the luxury of training an entire staff for that long.
[link]
From: Kevin H (Jan 20 2014, at 13:49)
$ perl -e 'print join(",", sort((1,10,5))), "\n";'
1,10,5
[link]
From: IowaDave (Jan 22 2014, at 06:47)
As a somewhat ironic twist, this page doesn't load in IE9. There is a Javascript error that states - "Hyphenator.js says: An Error occurred: A security problem occurred." ;-D
[link]
From: David Bethune (Feb 01 2014, at 07:59)
Where is AngularJS in this conversation? It's the anti-framework framework, not only because of its minimalism and "bare metal" HTML feel, but even more so because of the ease with which one can write his own Domain Specific Language. This is no small accomplishment!
In other words, AngularJS makes it possible for you to design your own HTML elements which are really objects backed with JS code. Pretty amazing, once you try it.
-- D
[link]
From: Anis (Feb 04 2014, at 23:25)
Javascript has its negative points, but sort is not one of them since it is more convenient to sort strings by default for most web needs than it is to sort numbers which are sorted as following:
var points = [40,100,1,5,25,10];
//ascending numerical sort
points.sort(function(a,b){return a-b});
//descending numerical sort
points.sort(function(a,b){return b-a});
[link]