Web development is just broken
dutherenverseauborddelatable.wordpress.com
dutherenverseauborddelatable.wordpress.com
Also: You need to kill the standards committees that keep coming up with stuff like WSDL and SOAP. Pretty much anything based on XML and you should get out the pitchforks and torches.
Stop hurting yourselves.
I am speaking as an OS guy who also does embedded systems. We have our own pieces of hell to deal with (over-designed and under-implemented protocols in USB and networking, natch; also hardware engineers who like to take away components to save money).
The last time I looked at web development it was a steaming heap of vile, corrupted technologies that barely talked to each other. Maybe alien unicorns have descended and made everything fluffy and nice since I looked last. There /is/ hope. I mean, you deprecated BLINK tags.
Honestly, do the database people and the client people ever talk to each other? Do the people doing browsers ever talk to the people doing IDEs? Or is this like different tribes, and they are trying to screw each other over in some kind of zero-sum game?
Y'all are fooling yourselves if you think there's not a problem. Look at the number of frameworks; these things wouldn't exist unless something needed fixing. Last time I was in the bookstore it seemed like there a dozen linear feet of dead trees describing frameworks. God knows how many there are online.
I think you need an intervention.
As for the claim that the proliferation of frameworks indicates a problem, well I completely disagree. They are so many frameworks because progress is being made improving the technology all the time. This is a good thing; it is how progress is made. By your logic there is a problem with the automotive industry (people keep making new cars), the computer hardware industry (new chips), in fact pretty much every industry that exists today.
It's human (hacker?) nature to think there must be a better way, and do something about it.
But that's really a different conversation.
[ citation needed ]
As to the second claim, SOAP is very popular with Java and .Net developers, especially when they have taken up the latest fad, SOA. There are also entire industries, such as healthcare, that are heavily pushing SOAP-based standards for data exchange.
And when it comes to medical systems, most of the time JSON wouldn't be enough anyway.
But you don't see infinite procedures to make the same car. Web frameworks aren't solving new problems. They are competing with other frameworks which does the exact same thing.
I want to say that we should have some grand unified abstraction for describing web applications but that doesn't represent reality outside of web development. We're still living in a world with multiple OSs (never mind the browser war).
The technology world isn't isn't unified.
if it truly were, would we be able to express solutions to arbitrary problems?
Such a unified solution as you hope for would implicitly prevent the flexibility that allows for technological advancement. Ruby on Rails "golden path" approach is actually a good example of this. Development is easier following the path. Deviate and it gets tricky quickly. But at least it's possible to deviate.
I believe the solution you posit would result in a black box approach to development with only one right way if even one at all. Deviation from the intended use of such a tool would likely be impossible.
"I don’t care about browser wars - my standard toolkit must work on all browsers, end of the story".
ALL browsers is very broad, and "work" is pretty vague. "Behave the same way"? Or just "not cause an error"? You want one codebase to work the same way on links, IE9, Safari and Blackberry? All of those browsers are part of the community on "the web".
"I don’t want no glue - the web is one platform, time to stop forcing us to treat it as a collection of heterogeneous components".
No, the web is a collection of heterogenous components - stop trying to force everyone to treat is as one platform. The portability and interop is what's allowed people to keep migrating bits and pieces around to get something that works best for them. I can change my logic from PHP to Node.js without having to relearn a new markup language for a different browser ecosystem - the CSS, JS and images I used earlier will still work from a new server.
The broad scope of what 'the web' is, and all the various technologies involved and required are what make web development so interesting. "Web developers" is an extremely broad range of people, constantly evolving and churning and growing and changing. If you want "one platform", you're free to focus solely on writing only Rails apps that talk to a Silverlight front-end, for example, or use only a PHP/IIS/Flex stack.
If you focus only on that one stack, some of your issues and concerns will be addressed, and you can become an expert in that one set of technologies. Beware that the larger web world will eventually evolve past you, and much of your skill won't be moveable to the next stage of web evolution.
"Web development", almost by its nature, requires a "jack of all trades, master of none" type of person, who can understand a broad range of problems and solutions, but also needs to call in experts for specific areas when required.
> I can change my logic from PHP to Node.js without having to relearn a new markup language for a different browser ecosystem - the CSS, JS and images I used earlier will still work from a new server. Sure, you won't have to relearn a new markup language and that's clearly good. But, look, your database will still stop working and your client-server I/O will suddenly show a completely different behavior. The current generation of web development requires a modularity that generally doesn't fit the application, and it shows.
But that said, the beauty of things is the interop. By all means, think of something better. I dare you to. I just don't think anything 'better' will retain any degree of cross-platformness, either for developers or end users. We had HyperCard and Director and VB and many other platforms which took care of a lot of things for us, but also locked you down to a relatively tiny audience of people. "The Web" doesn't do that (at least not to the extent earlier platforms did).
Thing is, nothing like this has ever been done before - app access distributed around the world with a massive ecosystem of development tools and services which by and large can work together, even if they weren't designed to work explicitly with each other.
re: "database will stop working". No it won't. I will need to use similar APIs to access it - the database engine itself will keep chugging away just fine. And... my client/server I/O will change? How so? A browser sending in a POST will be accessed in a request.post (or whatever the exact syntax on node is) and $_POST in PHP. So what? Presumably I'm switching because there's some other benefit (concurrency, team skills, etc) that I'd get beyond relearning the specific syntax of general concepts in a new platform.
Again - I wholeheartedly welcome people to envision a new paradigm. I'm old, cynical and skeptical enough to demand that I "see it before I believe it", and given the network effects at play, it'll have to be magnitudes better for all parties involved to catch on.
Embrace the diversity and use it to your advantage.
Fair enough. Let's meet again in a few months/years and compare notes :)
But web-based software is taking over the world; empirically it is not broken, it is very very successful.
And if you want to imagine some magical technology that solves these problems, you are probably falling for the silver bullet fallacy - anything that is advanced enough to solve complex problems (which web software now does) needs to be sufficiently complex to solve those problems. And any abstraction layer is likely to suffer from leaky abstractions (http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...)
That's not to say that improvements can't be made (Rails is one example that aims to make the web development process more coherent and consistent), but fundamentally (and empirically) it works.
As someone mentioned in the comments, we're basically back 20 years in terms of developer experience.
It was horrifying.
First, I had to pick a language. Then a GUI framework. Finding a combination of those that was cross-platform was trivial... As long as the answer was 'Java' and 'Swing'. -sigh-
I really wanted to write it in Ruby, but Shoes was not a good solution (too many features missing... Ones that I desperately needed) and all the other GUIs required special installation, or weren't up-to-date in the Ubuntu repos.
In the end, I chose Mirah. Java, but with some Ruby-ish syntax. That was it's own special torture because it's such a new language that there isn't much out there in the way of documentation or examples. (One time that I complained about that, someone suggested I contribute some. https://github.com/wccrawford/TV-Director is sample that is the answer to that.)
If you can get past the snide comments by "in the know" people who used it in 1998 and didn't like it, Tcl and Tk are actually still a good way of doing cross platform GUI development, depending on what your needs are.
Is it perfect? No. It has improved a lot though, and if you want cross platform, you're probably never going to get "Apple beautiful". You're going to get a jeep, that gets you where you need even if it's not as nice to look at as the Ferrari.
Tk also screwed something up that PHP later copied in a certain sense: it made it really easy for people to do something. Many of those people were not "qualified" to create UI's and thus went on to make some really ugly stuff. Moral of the story: if you create tech that makes things significantly easier, lowering barriers to entry, try and foster a culture that helps create "beautiful" results.
Edit: I initially wrote "GUI framework".
Furthermore, HTML + CSS are a way to create documents that's been hacked together to create so-called apps.
Fixed, thanks.
But it was a neat thought. :)
In fact it is not horrifying, it is nicer than writing web-apps. Pick either Qt with C++/Python, Java or C#/Mono and you're good to go.
I did the exact opposite and was equally as horrified.
Most toolkits (Swing, Fox, Tk, Qt etc.) work around this problem by ignoring it and merely instating their idea of what a GUI should be, or offering the lowest common denominator. So you end up with non-native widgets that don't "feel" right, bad performance (often because you can't take advantage of the platform's native graphics stuff) and all sorts of impedace-mismatches in the integration with things like file dialogs.
The only way to do good cross-platform GUI development is to go full MVC and isolate the non-visual parts from the UI to the point where the UI bits are just controllers and views that interact with a generic backend. This way, the UI is small enough that it's relatively trivial to custom-build a UI for each platform, making sure that each UI gives the optimal user experience for that platform.
It's more work, but it's considerable less work than writing a cross-platform GUI toolkit. With some careful planning, a lot of GUI-technology-independent code may be factored out. For example, a toolbar can be abstracted out in a generic implementation that the native implementation can invoke to make decisions. In a 2D-drawing app, the entire graphical buffer system can be platform-independent. And so on.
I know just one app that is implemented as a cross-platform GUI yet is equally "slick" on all platforms: Spotify. The app is written in C++ and draws its own widgets, but uses native widgets for things like input fields. However, Spotify's UI is very simple, and it camouflages its non-nativeness by using a dark colour scheme with some pretty neutral/browser-like design choices.
For example, Rails + Heroku gives you sensible defaults for your programming language (Ruby), you web server (Heroku), your database (PostgreSQL), your server side web framework (Rails), and your client side web framework (Prototype—perhaps not my favorite, but certainly a default). You can have this all set up from scratch in well under half an hour, your first time through.
If you don't like Rails, you can find similar pre-configured environments elsewhere.
The real web development headache is just how many of these layers you need to understand: SQL, a server-side language, HTML, CSS, JavaScript, and multiple libraries designed to make server-side and client-side coding sane.
According to other comments in this thread, the author has a commercial product designed to address the issues he raises. But if so, he does not seem to realize that he's working on a problem with many existing solutions.
So I take it that you agree with me on the brokenness of web development, even if you consider that setting things up is not all that bad?
You mention the layers themselves as a headache, and I could certainly have added them to my rant - for many, they are a nightmare by themselves.
But let's just assume that we're all seasoned developers and that no language or sum of languages is too scary for us, as long as they interoperate correctly. We still have a nightmare, here, because these languages simply do not cooperate. Just getting them to work together takes considerable amounts of glue.
And please tell me if I missed something, but last time I checked, RoR + Heroku really didn't solve much of the glue nightmare.
Also, if you add additional libraries there is no dependency hell because RVM and Bundler are each a work of art.
That's the _dependency nightmare_ you're mentioning. I agree that RoR solves a non-negligible chunk of it. But I have never seen a "rails new foobar" configure my SELinux or introduce any sane security policy in the database, for instance. So, the nightmare is still here.
The _glue nightmare_ appears when you're trying to pass non-trivial data from the client to the server, or worse, from the server to the client. Or when you're trying to validate the heck out of input data to ensure that there is no CouchDB injection or SQL injection or anything such.
I completely agree that web development is a mess. I just don't think that the first major problem described in your rant (choosing a programming language, web server, database, server-side framework, and client-side framework) is actually a major problem these days: Just pick any modern stack, and use the defaults.
And please tell me if I missed something, but last time I checked, RoR + Heroku really didn't solve much of the glue nightmare.
Rails provides excellent glue between the database and server-side code, at least if you like the sort of APIs provided by ActiveModel. (I do, some people don't.)
Rails provides less glue between the server-side code and the client-side code, at least out of the box. Basically, it pre-configures Prototype, and makes it easy to do basic AJAX stuff via view helpers and unobtrusive JavaScript. If you prefer jQuery, you can switch over in about 30 seconds using jquery-rails.
Rails does not provide a default client-side toolkit for highly interactive JavaScript applications, such as those typically built using Backbone.js or SproutCore.
Actually, the first problem mentioned was not choosing, it was _dependencies_ and then _documentation_.
The second time through, I can probably do it in under 60 seconds.
rails new my_app
cd my_app
git init
git add .
git commit -m "My application"
heroku create
git push heroku master
rails generate model post title:string body:string
# Commit new files.
rake db:migrate
heroku maintenance:on
git push heroku
heroku rake db:migrate
heroku maintenance:off
I've never used Rails or Heroku, so I have a question - how many companies can depend on deploying to Heroku? Is it really flexible enough?
I have only used Python + Django. A few solutions are starting to crop up for Heroku-like easy deployment. But I have some special needs that I don't think will be covered well by these services (for example, I have to do Comet, which means setting up an extra server to do Comet, etc.)
My gut has always told me that Heroku is fine for deploying your application initially, but that most companies will quickly outgrow it and have to resort to manual deployment solutions.
By the way, in my case, I started off with deploying on DreamHost, which is almost brain-dead simple. Then I moved to WebFaction, which gave me more flexibility but I had to do some extra stuff for deployment. Then at some point, when I started making more serious apps, I moved to using VPSs and encountered exactly the nightmare the OP is talking about. I suddenly had to learn how to deploy from scratch, which involved learning to install and configure various programs, and get them working together. It was... not fun.
As long as you don't write to the file system, and you don't need non-web, non-worker, non-cron server processes, you're probably OK on Heroku. You also have to be willing to trust Amazon and Salesforce, which isn't too big a stretch in many industries.
Their WebSocket support is still in beta, and it's not clear whether it supports Comet on non-WebSocket browsers: http://addons.heroku.com/pusher
On the other hand, if you need to respond to ZeroMQ messages, or if you need to poll S3 every 5 seconds, Heroku's just not going to work for you. In that case, you can either toss everything onto a server running Phusion Passenger, or set up a real deployment infrastructure with Chef (or Puppet). This can take up to 2 days for a sufficiently messy project, assuming you want to fully automate everything, and I agree that's it's not fun.
(Edit: Chef provides pre-packaged deployment instructions for Apache, Unicorn, Rails, ha_proxy, a database, etc. This takes a couple of days to work through the tutorials and set everything up. The setup is a bit of a drag, but it's sweet once everything is working.)
It can take much longer for someone who has never built a server at all. Learning to install and configure Apache + mod_wsgi (in the proper modes) etc. is the hard part. Doing it the second time is much easier.
As someone new to both Ruby and Rails, I found the process of installing both + gems and anything else I needed to take most of my first day coding, not to mention if I install on two machines.
I'm no programming guru, but it seems to me that even Rails could be simplified.
[0] https://rvm.beginrescueend.com/ [1] http://gembundler.com/ [2] http://rubyonrails.org/screencasts/rails3/bundler-action-mai...
I read this article[1] and it changed my life.
Also, the "I don't want no glue" line is a lie. Any such framework to coerce Web Development into a single language is all glue, all the time.
Further, he has a marketing problem. Most seasoned developers probably will not flock to a framework that prevents them from writing their own HTML/CSS/JS/SQL, so he'll have to grow his user base on people who haven't been programmers for long.
At the moment, web development is the equivalent of using Linux in the early 90s - you need to enjoy the process of getting it running more than you care about producing results. We're hoping to bring the Apple experience to web app development by providing a consistent set of core libraries, ready made API wrappers, a browser based IDE and one click deployment.
If you would like us to add more Coffee Script related features, please post a suggestion that others could vote on here: http://feedback.akshell.com/forums/108269-general
Communications between different apps is via HTTP requests, although we did have the ability to let you talk directly to another app before.
A very neat feature is the ability to reference trusted third party libraries. Updates and bug fixes to them are immediately available to your app with no work whatsoever on your part.
Currently the service targets fairly advanced developers who are well versed in JavaScript, understand relational databases (yet don't want to write SQL) and know Git, but have better things to do than administer servers.
With time, we are looking to add one click GitHub push/pull/fork+clone integration, web applications & API mashup templates and finally tutorials for getting started with development in JavaScript for the very beginners.
Sure, if you're planning to do something special, you can pick and choose all the bits the author talks about. But if you're doing that, you (hopefully by definition) know what you're doing and are able to make intelligent choices about all of them.
If you just want to build a web app, all you need do is pick one of the big 3 stacks and get going. The Microsoft Stack gives you everything you need with no mandatory decisions on your part. Same with LAMP (read the acronym and you've got your list of pieces). Even Rails has a standardized stack at this point.
If you don't want to bother with the details, you don't need to.
It does? What is it this week?
Joe Beginner will be fine provided he has the tenacity to learn, learn, and continue to learn. What he "deserves" isn't relevant. The reality is we're all Joe Beginner at something. For example, I have been writing code for almost 30 years (started real young) and have been doing web-dev for 10 years, but I'm Joe Beginner dealing with Ruby on Rails, MongoDB, and several other technologies I'm trying to wrap my head around.
Part of...well, actually one of the key aspects of being a programmer is maintaining a complex and diverse skill set. This was true back in the 80's when I started with AppleBasic, it was true in the 90's when we were writing Win32 in C++, it's true now, and it's not going to change.
Call me crazy, but I think using three or four different languages is of the things that makes web development really fun, more fun than trying to wade through pointer pointers to figure out where the hell I forgot to toss memory back on the heap. And isn't that why most of us hack anyway, because it's freaking fun?
To the subject at hand...I think it's a question of motivation. "Easy" was never part of the seduction; I wanted to make games, freak my folks out by making the screen flash and beep when they turned the computer on, hack the computers at school to lock out Walt the dickhead computer teacher guy, etc. "Fun" was always the motivation; "easy" never part of it because easy is...sorta boring.
"Easy" has value, to be certain: IMO it's a signal that it's time to automate that task. For example, I used to hack Apache vhosts files by hand. Now it's easy, and we've automated it (and the rest of the LAMP stack setup, for that matter).
If you want to develop something significant, you'll have to dive deep and spend some time boosting yourself on the learning curve.
Speaking of web development, most good MVC frameworks today solve this problem for you.
Ex: when you use rails, it makes your dev server a command away. It automatically creates an sqlite database by default. If you are building trivial stuff, you do not have to understand SQL and directly deal with the database. All you have to understand is some ruby and a bit of high-school HTML to create simple sites. Whether those bare minimal skills (i.e, minus CSS, minus Javascript) help you build a startup or get profitable is a topic for another day. But it does get you started!
Deploying... whether you use Heroku or any other platform or your own rock solid VPS, is upto you.
The blog post, IMO, sounds like the rant of a tired programmer.
If you want a web-site made easy use Wordpress or something else that provides what is needed for basic scenarios out of the box. If you are expecting standard interfaces for web-servers, programming languages and web standards that are not going to change regularly as software development matures as a profession you are insane.
Just take an example of something that is already relatively standard like SQL, now write some SQL for MSSQL and then switch to Oracle...
Lets face it beginners should not be building non-trivial web applications where things like scaling matter. At least not on their own, and if they do they should expect it to be a challenge and a difficult learning process they will need to dedicate themselves to. .NET tried this, they wanted to make web development as easy as drag-and-drop. In the end .NET ended up with two things:
1. A ton of absolutely crap legacy spaghetti code in corporate web applications
2. An group of developers who never really learned how to write code or understand the first thing about real web development.
However I'm not convinced that it's really a good thing for separation of concerns. You made a comparison with GUI development, but actually it's not uncommon to use a separate language to specify layouts when creating GUIs (Qt, Android...) The reason for that is that the declarative style of markup languages can often be a better fit than describing layouts programmatically. As for databases, it's great to have a (more or less) standard interface to query relational database that can easily be used from virtually any programming languages and from the command line. A lot of web apps are not limited to interact with a db and the filesystem but also need to interact with legacy systems. Less technical people might also want to be able to use off-the-shelf graphical tools to query the database. That might be a reason why ZODB, a Python-specific data store, hasn't been tremendously successful, despite meeting your requirements (notwithstanding scalability perhaps).
//Overly simplified example $.get('tooltips.php?id=tooltip-id',function(data){$('#tt').text(data);});
I think comments regarding ponies would be superfluous...
I mean, it's not as if things are the way they are just to make your life miserable. It's a matter of the incentives involved. And anyway, if you want to 'just get started', PHP is pretty good at that. You can have your hello world page up on the internet in a few minutes.
Originally, Web was intended as a collection of resources -- actually, a filesystem of sorts. But it grew out of proportions as it became popular since it allowed users to see color and pictures and animations on the Internet, which was up to that point either limited to plain text, or required some heavy-weight, non-standard applications to be installed on the client. Actually, the name used for the application used to access the Web -- a browser -- tells a lot about how it was intended to use: to "browse" the resources, not to execute them. Could you imagine what desktop development would look like if you were limited to using just some sort of file viewer to program for it?
Each Web application is, actually, two completely unrelated Web applications. One is executed on the host and is preparing the data for the Web server to serve; but there is another, which is running in each of the users' browsers, only connected to the former one by asymmetric pairs of requests and responses. Even if it consists only of HTML (and CSS), it still has code being interpreted and evaluated on the client; ajax apps only emphasize this.
So it's not Web development that is broken; in fact, it is a miracle how what was created by the developers to work around the fundamental limitations of the platform, which was never meant to be one.
Maybe my next rant will be called "Web development was never built in the first place" :)
* elastic compute - easier - no need to worry about hardware * REST - easier - no need to worry about WSDL and XML * HTML5, CSS3 - agreed powerful standards to create create UIs * jQuery - much easier than hand-rolling * JSON - easier and lighterweight than XML * decent modern browsers - improved standards adherence, so easier and quicker to write for multiple browsers * NoSQL databases - easier to work with (no ORMs), quicker to set-up (no schema) than relational dbs
Of course, if your web app is advanced, Rails may or may not be a good fit. But it'd OK that it's hard to write advanced apps.
But I'm happy to have the choice to use python, and play with different client side javascript libraries to suit my various needs (I do use app engine). And maybe next week I'll use clojure on the server side next week and coffee script on the client; that's the beauty of choice.
Overall if there were a single SDK for web development ala IOS development of android development, I would enjoy it less. I'll take the rough edges along with the additional choices and flexibility.
Building software is hard.
Modern Property development is broken. First I need to have a registered architect design a building, then I need to purchase the land, then get government approval, then deal with contractors and bank financing. I just want to choose a spot in a city and then start building my dream building. This is 2011 and this is the best we can do?
</sarcastic example>
The further away you move from low level control for abstractness (read: easy) you give up just that. Control. One of the requirements for this abstractness is everyone has their 'own' ideas of what 'easy' is, thus you always end up seeing framework N1,N2,N3... and so on.
If you take a look at Rails, there is much argument about "well I don't like Ruby, much prefer lang xyz", or "I don't like the magic, I like abc" (just giving an example). This exists for everything out there today, because we are all different.
It feels like everyone expects to just load up an IDE and start coding, but this will probably never be the case again. The Internet has brought us the ability to not only fork code but fork ideas. Having to rely on a main branch of well water (read: visual studio, xcode) leaves you powerless (see my main point about giving up control) in the end, (eventually as iterations increase).
Perhaps when something is not in physical form, the concept easily escapes us. There are many ways to 'hammer a nail', or 'code hello world'. The basic principal remains the same, blunt force 'could' be applied or you could just use a screw, or... (you see my point).
It is again probably the Internet which has increased the iteration of improvement, and obviously people do find it confusing to have to 'shop' amongst hundreds of options. If you look at it, it's no different than what we do at a grocery or hardware store today.
So, maybe it is really one's lack of understanding with the fundamental problem at hand (that your trying to solve). Knowing that, you could choose the right tool, level of abstraction, faults, etc... for the job at hand.
But one of my points is that we definitely haven't reached this level of maturity on the web.
World is complex. Technologies are. Deal with it.
Another thing that seriously bugs me is the approach to mask completely different goals and processes by imaginary simplicity of overlaying technology stack. Writing a web app and making it scale are totally different goals, choose what are you going to do first. Textual documents storage will differ from video hosting by a couple of orders of magnitude. The more generalization you achieve, the less freedom you'll have.
I'm sure that you know this, but in case anyone out there less well informed takes that at face value I felt compelled to add to it!
A "full stack" like using ASP.NET MVC,EF and IIS will get you to a dirt simple app pretty quickly but it still feels like too much for what you are actually producing.
"It must be obvious... that there is a contradiction in wanting to be perfectly secure in a universe whose very nature is momentariness and fluidity."
OS: Linux programming language: Ruby web server: Apache + Passenger database management system: Mysql server-side web framework: Ruby on Rails - includes ORM client-side web framework: jquery + backbone.js deployment: capistrano
and adjust those settings when it doesn't work for you.
worked for all my projects, and I did some really non-trivial CRUD applications.
To start with php, or ruby on rails or python django and learn some html/css to target billions of devices worldwide.
Anyways, back it the old days it used to be a 2 man show, usually an artist and a developer and they would knock out a game. As the industry matured and the technology involved became more complex specialization occurred. The same thing is now taking place in the web and we are seeing the technology start to converge around the idea of specialization.
SOA and REST has compartmentalized the server side into addressable business resources for performing business computation and access to data. Used correctly a business developers can provide information and processing to the internet without having to touch a single line of HTML or JavaScript. They can write services in pure Java, C#, Python or whatever. This allows a Java developers the ability to provide deep specialization in Java and provide the products of the specialization to other developers in the work flow without encumbering that Java developers with ancillary technologies.
Further many app servers externalize the management of environmental resources such as file access, which becomes the domain of an infrastructure admin. Server administration and configuration can now be performed by technical personnel that specialize in infrastructure related concerns rather than developmental concerns. This is a good thing because it allows more capacity from developers by freeing them up to develop.
Finally, the client side frameworks have finally liberated the UI from the Hodge-podge of technology soup that we created in ASP, PHP, JSP, whateverP. This in my opinion is where the web went wrong. We created the idea of the documents that just souped all of the technologies together and everyone from all distinct roles had to work in this mix. While it was great for the one man show developer the whateverP where always trading of ease of use for the developer for ease of use for the designer or vice-verse. One only needs to look at the contrast between PHP and JSP to see the two distinct philosophies at work.
So as the web has matured you are now seeing more delineated roles than the old web developer or web master or web guy. Now you see delineations like, SOA/REST developers, Content Manager, SEO Developer, Web Designer, UI Developer.
There are companies like Wavemaker that are trying to make it easy for the one man show developers to write modern web application and I believe that products such as it will grow in popularity as the solo developers looks for tools to keep up, but the reality is that the web has matured and with maturity comes complexity. Complexity that is more and more managed by groups of specialist as opposed to the generalist.
We took a document fetching/presentation system and beat on it until we had an application platform, and we're feeling the pain. We have built workarounds on top of workarounds to try to make applications look better, work better, and better to develop, but we're still stuck with the browser and its limitations. Reading some of the posts here, it seems like some people have developed Stockholm syndrome for the browser.
What we have turned the web into is a resurrection of mainframe computing. Our terminals are just a little bit better this time. It was the only vector for exceptional ease for the user so we flocked there, the trouble is, talking to the terminals makes up have to do a lot of less than ideal things on the serverside. Sure we may have prettied up some parts and made more and more tech for talking to the terminals, but its not great. We and bitched and moaned about the state of the terminals and over the last decade they've even became a smidge better.
If you want simple, shorten this list of requirements.
Current-generation frameworks just don't provide that much help at any of these levels.