HTML Web App Development Still Has a Ways To Go 279
GMGruman writes "Neil McAllister was helping out a friend whose web developer disappeared. Neil's journey into his friend's website ended up being an archaeological dig through unstable remains, as layers of code in different languages easily broke when touched. Neil realized in that experience that the ever-growing jumble of standards, frameworks, and tools makes web application development harder than it needs to be. Although the Web is all about open standards where anyone can create variations for their specific needs and wants, Neil's experience reminded him that a tightly controlled ecosystem backed by a major vendor does make it easier to define best practices, set development targets, and deliver results with a minimum of chaos. There's something to be said for that."
This just in... (Score:5, Insightful)
Web development is hard for even talented people. (Score:4, Interesting)
Even for excellent software developers, web development is difficult. It's not the concepts that are difficult, per se, but rather the jumble of half-backed hacks that make up ever layer of the web stack. The foundation is so weak that anything built upon it just can't stand well, even if it itself is well-designed (given the constraints of web development).
Just look at the common open source technologies used by many web sites. MySQL is one buggy hack upon another. PHP is much the same, plus some security holes.
HTTP has been over-extended well beyond its original use (cookies are a hack to get around its statelessness, it's caching mechanisms are fucked to high heaven, SSL and TLS are hacks).
JavaScript is perhaps the most horrid hack of them all. Something meant for adding minor interactivity to a page has been misconstrued as being suitable for large-scale application development, although it lacks many of the most basic features necessary to do that sort of development effectively.
It's difficult enough to fight with unclear and conflicting requirements alone. Toss in shitty technology, and it becomes very difficult even for the best seasoned professionals to develop even just mediocre software systems.
Re:Web development is hard for even talented peopl (Score:3, Interesting)
Which features are missing, exactly? Cappuccino [cappuccino.org], for example, implements almost exactly the same APIs and conventions that native Mac/iPhone developers use, only in Javascript.
Re: (Score:2)
Which features are missing, exactly?
How about procedural audio? Say I want to write a speech synthesizer in JavaScript. How do I send the samples to the speaker?
Re:Web development is hard for even talented peopl (Score:5, Funny)
Say I want to write a speech synthesizer in JavaScript.
There is no emoticon for what I am feeling.
Re: (Score:2)
Re: (Score:2)
Other than the horrid startup time, I actually quite liked Java applets for exactly the sort of reason you mention.
Re: (Score:2)
I believe 8^O~~~ (eyes wide, mouth vomiting) is what you were looking for.
Re: (Score:2)
You can use data: URIs to send the generated audio data to the browser's media player. Not exactly pretty, but it is possible. Wrap it in a sane API and it needs to be no more difficult to use than a native audio API.
Re: (Score:2)
You can use data: URIs to send the generated audio data to the browser's media player.
And then you can file bugs in each major web browser's bug tracker asking why your test case of sending a data: URI containing a .wav file to an <audio> element doesn't work.
Re: (Score:2)
Works fine Chrome and Safari via the <audio> tag. It works fine in Firefox through the <embed> tag.
I do not have IE installed to test, but I suspect it does fail. However, who cares? If users really want to use your TTS system, they will install another browser. They are going to have to install a native application to achieve the functionality no matter how you look at it.
JavaScript Audio (Score:3, Informative)
How about procedural audio? Say I want to write a speech synthesizer in JavaScript. How do I send the samples to the speaker?
Well, it depends on if you mean "in the browser" or "in JavaScript." If you mean that latter, I'd probably fire up Mozilla Rhino [mozilla.org] and put together something using the libraries that ship with Java. Some of those are still available in the context of the browser via applets in a lot of cases, too, so with some work, you could probably do it in browser as well.
If you mean in-browser, no
Re: (Score:2)
I'm sure Cappucino is great, and no offense to you, but it seems every time I point out that Javascript is horrible, someone tells me that no, it's not horrible, and all the features that are implemented or emulated by X Y and Z new frameworks, and I go back to Javascript and try those things, it still strikes me as still crufty and horrible. Why did I have to go out and get a framework to implement features that I should already have?
Re: (Score:2)
Javascript is actually a pretty nice language. Browsers, on the other hand, suck. HTML web pages are a terrible place for application development, no question.
You, of course, never need a framework. You can do everything that Cappuccino does yourself. Frameworks are what make development happen, though. No matter what language you develop in, you are going to use a framework of some sort unless you are crazy like RMS and feel the need to write absolutely everything from the ground up.
Re: (Score:2)
Yes, it is a mess, no doubt. But the features are not missing.
Re: (Score:2)
having one's browser running an object-oriented framework and platform abstraction layer in an interpreted language is about as boneheaded as you get.
Sorry. I thought that was how 50% of the web "worked". :)
Re: (Score:2)
in an interpreted language
What, you haven't switched yet from Internet Explorer to a modern web browser?
Javascript has try/catch/throw (Score:3, Insightful)
See it in action here [w3schools.com]. If you're talking about that mess of cluster that is subclassing from Exception, yes it doesn't have that (perhaps Dojo or other js frameworks do?) However, unlike Java and the like, this language at least has closures.
Re: (Score:2)
Even for excellent software developers, web development is difficult. It's not the concepts that are difficult, per se, but rather the jumble of half-backed hacks that make up ever layer of the web stack. The foundation is so weak that anything built upon it just can't stand well, even if it itself is well-designed (given the constraints of web development).
Just look at the common open source technologies used by many web sites. MySQL is one buggy hack upon another. PHP is much the same, plus some security holes.
Uhm, deficiencies of MySQL and PHP don't necessarily mean that web development in general has to suck. What about the Seaside [seaside.st] framework? To me, Seaside is a clear demonstration how much it helps sometimes to step away a bit and rethink an old thing.
Re: (Score:2)
Re: (Score:2)
In my experience, the tools for web application development are overwhelmingly crufty, and a stateless, connectionless protocol is a nuisance.
Then make your application architecture stateful! Use continuations, Luke.
Re:This just in... (Score:5, Insightful)
The problem I find with web developers is that they are too busy chasing the "Ohh shiny" of the month. I've worked off and on with a development group over the years usually as their systems & database guru during the planning stages. This is usually once or twice a year. And each time they are using a different framework "Because it has killer feature xyz". But then they get into it and it seems like it won't do A or B and they end up coding their own.
Meanwhile, at the day job, we had a project that was very close to something I did 12 years ago and wrote in perl5. I dusted off the old scripts, installed, changed the path to perl to the new system and was up and running in less than an hour. I had to update a few lines of code to use new perl modules, but a decade later it still worked. We rewrote the backend to use PostgreSQL instead of flatfiles and updated the template files so the web pages generated don't look like something out of the NS4 days, but maintenance has been a breeze.
Re: (Score:3)
This is a great post and deserves to be modded up. Well-designed, maintainable software is kind of timeless (barring the obvious) and is orthogonal to the technology used.
The corollary to this is too many developers aren't taught how to design software. Instead, they learn about "features" and technology-specific stuff, when in reality the technology is just not that important.
Re: (Score:2)
Re: (Score:2)
One of the hardest aspects of starting a new project is just deciding which languages and tools - with their respective ecosystems - to employ. There is always pressure to jump to the new language du jour that all of the cool kids seem to be using, and as a result everyone spends half their time climbing one learning curve after another. How many developers out there have used 4 or 5 languages in the past two years? More than a few, I'll bet. Each new environment is the panacea for all of the frustrations e
Re: (Score:2)
I find it's the opposite. The vast majority of web developers seem overly eager to avoid extra work, routinely compromising the quality of the end product. This means they wont bother to clean their code, and instead of researching and learning more efficient ways to get something done they'll instead go with some clumsy approach that doesn't work well, but does work. And forget about expecting them to learn something new.
Re:This just in... (Score:5, Insightful)
On the flip side: Being a decent software engineer doesn't make you a good web developer. I've had to deal with a site built by decent software engineers who didn't understand the web and it fell seriously short in SEO, content management, analytics, degradation and a slack handful of other stuff that's second nature to a decent web developer.
Re:This just in... (Score:4, Insightful)
Knowing how to code is easy. Being a decent software engineer isn't. 90+% of web developers fall into the first category.
And 90 % of developers think they are a part of that 10%. And they disagree on who else is in that category.
Dunning-Kruger Effect (Score:2, Informative)
Re:This just in... (Score:5, Insightful)
First, minor nitpick though it may be, HTML isn't coding, it's markup. It shouldn't require a 90th percentile web developer to craft it. All you have to do is understand and follow about 2-5 pages of straightforward rules, and you can create a valid HTML file. It's not hard. People don't do it not because they're dumb, but because they can get away with it.
HTML was designed to be as accessible to new developers as possible. If it had not been, and you could only do web development if you were in the 90th percentile of brilliant developers, it would not have taken off so explosively in the mid-90's.
HTML was originally designed to be loose and forgiving about markup errors. This was both good (HTML was fault tolerant; you could still read a page even if the author didn't mark up everything perfectly) and bad (because now the browser had to do a lot of guessing to infer the intent behind the bad markup and render it somehow, and this made things very prone to error and inconsistent rendering). Ultimately it was recognized to be bad, so W3C tightened up the rules for validating correct HTML syntax, and web developers who cared learned to appreciate the benefits of valid markup. The browser is still forgiving of invalid markup, of course, so bad markup is still tolerated. But unless the web developer recognizes the value of valid markup (consistent rendering as intended), which isn't hard to author, they will tend not to worry about validation, and will continue to think that the web ecosystem still sucks as much as it did in the late 90's when browsers from various vendors were widely inconsistent.
In the early days, the browser wars were not just about who owned the market share, but who could usurp the open standard for HTML and CSS through vendor lockin to unofficial vendor-specific HTML tags. Browser vendors thought they could win the browser wars if they could advance HTML and offer web developers incentives to develop web sites for a specific browser, and thereby steer the market toward using the preferred browser.
As a result, browser developers routinely ignored, broke, or unofficially extended W3C recommendations in ways which made web development a horrible nightmare. When W3C released HTML 4 and CSS 2.1 recommendations, it took nearly 6 years for browser vendors to deliver browsers that actually supported those standard anywhere near decently.
They STILL don't support the standards fully, 100%. W3C has never even finalized the CSS 2.1 recommendation, for that matter.
We've been stuck in a decade of HTML4/XHTML1 + CSS 2.1 stagnation. Only the last 4-5 years have been decent for web developers to fully use clean, compliant HTML4+CSS2.1, and even then only if they elect to break compatibility for outdated browsers and focus on supporting reasonably modern versions of the major browsers that have finally gotten on board with supporting the W3C recommendations.
The downside to this decade of stagnation is that we've been stuck with the limitations of HTML 4 and CSS 2.1 for a long time, long enough for other people to come up with other ideas. Things like tableless layout, fluid layout, rounded corners, transparency, server-provided fonts, multi-column text flow, and so on have frustrated web developers for the last decade. W3C really couldn't do much about it for the first half of that decade because it took browser vendors that long to just get their shit together enough to support the most recent standard. But now, they've been taking way too long to advance to the next level.
HTML 5 and CSS3 are nearly here, and are already partly supported by contemporary mainstream browsers. This is good, but we really need to see a faster adoption, especially in the advancement through the Recommendation process. Unless innovation happens on a regular basis, other players out there are bound to realize that you don't have to serve only HTML over HTTP. Microsoft has something called XAML now, which they use to build rich interfaces for Silve
Re: (Score:2)
So let me see if I can sum this up:
HTML is inadequate as a software platform - it's a markup language, not a proper development language.
It is laden with hacks and "extensions" by individual browsers that are not officially supported and therefore not found in other browsers. Maintaining backwards compatibility creates a very difficult environment to develop web applications in.
The W3C lacks the authority to reliably set standards and best-practices for the industry that a closed-source vendor would have.
P
Re: (Score:2)
Re: (Score:2)
Agreed...
Most of my programs are Web Applications but I wouldn't call myself a Web Developer. I am a software developer first who happens to use HTML for the data output and Javascript to streamline the User Interface. But most of the real work is behind the scenes. Creating database procedures (Yes there is a big debate about stored procedures if you should use them or not, I tend to like them), creating server side programs to gather the information correctly, manage security, and do any additional stu
Re: (Score:2)
As with any programming, proper commenting can clear up misinterpretations and confusion.
I prefer some of the statements made by Fowler in his Refactoring book. To paraphrase, code sometimes has bad smells. There's two ways to fix it. First would be to refactor it into something that doesn't smell, or apply a liberal dose of deodorant known as comments. They don't fix the smells, they just hide them. Generally speaking it's better to rewrite the code into something that's understandable rather than commenting it. (and then later on, the code gets changed and the comments don't, and the w
Re: (Score:2)
On the other hand, cleanly written code can make obvious what the code is doing, but it still sometimes requires good commenting to explain why.
Was this code just never correct? Did the requirements change? Is there a good reason for what it does that may not be apparent to the coder? Will something break downstream if it's changed? (Ideally the answer to that last question will always be no, but the reality lies somewhere else.)
Hmmm? (Score:2, Funny)
What? Can you DOS people now?
Re:Hmmm? (Score:4, Funny)
C Development Still Has a Ways To Go (Score:5, Insightful)
back to perl! (Score:2, Insightful)
The ultimate glue language. It's not pretty as python but it's a woodchipper when it comes to parsing and re-gluing outputs. Indeed that's what the acronym P.E.R.L strands for. My favorite reason to use perl is that you can do more things more easily with the core language. You don't have to depend upon importing libs. The surprise is that it's also not bloated at the core level: compare the thickness of the perl pocket ref to any other language. it's tiny.
Re:back to (UGLY) perl! (Score:2, Insightful)
Perl is for coders, not web designers. As the former, I can pull together and correlate data from all over the place. The only problem is my output is ugly as hell. Since I don't do commercial work viewed by the general public that isn't a problem but it would be nice. Whenever I right click and look at the source for a fairly complicated webpage I get depressed. Seems way, way too complex and you are not seeing everything being brought in via CSS and JS libs.
I keep looking for a way to bridge the gap
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Sure but's been backronymed [wikibooks.org] so many times I tend to think of it as an acronym now. The best part is depending on mood and how coding is
going there are a plethora of acronyms to choose from!
Perl - A high level scripting language common on Unix-like systems, with the common backronym of "Practical Extraction and Report Language", but jokingly referred to as the "Pathologically Eclectic Rubbish Lister". Both expansions appear on the man page. More recently, "Parse Every Random Line", in honor of the extensions proposed for Perl 6. Another less colorful one is "Pathetic Excuse for a Real Language"
from: wordIQ [wordiq.com].
Re: (Score:2)
Practical Extraction and Reporting Language. [linuxjournal.com]
Re: (Score:2)
what exactly is wrong with
for x in xrange(start, end, gap):
that's a for loop with ints. If you thinking of writing a loop of the form for(float x=start; xend; x+=gap) then you really shouldn't. That's how rounding errors accumulate. You can make your own for loop with a generator
def floatloop(start, end, gap):
val = start
iter = 0
while(val end):
yield val
iter+=1
"tightly controlled ecosystem"? Bullshit... (Score:5, Insightful)
The problem with web app development is that the environment was never intended for interactivity, it was designed for displaying information. Everything added since then to create 'apps' has been bolted on (sometimes cleverly, sometimes not so cleverly) and implemented differently between browsers and (relating to plugins/extensions) differently between operating systems. Developing for x86 machines running Windows and/or Linux isn't a "tightly controlled ecosystem" but you can certainly develop excellent applications, why? Because the environment was intended to run applications.
Re: (Score:3, Interesting)
If it was 'never intended for interactivity', why are POST and DELETE part of the spec? They are designed for interactivity.
If you want to get picky, 'computer' were 'never designed' for media playback, using your criteria. (That criteria being that only the initial thought counts, and not the years and years of changes afterwards.)
Re:"tightly controlled ecosystem"? Bullshit... (Score:5, Insightful)
POST and DELETE
You're confusing HTTP with HTML.
If you want to get picky, 'computer' were 'never designed' for media playback, using your criteria
Uhm, you're completely missing the point. Computers don't have to be 'designed' for media playback, media playback is simply an expression of the inherent capabilities available to a computer. A web browser is an application, not an operating system or hardware, that people are trying to force into being an application container. It is not meant for these types of things. People have found ways around these shortcomings; however, they generally tend to be poor, kludgy, and overly complex. This is, again, because HTML, XHTML, and such, are not intended to be used for application development.
Flash is another example of something that was not intended to be used for application development, yet it has grown to accomodate these type of possibilities and since the introduction of Flex, it's far less horrid than previously - but it still isn't a good development environment because of all its legacy baggagejust like web browsers.
Re: (Score:2)
You mean PUT and DELETE, which came in HTTP 1.1 [w3.org], significantly after HTTP 1.0 had defined all the methods as GET, HEAD and POST. [w3.org] These deal with the HTTP's resource model, which only deals with the URL notion of thing, not page-level interactivity which is what I think the OP was talking about.
Still, I do like HTTP 1.1 and one thing I like about REST is that it builds on what appear to me to be fundamental assertions about the HTTP model. You're not fighting the model, you're working with it. Still, I do wo
Re: (Score:2)
And that is exactly why I wanted xhtml2 instead of html5. It has a real framework for web applications between xforms and xml events. It is almost exactly what I would have done for my perfect web application format. The only thing I would add would be the ability to send a model from one page to the next without transmitting the data to the server.
Re: (Score:2)
HTTP != HTML
Dumbass.
Re: (Score:2)
Java was on the right track, but was, perhaps, a little ahead of its time. Instead of rendering HTML, the browser needs to provide a virtual machine environment in which applications can be downloaded over the network, much like how web applications are loaded today, but implemented in languages suitable for development (which can include, but should not be limited to, Javascript).
HTML does not need to go by the wayside, of course. If your goal is to display an HTML document within the browser, you can link
It's just new (Score:3, Interesting)
x86 frameworks have been around for how many decades? HTML5 has been around for how many months?
Web development may seem like a pain, but last I checked, it's the only truly cross platform development environment that has ever existed. If your bank, for instance, had to develop binaries for every platform, you'd never be able to login and move your money around at 2 in the morning.
It's taken time to develop the standards that enable platform agnosticism of more vanilla HTML standards, and it will take time
Re: (Score:2)
I agree that maturity is certainly a major aspect of the problems relating to web application development; however, the primary reason is still the fact that the web browser is built around displaying HTML/XHTML and HTML was not intended to be used for applications. x86 frameworks are specifically designed for the purpose of building application (although I'm sure we could find some that would make us say 'well, maybe not this one...' ;))
"Web development may seem like a pain, but last I checked, it's the
Re: (Score:2)
The whole world, on one inferior runtime simply because it is the same everywhere? No, it did not happen for communism, and will not happen for web development.
Re: (Score:2)
The whole world, on one inferior runtime simply because it is the same everywhere?
Have you not heard of Javascript? Find me a major site that doesn't use it.
Re: (Score:2)
The other point is typography was a (still not completed) after-thought. At the outset html was for replicating the scientific paper and HTML's terseness and simplicity was its strength. Control for layout was given to the client browser and academic papers could be read in Mosaic or in lynx; one need not worry about what the user was using. Tables and images were added later because these are needed for academic writing. Because there is a standard flow of information in the academic paper and because the
The problem is with the serverside code, not html (Score:2)
The problem in his example is with the serverside code not html.
And if you want to, it it simply to choose just a single vendors framework and use only that.
Re:The problem is with the serverside code, not ht (Score:3, Insightful)
Mostly (Score:5, Insightful)
I can agree with all of this except the "backed by a major vendor" part, which seems superfluous... Design is all about maintaining a coherent vision of the end product, whereas hammering a tin shed on the side of the Taj Mahal is always a bad idea, particularly for maintainability and robustness. What isn't clear to me is why I need a vendor to supply my vision when I've already had years of education and experience...
Re: (Score:2)
The glory of your vision may be more widely appreciated when a major vendor can hammer it into the thick skulls of the rest of the world's development community until they come around to appreciate it on their own. :)
(Just sayin'. I mean, otherwise, why would they have even heard of you? Remember that these people aren't necessarily in on the Hot New Stuff in the grassroots developer community, and their employers probably are even worse.)
Re: (Score:2)
Re: (Score:2)
All the management aside (sounds like this server many not suffer from a coding problem; it definitely suffers from a design/management issue though), the "backed up by a major vendor" doesn't even come into it. .net, asp and whatever other techs Microsoft have released as web development languages over the years, I don't think a call to Microsoft would have helped in the slightest.
If you end up with a loose scrabble of
Are we trying to copy GUI apps too early? (Score:2)
"too many frameworks" (Score:2)
Has the 'too many frameworks' argument every held water? 'Too much choice' is not a problem, especially for a seasoned developer.
Re: (Score:2)
Re:"too many frameworks" (Score:4, Interesting)
Off the top of my head, here are a few problems with the mryiad of many frameworks for the web:
1) The super-ultra-awesome slider you want is for YUI but the rest of your site uses jQuery. If you want to use it, you'll have to have the browser pull down both jQuery AND YUI.
2) Many of the frameworks conflict--prototype, for example, doesn't play nicely with a bunch of other frameworks.
3) Each framework added to your stack increases the number of moving parts on your site. More moving parts = more chance for error.
Seriously, it is a cruel joke when you find the-most-perfect-rich-text-editor but it was for MooTools instead of YUI.
*That* is my problem with having so many frameworks. The world would be a better place if we all just used jQuery :-)
Re: (Score:3, Interesting)
It is when the choice is put into the hands of monkeys with darts. That's the problem he's pointing out. Most small companies don't hire seasoned developers unless they specialize in software development. They get whoever they can for cheap, or, at best, they get what their limited experience tells them is the best person. They hire:
1) Kids fresh out of college who know theory but have worked with very little.
2) People with no actual formal computer training who simply "know about computers" and and will
Re: (Score:2)
Bah. Browser crash causes double post. There's an irony to this happening on a thread all about using a stateless protocol to perform stateful functions. :-)
The problem is not the tools... (Score:5, Interesting)
The problem is not the tools (well, not *always* the tools), but the developers. You can provide the best development tools in existence to an incompetent developer, and you will end up with a crap website. It has nothing to do with the quality of the tools or the maturity of the application frameworks.
Hell, humans have been building houses for 1000s of years, yet an incompetent builder can still build a house that will fall apart. I don't think the problem is that the hammer and saw still have a ways to go.
Re: (Score:2)
The problem might have been the client. The second developer might have said, "I'll have to spend X hours to recreate the existing framework and add your new requests."
Client balking at cost, "Could you just add the new features using what's already in existence?"
Developer, leery, "Technically that's possible, but it creates a mish-mosh you'll have problems maintain in the future."
Client, believing the Developer is trying to make more money, "I'd rather just add the new features than rebuild what I already
Re: (Score:2)
Exactly. Badly organized and poorly written code is certainly not exclusive to web development. A truly bad developer can practice his lack of craft in any language, and throw together a poorly designed system for any platform.
Or as your analogy illustrated, while computers allow us to make mistakes more quickly than ever, humanity has been finding new and creative ways to do a crappy job at things for a long time. It's what makes us different from the animals.
His anecdote seems orthogonal to his point... (Score:5, Insightful)
With HTML, whether the shiniest of web 2.0 or the seriously old-school stuff, there is clear separation between the client(where "standards" such as they are, matter) and the server, which can do absolutely whatever it likes, so long as it responds correctly to a few HTTP messages.
If you want to deliver a webapp, the development of your client component is, indeed, somewhat constrained by the fact that "web standards" are more evolved than designed, and are somewhat inconsistently implemented. If you want to discuss the cons of web-apps, horror stories in this vein are the anecdote to use. If you want to discuss the pros, heroic tales of multiplatform, install-free deployment are to be used.
On the server side, though, the vices and virtues of web standards(aside from seriously uncontroversial stuff like TCP/IP and HTTP GET) are basically irrelevant. It's your server. You can do whatever you want to deliver HTML, CSS, and javascript, and interpret responses from your clients. Totally in-house stack? If you feel like it. Modestly customized OSS job? Sure. Some single-vendor enterprise development solution? If that is how you roll. The fact that somebody's web-dev fucked up and then disappeared just seems completely irrelevant(can you think of any type of development, application or otherwise, where "the developer fucked up, then disappeared, and we had to call somebody else in to do a mixture of archeology and pacification" has ever been a good thing?)
Re: (Score:2, Insightful)
Re: (Score:2)
With HTML, whether the shiniest of web 2.0 or the seriously old-school stuff, there is clear separation between the client(where "standards" such as they are, matter) and the server, which can do absolutely whatever it likes, so long as it responds correctly to a few HTTP messages.
We're talking about a hell of a lot more than HTML. HTML is actually the problem, it doesn't do anything we really need it to, so in the browser wars JavaScript was developed. Well, that still doesn't do anything close to what we need, so developers turned to Java, Flash, Ruby, jQuery, ASP, MooTools, YUI, etcetera, etcetera.
HTML is easy. It's also next to useless. All you can do with it is throw up some images and text in a neat layout. Seriously, try using just HTML to build a website - it sucks. Eve
Meh (Score:5, Insightful)
Actually, web development is pretty easy. Just that you got to stay away from the "do it all frameworks" that you want to "customize".
Either build it yourself or use off the shelf, but when you try to combine the two you get a mass.
The tools/languages he mentions all do their own things. And since when are html, xml, json and css a language? Might as well call headers in C a separate language.
Neither is cross-browser all that hard or rather, it doesn't need to be.
As an experienced web-developer I see some very simple problems with web-development:
Really, web development ain't all that hard, but the customers often make it far more expensive then it needs to be.
Re: (Score:2)
Anyone can punch out code
If that was the case coding would be a minimum wage job.
Don't know what he's talking about (Score:3, Funny)
Re: (Score:2)
You forgot that you also need to know xml and apache configuration settings, plus make if you want to make it into an easily deployable package, and etc...
Wanting better tools??... (Score:3, Interesting)
As a webmaster, if found the article strange.
We have better tools today, than years ago. Firefox and his amazing extensions (like Firebug or Webdevelopper) make analizing what is going out here, much easier. JQuery itself make writting javascript predictible (so if it works here, it will work on other browser). There are not lacks of good Code Editors. We use to have good HTML Wysiwig editors, but these are outdated by now (I could be wrong, but the better pad nowdays seems the brain of the designer).
So.. what you need? REDMINE to track proyects? Good debuggers? Inspectors? Documentation?
Working with HTML could be hard (specially if you have to support webpages that have to run on Internet Explorer 6), HTML itself is crap, Javascript is much more evil than people know (but I love it, like a bad girlfiend)... but.. the tools? what tools you need? tools that automagically write code (good code) for you? Visual Studio seems to have some of these, and while I don't use these myself, I have ear good things... (if you are into wysiwig and how bloated any code touched by microsoft looks. ). What you want exactly?
Could be, maybe, that you don't know what tools we the professional webmaster have available? :-)
Commie! (Score:2)
There's also something to be said for a tightly-controlled economy backed by a government with absolute power. Nobody starves, and all that.
Alas, that situation turns out to be unstable in the long run because it can't cope with an ever-changing, inherently uncontrollable world, the "absolute power" thing corrupts absolutely, and various other defects not visible within the tightly-controlled system, even after they are visible to everybody else.
Long run, it appears that the unplanned, unmanageable, chaoti
Smells like corporate propaganda to me (Score:2)
Neil's experience reminded him that a tightly controlled ecosystem backed by a major vendor does make it easier to define best practices, set development targets, and deliver results with a minimum of chaos. There's something to be said for that."
So whatever you do, don't use open standards, open standards screw up everything. Only develop for MSIE, and other "standards" used by major corporations to embrace-extend-extinguish.
And this coming from infoworld? Why do I smell a corporate propaganda thinly veiled as some sort tech commentary?
Web Development (Score:4, Interesting)
There are a couple of problems I see in web development:
1) Unlike the systems programmers, myself included, for a given topic area tools are adopted and standardized.
Web developers seem to get jobs based on the flavor scripting language of the year.
(All of which is crap in my opinion....i.e. php, javascript....python...)
It always seemd too me, that XML, XSLT CSS and Java servlets are really all you need and you can build marvelous interfaces. Tried that once, but the response I got was (thats too hard, lets use javascript).
2) The closest I have come to a decent application framework for building web apps is Java. It has clear security controls, recognizes the importance of Virtual Machine technology to compartmentalize access in a dangerous online world. It even has a very straightforward debugging environment which is quite impressive to track down bugs.
But curiously, it is shunned because if you don't know the scripting language flavor of the day, people don't want to build web sites or won't hire you.
Which is one of the reasons why I don't write web applications anymore. Because when your job and pay is based on how fast you can memorize the scripting flavor of the year, and it doesn't bring anything new to the table (in many ways it can be even worse) to solve the problem of writing a web app, well...it becomes just a money game.
I mean really, I don't mind learning new languages, but I haven't seen anything new since Java 1.6 was released that is any better...just mostly worse.
3) Finally the field has become too greedy. I mean, there is no reason why it has taken this long to standardize video and audio, except for the fact that greed is everywhere.
It is really sort of disgusting, and the crap you have to go through to get video onto a persons browser is just way over the top, mainly due to Adobe and Apple being greedy idiots.
Maybe when the Video and Audio tags get full support for open protocols I will write web apps again. It isn't rocket science, but it is currently a science of idiocy.
-Hack
Re: (Score:2)
It always seemd too me, that XML, XSLT CSS and Java servlets are really all you need and you can build marvelous interfaces. Tried that once, but the response I got was (thats too hard, lets use javascript). ... [other tech] All of which is crap in my opinion ... The closest I have come to a decent application framework for building web apps is Java.
Whereas I read your comment and that of many others in here and see tool bigotry. Maybe my preferred methods are Perl and HTML4 + CSS. Bob has a boner for Ruby and Rails. Both of us think XSLT is a dead methodology, and bicker constantly over whether to do Ajax with jQuery alone or to use YUI. We'll all glue our crap together hope it works. In the end, any product we three produce will suck just like the topic web product.
Even if we settle on a framework and a set of technologies my Java will read lik
Re: (Score:2)
I see a day coming (Score:2)
when so many frameworks are available that if the original developer of a site gets hit by a bus, they'll be no person in the world qualified to maintain it.
Idea for How the Web Should Work (Score:2)
This is how the web should be structured in the future. "Pages" can still be written declaratively, just like our interfaces for desktop software can be designed and stored declaratively. However, they can be compiled into bytecode classes that get sent back and forth in serialized form over "HTTP" (or whatever new, stateful protocol someone comes up with.) The browser will become this: A Virtual Machine and a Layout Engine/Server - The VM will "run" the site as bytecode and directly manipulate the site's l
Wouldn't it be nice... (Score:2)
... to have a scripting language that worked equally well on the browser and on the server and wasn't a complete piece of shit like Javascript? One programming language, one presentation language, one style language.
I'm not trying to discount current solutions here, I'm just saying that there has to be a better way.
In other words... (Score:2)
We keep making the web browser do things it never was and should never have been intended to do. Instead of writing an actual interactive, client-server application, we kludge together something for a browser which then becomes vulnerable to bugs in the browser, the various technologies used to make the page interactive, the back-end services, etc.
We have a hammer, the current WWW stack, and we see all problems as nails, even when said problems are screws and would be better handled with a screwdriver.
Re: (Score:2)
"a ways to go" might be an idiom? Heck, "a ways" might be.
In this case, "ways to go" might be thought of as singular, so "a ways to go" makes sense in a roundabout way.
"He has a ways to go" would mean he needs to grow.
"They have a ways to go" would mean they are far from reaching their goal.
"They had a ways to go yet" would mean the destination is still quite a ways off.
I don't know the proper grammar terminology/explanation for it, but it's correct.
Re: (Score:2)
Re: (Score:2)
Chances are, no, most native English speakers couldn't really explain it, at least not accurately. I'm a native English speaker, and I have a degree in Literature. I didn't really learn grammar in school until I took Latin and Spanish in high school, and more Latin and Japanese in college. I spoke and wrote well before the foreign languages, but largely because I have educated parents and grandparents and just sort of internalized it early on; it wasn't really taught to me. Like in 'My Fair Lady,' oh, w
Re: (Score:2)
Do the English still recognize RP and "the Queen's English" as official, or is that no longer politically correct?
No, they probably aren't. Fowler's [wikipedia.org], probably, would be the usual reference.
I notice another post references the Cambridge Dictionary of American Idioms. So the answer to the original poster's question is: "No don't do it, because you might be mistaken for an American".
Re: (Score:2, Informative)
'A ways to go' actually a colloquialism [wikipedia.org], so I understand your confusion.
Re: (Score:2)
"A ways to go" is an idiom, like "nest egg" or "tongue in cheek".
You have to take the phrase in its entirety, it is not singular or plural, and it means (with some flexibility) "there is a lot left to be done".
It's similar to "a long ways off", and the two are often interchangeable. Both suffer the problem of horrendous grammar that you pointed out, but that's English for you.
In other words, there are a lot of phrases in English where you just toss all the rules right out the window (another idiom there!),
Re:"a ways" to go? From a veteran editor... (Score:4, Informative)
Colloquial/idiomatic.
ways
–noun (used with a singular verb)
way (defs. 7, 14, 20a).
Usage Note: ... In American English ways is often used as an equivalent of way in phrases such as a long ways to go. The usage is acceptable but is usually considered informal.
http://dictionary.reference.com/browse/ways [reference.com]
Re: (Score:2, Informative)
The correct usage is "a way to go".
Re: (Score:2)
Rails certainly streamlines web app development. But what about really asynchronous web app stuff, like comet?
Re: (Score:2)
IE6 failed? (Score:2)
Are you joking? IE6 was such a phenomenal success that industry still can't shake it. You can't possibly justify calling it a failure. By every metric it's a piece of software that succeeded. I'm replying to your message using IE6 - 9 years after it was introduced.
Had it failed, it wouldn't still be holding back the web.
Personally I think this desperate need to shove everything in a browser is a retarded sickness that needs to die.