

A new development era - nashequilibrium
http://blog.ziade.org/2013/01/25/a-new-development-era-essay/

======
ghc
> In fact, I think Python is becoming the secret weapon behind every good
> Javascript application ;)

My recent experience says this is not true. Python is so widely used as a
backend that it is in no kind of secret weapon - at least not in the way Lisp
was a secret weapon for Paul Graham with Viaweb. _Every_ startup I've dealt
with recently is building their backend in Python, Ruby or Node. I think the
real story here is that compiled languages are on a major downswing in use for
startups that build web apps. I haven't run across a startup building their
backend with .NET or Java in a couple of years, except for one payment
application that built the business logic with C# and MS SQL Server (they
still built their web API with RoR).

Recently I tried to go back to compiled languages for a new web project. I
really wanted to try something fun in Haskell that wasn't just data processing
(what I normally use it for). I picked up Snap, Yesod and a few other
libraries only to find that it was just too much of a pain.

Dynamic languages remove so many little annoyances with web development that
it's hard to justify going back to a compiled one when you could just cheaply
spin up an extra VM or two to deal with the performance differential between
dynamic and compiled languages.

Maybe I'll try Go next...

~~~
dysoco
Well you have Go, D and Haskell: And Scala, Clojure, Erlang if you count VM
languages.

~~~
Ygg2
Erlang has a VM version?! I thought it had it's own VM.

~~~
dysoco
I said "VM languages", not "JVM Languages" :P

------
girvo
That which was old, is new again. I find the cyclic nature to be interesting,
and possibly a response to the increasing nature of computer power.

Originally, the mainframe was where the power was. Then the PC was enough to
do a lot of the work the mainframe was doing. Then the nature of delivering
experiences to those around the world necessitated a shift back to the server
for a lot of tasks (try running Google or Facebook locally), with a shift to
making the Gui thin... Performance in the browser was woeful.

Now, the performance of the browser across our increasing amount of disparate
devices is nearly adequate enough for thick guis once more, with the bonus of
it working across a multitude of OSes (Windows, Linux, Mac, iOS, Android,
Windows Phone, Chrome OS, etc.)

It truly is interesting to watch and play in :)

~~~
PommeDeTerre
This is more a case of "old is still old", I think. We've been hearing about
how web apps or browser-based apps will replace desktop apps for many years
now, yet it never happens.

I can still remember all of the Java applet, ActiveX control and DHTML hype of
the late 1990s. It died out when it was proven to be nonsense. Desktop apps
continued to thrive.

Then it built up again a few years later, during the middle of the last
decade, when AJAX and jQuery became all the rage. These offerings were
marginally better than what we saw in the DHTML era, but still lacking. The
only traction they gained was at the very low end. Most serious users still
preferred to use real desktop applications.

Now it's a few years later, and there's been a lot of HTML5 hype. Yet the
browser-based apps are still no closer to replacing desktop apps. Gmail, for
instance, has been around for almost a decade, but a great many people much
prefer a real mail client. We also haven't seen much traction when it comes to
modern online office suites, and other web-based alternatives to more
traditional desktop apps.

Native desktop or mobile apps are going to be around for a long time. I
question whether it is even possible for any browser-based app to compete. In
order to do so effectively, it would be necessary to eliminate the browser
itself, as it is the browser and its related technologies which provide the
poor experience we get from many web apps. It just looks like a complete no-
win situation for web apps, aside from perhaps at the very low end.

~~~
graue
This is all anecdotes unless someone's done a survey, but in my experience
_very_ few people use a native app for email anymore. I do so, but can't think
of a single other person I know who does. Almost everyone's on Gmail, and a
lot of people only do IM (Gchat, Facebook Chat) in the browser, too. And there
was never a native desktop app for Facebook, but that didn't prevent it from
getting a billion users. Likewise, where's the native app for YouTube? We all
used to download videos and then watch them in native video players. Not
anymore.

