
Picking technologies on the right side of history - DanielRibeiro
http://swombat.com/2011/12/7/picking-technologies
======
AndrewDucker
Surely the right thing to do is to write your systems in such a way that you
can pull out (say) a file-system explorer written in flex and replace it with
one written in JS in as easy a manner as possible.

After all, if you don't provide the good user experience in 2007 (when it
might not have been possible to do so in JS) then you won't be around in 2011
to complain about technology having moved on.

Heck, it might require less effort overall to write it once in Flex, and then
rewrite it in JS four years later than it would have done to write it in JS in
2007 and then keep it up to date with a changing JS landscape over that time.

And you can't ever be sure that you picked the technology on the right side.
So design your systems so that it doesn't matter which side wins, you can
adjust to the new reality and keep going.

~~~
swombat
_Heck, it might require less effort overall to write it once in Flex, and then
rewrite it in JS four years later than it would have done to write it in JS in
2007 and then keep it up to date with a changing JS landscape over that time._

That's definitely one way to do it, but it depends on the technology and the
resource constraints. Ultimately, you have to pick some technologies to rely
on. Sure, in theory you can architect your multi-tier app so that you can swap
out Java for .NET, or Python for Rails, or Postgres for MySQL, or even HTML/JS
for Flex, but those are all difficult and costly swaps to perform. And most
startups can't afford to build expensive components twice. They have to make a
gamble.

Full-Flex front-end was an accepted model in 2007, with a fair few apps
following it. Yes, we could have built just the explorer component in Flex,
but that would have had a number of other problems (such as loading times
every time you changed a tab, for example). More critically, when we started
we had only a vague idea of what this explorer tab might look like. Like many
startups, we were discovering our customers' actual needs as we went along,
and so it wasn't possible to just declare "the explorer component will look
like this and it will be built in Flex", because to be honest, though we
suspected the explorer component would be important, and had some ideas about
what it should look like, those were completely unchecked assumptions.

 _And you can't ever be sure that you picked the technology on the right side.
So design your systems so that it doesn't matter which side wins, you can
adjust to the new reality and keep going._

