Like Scott... I've oft had disdain for the web dev' experience.
Started programming in '67, and haven't missed a day since. ArpaNet was exciting, but Berner's-Lee ideas opened up a pandora's box to be land-Netscape-d, and we're still trimming the bushes.
So, I've not been all that anti-MS over the years, but they certainly have a habit of trying one's patience, don't they. The MS approach to the web is no exception: "do it this way. No, wait... that way is bad... try this."
"ActiveX, COM, DCOM, COM+, CLR, .NET, Web-sockets, not yet" it all starts to sound like a Billy Joel song. Isn't it funny how parts of 'Razor' markup resemble classic .asp? Kinda makes you long for the Scott McNealy vision all over again. Man, the transition from AWT to Swing seemed orderly by comparison.
So... way back in the dark ages of 2002 ASP.NET with ViewState seemed like a good idea. Yeah... that was the ticket. We can think like desktop-developers, not worry so much about state-preservation, and concentrate on the LOB app's biz-rules. Nice. Until ViewState became larger than the page, and every thing that a poor user did caused churn and grunts as latency destroyed patience and the number of postbacks caused epileptic fits.
So we used lots of server-side widgets (gotta love those grids) to help. Things got slightly better... but, there was no way that I could not shudder at the thought of the poor users sitting in the office, forced to enter data into a system that was 2-4x slower than it should be. And.. after trimming Session and ViewState, and using more JS to reduce round-trips, we still ended up with users hating the experience, going into epileptic shock from the latency blues. Remember the promise of 'SmartNavigation'? Never worked well, right?
So, we all started to take a hard look at AJAX. Loading data asynch'ly client-side... wicked pissah. Telerik had some fantastic examples and widgets embracing the paradigm. For me, the JS door cracked open a little more; getelementByID and InnerHTML became good friends.
And then John Resig did us all a huge deed. jQuery saved the day. All of a sudden, JS was almost a real language. And... we started to escape from the bondage of the mighty MS 'long and winding' road-map.
OK... I've been typing too long, and I really wanted to talk about my latest KendoUI experiments.
So, have YOU tried to get the KendoUI AutoComplete to do its thing for you? Do YOU have it working with a RESTful JSON remote datasource? Well... I must say, it was more than a bit of pain, and it wasn't exactly a 'restful' project dalliance. but... maan.. it rocks.
Feast your eyes on this and behold the beauty:
$("#patSearch").kendoAutoComplete({
minLength: 2,
placeholder: "(Initials, DOB, MRN)",
suggest: true,
animation: { open:
{ effects: "fadeIn",
duration: 300,
show: true
}
},
dataTextField: "LastName",
dataSource: this.patients,
template:
"<span class='patSearchRow'> ${data.LastName.trim()},${data.FirstName}-${data.DOBString}- MRN:${data.MRN}-${data.ID}</span>",
select: function (e) {
if (e.item !== null) {
var theitem = this.dataItem(e.item.index());
session.setPatientInContext(theitem);
}
}
})
autoComplete = $("#patSearch").data("kendoAutoComplete");
autoComplete.list.width(400);
autoComplete.list.addClass("patSearchRow")
I'm starting to like Kendo, and love it's harmony with (and the ubiquity of) jQuery. It's not just that KendoUI rocks... it's the attitude of the whole JS-library community. There's alot of great people putting tons of effort into JS. And soooo many cool things we can now do for our enslaved users.
It's not exactly easy yet... but we're getting there.
More later... the bees are a-callin'. Time to put more sugar-water on the hive; winter's coming.
Long live ECMAscript !
Monday, September 17, 2012
Wednesday, September 12, 2012
KendoUI's AutoComplete and JSON for the RESTofus
so.. yeah, like Scott... I've oft had disdain for the web dev' experience.
Having worked in just about every stateful environment there is over the years, it was both joyful and painful when ArpaNet was finally blessed and the web became something more than a Berners-Lee rolling paper.
Heck, even 68000asm had better support for real programmers when it was born. So, back in... somewhere around the early daze of Win95.. when the suits realized that color monitors were good, CDs werent the devil and 3.5"diskettes were... we all had to look at how we too could play.
Active Server Pages bit like the .asp they were. Javascript? ok.. that was something that the Netscapers cooked up so we could finally validate some data that we had started to collect... we could now actually build a community by allowing peeps to sign-up themselves... actually typing in their own email to OUR webpage... and we could even store it in a database. Whoopee. Playing with Alert() and window.open was fun. How much time can you spend preventing submarining? oh the joy.
But... run... a REAL biz-app... in a browser? Riiiiighhhht. Point-of-presence sites were fine for me, but sh-t, maan... do you really want to trust your biz-data to an HTML app? CFML was a godsend, and Jeremy Allaire my personal hero. That helped a whole bunch. <CFQUERY> was a big deal.
Roll it forward.
ASP.NET with ViewState seemed like a good idea. Yeah... that was the ticket. We can think like desktop-developers, not worry so much about state-preservation, and concentrate on the LOB app's biz-rules. Nice. Until ViewState became larger than the page, and every thing that a poor user did caused churn and grunts as latency destroyed patience.
So we used lots of server-side widgets (gotta love those grids) to help. Things got slightly better... but, there was no way that I could not shudder at the thought of the poor users sitting in the office forced to enter data into a system that was 2-4x slower than it should be.
Other projects forced a hard look at AJAX. Loading data asynch'ly client-side... wicked pissah. The JS door cracked open a little more; getelementByID became a good friend. InnerHTML was for me.
And then John Resig did us all a huge deed. jQuery saved the day. All of a sudden, JS was almost a real language.
OK... I've been rapping for hours it seems, and I really want to talk about KendoUI. Here we go. Have YOU tried to get the KendoUI AutoComplete to do its thing for you? Do YOU have it working with a RESTful JSON remote datasource? Well... I must say, it was more than a bit of pain, and it wasnt exactly a restful project dalliance. but... maan.. it rocks. Come to the MeetUp... and we'll show ya.
More later... the bees are callin. Time for more sugar water.
Having worked in just about every stateful environment there is over the years, it was both joyful and painful when ArpaNet was finally blessed and the web became something more than a Berners-Lee rolling paper.
Heck, even 68000asm had better support for real programmers when it was born. So, back in... somewhere around the early daze of Win95.. when the suits realized that color monitors were good, CDs werent the devil and 3.5"diskettes were... we all had to look at how we too could play.
Active Server Pages bit like the .asp they were. Javascript? ok.. that was something that the Netscapers cooked up so we could finally validate some data that we had started to collect... we could now actually build a community by allowing peeps to sign-up themselves... actually typing in their own email to OUR webpage... and we could even store it in a database. Whoopee. Playing with Alert() and window.open was fun. How much time can you spend preventing submarining? oh the joy.
But... run... a REAL biz-app... in a browser? Riiiiighhhht. Point-of-presence sites were fine for me, but sh-t, maan... do you really want to trust your biz-data to an HTML app? CFML was a godsend, and Jeremy Allaire my personal hero. That helped a whole bunch. <CFQUERY> was a big deal.
Roll it forward.
ASP.NET with ViewState seemed like a good idea. Yeah... that was the ticket. We can think like desktop-developers, not worry so much about state-preservation, and concentrate on the LOB app's biz-rules. Nice. Until ViewState became larger than the page, and every thing that a poor user did caused churn and grunts as latency destroyed patience.
So we used lots of server-side widgets (gotta love those grids) to help. Things got slightly better... but, there was no way that I could not shudder at the thought of the poor users sitting in the office forced to enter data into a system that was 2-4x slower than it should be.
Other projects forced a hard look at AJAX. Loading data asynch'ly client-side... wicked pissah. The JS door cracked open a little more; getelementByID became a good friend. InnerHTML was for me.
And then John Resig did us all a huge deed. jQuery saved the day. All of a sudden, JS was almost a real language.
OK... I've been rapping for hours it seems, and I really want to talk about KendoUI. Here we go. Have YOU tried to get the KendoUI AutoComplete to do its thing for you? Do YOU have it working with a RESTful JSON remote datasource? Well... I must say, it was more than a bit of pain, and it wasnt exactly a restful project dalliance. but... maan.. it rocks. Come to the MeetUp... and we'll show ya.
More later... the bees are callin. Time for more sugar water.
Friday, August 17, 2012
Confessions of a Desktop developer….
I must confess. I
have not always been a fan of Web development.
I have been a developer for over 12 years and most of that time I have
been developing Desktop applications. I
always found JavaScript to be more painful than useful. I’ve always been a big
fan of WinForms/WPF and C# .NET. I viewed HTML and JavaScript as a limited
technology, not suitable for building LOB (line of business) applications.
At my last company we developed a large WPF application that
was rolled out to over 1,000 users. This application had 14 real-time integration
points and on average we had 500+ concurrent users worldwide. WPF allowed us to make a really stylish UIs and
I fell in love with Data Templates.
Just 4 months ago I received a phone call from a friend. He
explained to me how his company was planning to rewrite one of their core
strategic applications. I thought “awesome!”
After all, what geeky developer doesn’t want
the opportunity to “completely” rewrite an application from the ground up? So, I changed jobs.
At the new job, step1 – choose a technology platform. My
first thought was of Silverlight. It
runs on Windows and Mac (and we could say Linux too). For me, going from WPF to
Silverlight was a no-brainer. But, as we
researched our customers’ needs and talked to them about technologies they are
adapting we kept hearing the same story, “Silverlight is dead or dying,
Microsoft is moving away from it”. My
heart sunk. HTML 5 and JavaScript, do I have to go there? L.
Now, I’m not going to argue the merits of Silverlight versus
HTML 5. You can find those arguments all
over the web. And I’m sure they will go
on for years.
With our need to support multiple platforms (Windows, MAC, and Mobile devices and the current view of
Silverlight’s future, the decision was
made to use HTML5, CSS, and JavaScript for the UI. Yes, my heart sunk.
Well what to do? Being a professional (I cried at home and
did research at work) I started to look at what people had been doing with
JavaScript and frameworks. I was very surprised;
I found a lot of good stuff. JavaScript frameworks
have come a long way and there are a lot of them.
It’s been 4 months now and I’ve learned a lot. In the coming
weeks and months, I plan to post about my experiences good and bad. I still like Silverlight but my perception of
HTML and JavaScript is starting to change.
It’s not that subpar technology that I hated to work with years
ago. It will be interesting to see what
happens to Silverlight in the future but for my current future it’s HTML, CSS
and JavaScript.
Friday, August 10, 2012
Join us for our first MeetUp:
So many technologies, so little time
Are you thinking of migrating an application from the desktop to the web? Are you wondering if you can reuse most of your existing code? Are you not sure what technologies and vendor tools to use? Well you’re not alone. We are in the beginning stages of doing it ourselves. We have a goal to migrate one of our strategic applications from the desktop to the web over the next 2+ years and we want to share our highs and lows (and maybe some anxiety along the way) with you as we travel this journey. Come join us in our technology Therapy sessions.
Choosing technologies and Tools
Are you thinking of migrating an application from the desktop to the web? Are you wondering if you can reuse most of your existing code? Are you not sure what technologies and vendor tools to use? Well you’re not alone. We are in the beginning stages of doing it ourselves. We have a goal to migrate one of our strategic applications from the desktop to the web over the next 2+ years and we want to share our highs and lows (and maybe some anxiety along the way) with you as we travel this journey. Come join us in our technology Therapy sessions.
Our first (therapy) session: “So many technologies, so little time”.
- HTML 5 (what happened to 4, 3, 2, and 1? )
- AJAX (are we cleaning Windows?)
- Compass,CSS (be stylish, modern, have 3.)
- JavaScript/Coffee Script (I can’t start my day without coffee)
- Ruby on Rails, PHP/Python (I hate snakes)
- Java (isn’t that an island in the South Pacific?)
- .NET MVC (Most Valuable Customer?)
- Backbone.js, KnockoutJS (knock out? Are we boxing during this session?)
- ExtJS, YUI, Dojo, KendoUI (is this a martial arts demo?)
- JQuery, Node.js (I’m running out of things to say)
- JSON (are we missing an “a” in Jason name?)
- RESTful (I’m getting tired, can I rest now?)
- Mobile (I have an app for that)
- FLASH (Really? Aren’t we done flexing our Air Muscles?)
- And more
We can’t decide for you but we can share our thoughts on what we decided.
Join us on September 13 @ 6pm as we start our journey to migrate a desktop application to the web. RSVP on MeetUp: http://www.meetup.com/Desktop-to-Web
Desktop to Web
Travel with us as we migrate one of our strategic business
applications from Windows Desktop to the Web. During this journey, we’ve
decided to share our story as it happens. Each week we will post our
experiences (the good and the bad). We will detail both the technologies
we’ve chosen and why we chose them. Our postings will likely range
from what ORM we decide to use, to our struggles with JavaScript OO patterns.
Additionally, like all technology groups, we will probably have some
disagreements and we hope to be able to share them for your benefit.
We’re also looking forward to sharing our triumphs and
challenges face-to-face. Once each quarter we will schedule a
get-together (with food and drinks J
) in the Boston area. During these get-togethers, one of our developers
will present on a topic of their choosing. After the presentation, we
will have a round table discussion to talk about the topic. Our goal is
to share our experience as well as draw on the experiences of other people.
This journey is scheduled to take us about 2 years. In
that time we hope to provide some useful learning experiences as we travel down
this road.
Here are some of the presentations topics we plan to cover:
- Determining what technologies and tools to use
- Design patterns for the web
- RESTFUL services
- Security
- Hosting challenges
- And more….
Subscribe to:
Posts (Atom)