Maybe it's a matter of age — I suspect you might be a little older than me and
the crowd I hang out with (mostly mid-20s). From my vantage point web apps
have obviously already replaced many categories of native apps, and are on the
way to replace more. It seems as if you are denying something that already
happened.

~~~
Encosia
I think a lot of people who have only been exposed to web based email don't
realize what they're missing in a good native client. I have several friends
in that mid/late-20s age range that went to work in corporate jobs, used
Outlook 2010 for the first time, and then asked me for help getting their
personal Gmail/Yahoo/Hotmail accounts working with Outlook because they like
doing email there so much more once they learn to use it well.

edit: BTW, I see your comment was downvoted while I was writing mine. I just
wanted to say that I did not downvote yours; you make good points about
Facebook and YouTube, to be sure.

~~~
purplelobster
Outlooks is so much worse than gmail in almost every way. The only good thing
about it for work is integration with all the other MS applications. My
experience with Outlook after many years of gmail has been nothing but
frustrating, and I hear the same story everywhere.

~~~
Encosia
I'm genuinely curious what you mean by "almost every way".

I use the Gmail web interface daily because its keyboard shortcuts for
labeling, archiving, and deleting are unbeatable for triaging my inbox, but it
pales in comparison to Outlook 2007, 2010, and 2013 for composing and
scheduling (and I schedule against an Apps for Business account, not
Exchange). In particular, pinning search folders like "Unread Mail" to the
"favorites" area is invaluable to me because I filter a lot of my mail with
"skip inbox" and "keep unread" so lower priority mail doesn't clutter my inbox
or distract me with push alerts, but I want easy access to it later. I've
tried using g + l "unread" in the Gmail web interface to replace that, many
times, but the experience is just so much worse that I don't find it usable at
all.

------
calpaterson
It's funny, this architecture he mentions of one-page-app clients on the
frontend and microframework servers on the backend with Python is precisely
the model I choose for a recent side project.