You can't ever be _sure_ that you _did_ pick the right technology to "stand
the test of time", but sometimes you can be relatively sure that you didn't.
Even in 2007, for anyone with good knowledge of Open Source, it was clear that
eventually, Flex would be losing to open technologies. It wasn't clear how
long that would take, and whether Adobe might counter that by opening up Flex,
but certainly there were strong concerns about Flex (which we were aware of,
but didn't really factor in as strongly as we should have). Similarly, anyone
building a startup that critically relies on Java (or, more controversially,
PHP) today is picking a technology that's waning and will certainly be largely
irrelevant in 1, 3-5 (most likely), or 7 years at most.

~~~
mattmcknight
I think this is missing the architectural problem with Flex- it was more than
just Flash widgets. If it were just Flash widgets- that would be fine, and you
could swap them out. The problem with Flex is that it takes over much more of
the application, handling communication with the server. I always felt that
Macromedia/Adobe were trying to just a little bit too much for you to create
vendor lock-in.

------
mattmcknight
I had a hard time convincing people not to use Flex in 2007 based on my
intuitive sense that it was "wrong". It imposes an event model on programming
that is "against" the way the web works, so the abstraction tends to be leaky.
Someone that understands how the web works tends not to like it, while you
could see web novices appreciating how it simplified the programming model for
certain kinds of data linked controls.

I had very similar intuitively negative feelings about ExtJS last year. It's
not one of those things you can just swap out, you have to write the web
application in a particular way to support it.

~~~
gtCameron
Completely agree about ExtJS. It is quite valuable in that once you learn it
there are a lot of things you can easily throw together that would have been a
lot more difficult with something else, but the learning curve is so high that
its tough getting new developers to the point where they can add to the code
base.

------
jiggy2011
I'm not sure I'm quite on the "flash is dead" bandwagon just yet much as I
would love to see it replaced with something more standard. I agree that it
will decline but it's death will be a slow and agonizing one.

If I was back in 2007 and had to build a rich GUI interface that would work
with IE6 as well as modern browsers I can't really think of any other option
but to either use flash/flex or severely restrict your expectations. As it is
now there is still a fair few things that cannot be done well (webcams etc)
with standard HTML/JS (especially if you are not running a super uptodate
browser).

The problem with these technologies is that feasibility is _really_ in the
hands of a minority of big corporations (MSFT/Apple etc) who are the
gatekeepers and make decisions about the platform, they problem is that they
often work in secret.

Let's face it , the biggest reason behind the "death of flash" is that apple
announced they would not support it on their newer tablet and phone devices.
If this hadn't happened plenty of people would still be merrily writing flex
code for the web.

The problem with the secrecy that these corporations work on their products
with is that developers literally have no idea what will happen, if Apple had
made a friendly warning to web devs saying "hey, trust us you should really
stop using flash if you want to work with our devices" a year before they ipad
came out there would be less people having problems.

Let's say hypothetically that Microsoft suddenly came out next year and
announced that (for example) they were going to trash all support for .NET
across all platforms for windows 8 onwards (including server) and had decided
that everything should be written in python if it wanted to run on their OS,
no exceptions.

Obviously lots of python devs would rejoice with the headstart they had, but
firms that had invested significant time and money intro creating large apps
with big codebases in .NET etc would be completely screwed. Obviously
Microsoft generally don't pull shit like that (quite as much) but Apple would
be more likely to do that kind of massive change and they are gaining market
share..

------
spatten
But you also have to ask the following question: Would it have been more
expensive to write it in Javascript in 2007 (with the same or close-to-the-
same user experience) than to write it in Flex in 2007 and rewrite it in
Javascript now.

My feeling (and I've spent some time thinking about this since we're going
through the same thought-process right now for a project) is that the write it
in 2007 in Flex and translate it now to JS is actually the cheaper option. The
frameworks for large JS projects that we have now just didn't exist in 2007.

This is without including things like comparing the present value vs. future
value of money or the risk that the fancy Javascript code you are spending
tons of time building (which was _much_ faster to build in Flex in 2007) is
going to be useless since no-one actually wants what you are building.

------
zdw
End user technologies are less important than API's, which are less important
than actual data and the formats used to store it on disk.

If you pick something like Markdown (for basic structured text), JSON (for
data structures), or XML (for more complex document-based data), and structure
your data first you're going to be better off than jumping into a front end
design and working out the back end along the way.

------
jroseattle
This is a rock and hard-place for nearly anyone in this position, as I've been
there as well. Most recently, I've seen colleagues have to make choices around
NoSql key-value stores (Mongo, Redis, Cassandra, Riak, etc.)

I agree with AndrewDucker to a certain extent: structuring your application
architecture to allow one to move from one sub-system to another is ideal.
While appropriate in generalities, it's the specifics that matter. Most
substantive environments don't interact with these systems through a simple
connection that can be hot-swapped. There are dependent processes that are
often designed around the fundamentals, quirks and intricacies of a given
technology.

The scope of one's implementation definitely affects how much you can hedge
your bets if you need to shift to another technology stack.

------
techcrucher123
So my question is, is PHP on the right side of history or not?

~~~
aysar
If you have companies like Facebook using it... surely you'd think PHP is on
the right path, no?

~~~
mindstab
That's not really saying anything. Facebook picked PHP in 2004 and is now
stuck with it. They have a huge code base in it.

But there are a lot of indications they are moving away from it in all places
they can. They still use it for front end work, but even there they have been
one of the biggest innovators coming out with the HipHop PHP compiler.

Behind that they also came up with the Thrift RPC framework specifically so
that the rest of their code and logic could be written in many other languages
including Java, Python and Erlang.

Facebook is a lot more than PHP and they've pushed PHP innovation a lot too. I
find their use of PHP as no clear indication PHP is the right or wrong choice.
It's just the choice they made 7 years ago and are living with

~~~
simonw
[http://www.quora.com/Why-hasn-t-Facebook-migrated-away-
from-...](http://www.quora.com/Why-hasn-t-Facebook-migrated-away-from-PHP) has
some insider insight.

------
BlueZeniX
Ever since I've started programming in haXe, it became clear that the language
you code in should never be completely tied to a single platform. This article
hints at Flex dying and tech needing replacement, yet many parts of an
application (lets call it domain model and business logic) should be unique
and not rely on a specific platform or data exchange format.

When you write your data model in a language that works on client and server
platforms, you save lots of duplication of effort and gain flexibility. The
best example of experiencing the opposite I have is a fairly large application
I worked on, where the backend developers designed a totally different set of
classes around a (pretty much undocumented) XML structure than the frontend
guys. Basically all communication happened through XML. Sure "it's an open
format!", "it's human readable! (in a sense)", but taking over this project
figuring out semantics and what was considered valid became a painful effort.

Your frontend should always use the same domain model as the backend.
Designing the fundamental parts of your application without relying on an ORM,
XPath, JSON, .NET, Scala case classes, Flash, Javascript, HTML5, Swing,
whatever... makes you platform agnostic and shrug at the next internet
technology death.

Am I happy Flash is considered dead? No, currently HTML5 lacks many features I
rely on today and sanity (isn't it kind of bizar we consider cross-browser
issues as normal?). Will my skills and all of my codebase die with it?
Absolutely not.

------
gfodor
There is still no Javascript equivalent of Flex (declarative layout, etc), as
far as I know, so I don't know what the author is getting at.

