How to choose tools
Finding the right terms & avoiding the "hammer first"-principle
Aksel Gresvig/@agresvig - Accenture - JavaZone '14
What this talk is about
- Situation: We make software (decisions)
- Complication: The nature of our industry
- Complication: The nature of humans
- Conclusion: Defining terms & choosing tools is hard
- Message: Use-case always first - then tech reqs.
- Case in point: Web App frontend solutions
I talk about frontend architecture because this is my main domain
But the principles discussed apply to software architecture in general
What's in it for you?
Some hard-earned advice on what to keep in mind when planning new projects
Some up-to-date insight into the frontend architecture options
We make software
Why?
To solve problems
The nature of our industry
..is tiresome.
- Staying up to date demands a lot
- There will *always* be new options around that promise the holy grail.
- FOSS has made the landscape so fertile, yet so vast.
What makes it even harder is that we are human, i.e.:
We're lazy habit makers, who
do what they've done before because we're are comfortable with it
think new stuff is scary stuff
think repetition is easier than innovation
Photo: generalunitedindustries.com
We're flock animals
We do whatever everyone else is doing
AngularJS all over the scene? Must be good lets use it
Photo: Dariusz Paciorek/Getty
We're Impressionable
We believe the hype
Golden kid at last conference always gets attention
Fancy promo-site and API docs gets us (guilty!)
Photo: BRANKOPOPOVICBLOG
So how do we navigate the
TECHNICAL LANDSCAPE
and deal with our own
LIMITATIONS?
We ask the right
QUESTIONS
to find the right
ANSWERS
What really matters is the
Use Case
User
Gain a
THOROUGH
understanding of your applications' problem domain
What should the software you are building do?
Who is the target user?
These are matters that always should take precedence
Gain a
SOLID
understanding of your applications' technical requirements
Example Considerations
- Will we need a lot of user input?
- What are the target user's habits, and consumption devices?
- Content-driven or data-driven?
- Public or Private? - SEO importance
- Requirements and desires regarding speed & responsiveness
Use this info to
TAILOR
the solution to your user's needs and your technical requirements
Case-study:
Webapp frontend solutions
Lets look at webapps! After all, its what the majority of us are building these days
Webapps are used by people, not machines
UX for your use case should be front and center when planning out the solution.
Decisions, decisions
- So much to choose from, something new every year
- Last year - Angular, This year - React, Meteor
- Differing technical approaches to the same problems
so
How to choose?
Lets consider some fundamentally different technical approaches
like
Clientside rendering
(Backbone, Angular, Ember, Knockout)
..vs
server-side rendering
(JSP, Django, Ruby on Rails, Wicket, etc)
Clientside frameworks
Server sends Javascript to client
-> execute on client
-> fetch data, render UI
WHY do this on a consumer device when we have peta-zeta datacenters that can do this for us?
Because partial rendering and UI animations provide a
more responsive experience
Where SPAs win over traditional webapps
Where traditional server-side rendering wins over SPAs
Typical SPA based applications are
Typical server-side based projects are
There is a difference in nature between a
WEB APP
and a
WEB PAGE
Which one are you building?
This should greatly inform choice of framework
The hybrid approach
Is there such a thing as "best of both worlds?"
pjax
pjax = pushState + ajax
pjax loads html from your server into the current page without a full page load
The idea is you can't tell the difference between pjax page loads and normal page loads.
But really it's just ajax and pushState.
On the client
My Site
Go to next page.
$(document).pjax('a', '#pjax-container')On the server
def index
if request.headers['X-PJAX']
render :layout => false
end
end
Why is this cool?
Because its simple. Simple is good
It gives SPA feel with server-side benefits
But..
it doesn't really scale to full-size web app development
Isomorphic Apps
Write once, run twice
The Holy Grail of webapp development?
Advancements in frontend tech. helps make it possible
- Node.JS - JS on the server
- Browserify - use browser JS modules on the server
- Facebooks React - Build reactive UIs in JS
- PouchDB - client <-> server DB syncing (replication)
Put common application logic in
Reusable
JS modules and run them where it makes sense (server or client)
Examples
- Re-use validation rules client and server-side
- Render on the server initially, and from thereon client renders
- Use same models/data-structure
Isomorphic Apps - illustration
UI rendering code sample
// Our component...
var HelloMessage = React.createClass({
render: function() {
return Hello {this.props.name};
}
});
// ...can be rendered to a string on the server...
React.renderComponentToString(HelloMessage({name: "John"}));
// ...then on the client, renderComponent will preserve
// the server-rendered markup & just attach event handlers
React.renderComponent(< HelloMessage name="John" />, mountNode);
Hi my name is Aksel, and I am a
HIPOCRITE
Do you see the irony?
I just vouched for the latest and greatest, yet-to-be tested in production, approach to building webapps.
Exactly this years JavaZone hype