What I learned: \- Javascript requires a lot of architecture to be sustainable
over even medium size apps (I stole N. Zaka's architecture)

\- Writing functional tests for Javascript is difficult. (Writing unit tests
is easy)

\- Most web browsers are nearly there with everything you need for one-page-
apps. IE8 is the only real problem, and I think my problems are soluble.

\- Python's single threaded nature requires that you make explicit effort to
add offline jobs (I added a priority queue using redis)

\- Elasticsearch is actually quite complicated once your needs move out of the
completely trivial

\- Most of the documentation for Elasticsearch assumes a working knowledge of
Lucene (which I don't have).

\- Mongodb is really really easy to develop against

\- Getting a single page app to be sensibly indexed by Google is not easy.

Here's the backend source:

\- <https://github.com/calpaterson/recall>

And the frontend source:

<https://github.com/calpaterson/web-recall>

And the current deployed version is here:

<https://recall.calpaterson.com/about/>

I'd love to answer any questions, I'm not as keen on one-page-apps now as I
was when I started.

~~~
jseims
Do you have a link that elaborates on N. Zaka's architecture?

~~~
politician
I've also successfully implemented Zakas' [1] approach after watching his
presentation "Scalable Javascript Application Architecture" [2] and abandoning
Backbone.Aura [3]. Aura theoretically implements this, but in practice we
found that it made some assumptions that were incompatible with our needs.
Consequently, we rolled our own implementation.

[1] <http://www.nczonline.net/blog/about/>

[2] <http://www.youtube.com/watch?v=vXjVFPosQHw>

[3] <https://github.com/aurajs/aura>

~~~
swah
Very interesting mateiral. I used backbone.js a while ago but missed Aura.

Do you know if that architecture is compatible with Angularjs' philosophy?

------
onemorepassword
Although there is definitely a shift going on, I suspect it won't be half as
radical as people like the author tend to evangelize. This model may be a big
shift for a simple web app, but for larger applications with lots of business
logic it will barely make a difference.

The "big web app full of things" will still be there, only with a few things
less, and it will still be built with tons of tools, not just a micro
framework.

The future of web development won't be that different. There will just be more
of it, but that's pretty much what has been happening since the 90's.

There's enough exiting new stuff happening without going overboard and
announcing it as a new era or a major paradigm shift. Maybe I'm getting old,
but I find it tiresome.

------
elicox
The people live in a bubble, they don't considerer that there is others kind
of software that required more (so much more) business logic, that only an
insane man can try to solve with js.

~~~
steverb
The problems that can be solved using js grow large with each passing year
though. I wrote a video recording and exporting app for a client this year
using web technolgies (html + js + node). I couldn't have imagined that being
possible 10 years ago.

~~~
rjbond3rd
Very cool. So did your app somehow manage to do video capture on the client
hardware, or did you access something equivalent to a webcam?

~~~
steverb
In this case, it captures and streams from the computer it is running on via a
video capture card. The application is for archiving audio and video from an
external box that it monitors.

The nice thing about doing it that way, is that adding the capability to
stream real-time from the external box that is being monitored is as easy as
opening the ports to external access.

------
ecopoesis
MVC isn't just a good idea for making development easier, it's also the
natural resting state for most applications. In the future, well just be
distributing the models, views and controllers across multiple machines and
networks, just as was done on the past.

------
snambi
Still Server will render the main page. Main page is " html + main content
that user and search engine wants to see". Because the search engines need to
index this page ( meaning the URL ), so the main content must be same, unless
it is a private page. Also the browsers are designed to render html from the
server. HTML5 brings in a lot of dynamic features, but the main feature is not
going away.

------
DasIch
Interestingly enough we still prefer to use a Twitter client instead of
twitter.com, in fact those clients are what made Twitter big or at least so a
lot of people claim.

Why would that be any different for other things? Why should that change in
the foreseeable future?

~~~
girvo
Actually, we might, but everyone else didn't. IIRC something like 90% of
traffic on Twitter was directly on the site, not through a client.

~~~
tl
I would argue that Twitter is bad example. I prefer the Twitter site over the
apps. Reeder vs. Google Reader is a different story.

------
rsl7
wait... this guy thinks the future is going to be simpler? when has that ever
happened?

However, I largely agree on the right side of the big vertical network line in
his diagram, and I feel this has been obvious for years now. The left side,
not so much. I think the reduction of web services to JSON type data will
enable an explosion of client side diversity, and that is a good thing.

Also there is nothing classic about "server-side" MVC : it is ridiculous and
never made any sense.

~~~
nonamegiven
"wait... this guy thinks the future is going to be simpler? when has that ever
happened?"

It happens constantly. It's such a strong urge that making things simpler
itself has become simpler.

I'm touching simpler right now. This linux distro (lubuntu, doesn't matter)
took me much less than an hour to download and install, fully functional with
no configuration by me. In fact it was fully functional before I installed it,
because it was a live distro that connected to the internet with no
configuration on my part.

15 years ago that would have required me to download a bunch of separate
files, copy them to a stack of floppy disks, and keep a book by Matt Walsh
open on my knees while I tried to figure out again how to make my computer
talk to my modem and to the wider internet.

I'll completely reinstall my OS on a whim, with confidence. I used to approach
it with dread and a good night's sleep.

I also don't adjust the choke on my car when I start it, and I have no idea
how to safely crank the engine from the front of the car; actually, I can't
find the place to put the crank handle in, and I can't find the crank.

EDIT: s/router/modem/

~~~
chipsy
That's easier, not simpler. When part of the stack breaks you're even less
likely to know how to fix it than 15 years ago.

<http://www.infoq.com/presentations/Simple-Made-Easy>

~~~
nonamegiven
The procedure that I use is simple, regardless of the underlying complexity
that makes it simple.

Eating is simple, even though the body is complex. I'm glad I don't have to
explicitly operate my pancreas.

