Rants on the daily grind of building software. This has been moved to https://slott56.github.io. Fix your bookmarks.
Moved
Moved. See https://slott56.github.io. All new content goes to the new site. This is a legacy, and will likely be dropped five years after the last post in Jan 2023.
Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts
Thursday, April 20, 2017
Thursday, March 6, 2014
Enterprise JavaScript -- Not the best idea
See this:
The article lists reasons why Enterprise JavaScript is a recipe for disaster. "Finally, there's legacy integration..." This is the point.
In particular, JavaScript needs to get the data from somewhere: a backend process. If we push business knowledge into the front-end, even if we're assiduous about code libraries and sharing, we still have to fight with the "Out-Of-Date JS Library" issue. Server-side business knowledge is inherently consistent and sharable.
The big reason JavaScript feels good is because it's seems productive. Java is complex. C++, C#, and Objective C are Very Complex.
And.
Backend programming doesn't allow you to see finished-looking stuff right away. When you're fooling around with JavaScript you feel like you're doing real work. You're moving data around on the HTML page, that's productivity, right?
A spreadsheet is just as productive as JavaScript presentation. Almost exactly as productive. The underlying data and processing still originates somewhere else. That's where the real value lies. In the data. In the backend.
JavaScript is a swampy foundation for your enterprise codebase: My latest column at SD Times http://t.co/a82aUquk0d
— Larry O'Brien (@lobrien) February 20, 2014
The article lists reasons why Enterprise JavaScript is a recipe for disaster. "Finally, there's legacy integration..." This is the point.
In particular, JavaScript needs to get the data from somewhere: a backend process. If we push business knowledge into the front-end, even if we're assiduous about code libraries and sharing, we still have to fight with the "Out-Of-Date JS Library" issue. Server-side business knowledge is inherently consistent and sharable.
The big reason JavaScript feels good is because it's seems productive. Java is complex. C++, C#, and Objective C are Very Complex.
And.
Backend programming doesn't allow you to see finished-looking stuff right away. When you're fooling around with JavaScript you feel like you're doing real work. You're moving data around on the HTML page, that's productivity, right?
A spreadsheet is just as productive as JavaScript presentation. Almost exactly as productive. The underlying data and processing still originates somewhere else. That's where the real value lies. In the data. In the backend.
Tuesday, July 10, 2012
Cool stuff I saw at MADExpo
A random list of cool things.
I finally laid eyes on an Arduino. Let me simply say that it looks like dangerous, dangerous fun. I think I'll be hanging around at Radio Shack a lot.
- HTML5. Start now. It's supported (more or less) by all browsers if you add appropriate shims. Start with sites like http://www.html5rocks.com/en/ and continue reading. It's largely arrived and there's no compelling reason to delay.
- JavaScript. I'm not a fan of the language. However. It's clearly here to stay. It's part of many important technologies (like CouchDB). HTML5 shims (or shivs) are necessary. Flex (and other browser plug-in languages) are effectively dead. JavaScript is all that's left.
- Redis. Wow! Is that cool? Rather that fart around trying to get outstanding performance out of a clunky old RDBMS, use a simple, high performance data store.
- MongoDB. Now that I've seen it, I have a vague notion of places where Mongo is better and places where Couch might be better. In 80% of the application space, both are fine. But there's a 20% where we might be able to split a hair and leverage the slightly different feature sets.
I finally laid eyes on an Arduino. Let me simply say that it looks like dangerous, dangerous fun. I think I'll be hanging around at Radio Shack a lot.
Subscribe to:
Comments (Atom)