81–90 of 147 posts
7. Progressive Enhancement. It should be mentioned more, the current trend of tech is leaving it behind, for no good reason... There should at least be a debate on it... but it seems it's in the "Too hard" basket right now.
This is against the grain, but it is obvious to me that the way forward for web development is to rise above Javascript and simple DOM mangling, which is what most of these popular tools assist with. Javascript does not scale complexity and manipulating DOM elements directly is both error-prone and a lousy programming paradigm. We need something in between that offers a sane development model and deals with the compl…
Ragarding your edit: A startup called famo.us( http://famo.us ) is focusing on exactly this (canvas based UIs) however I'm not completely sold that this is the future. It's an awful lot of wheel reinventing. They're doing it in the name of solving performance for HTML5 apps and for creating apps with rich UIs which would be more similar to interfaces we see today in games rather than traditional DOM based UIs. Howeve…
This is against the grain, but it is obvious to me that the way forward for web development is to rise above Javascript and simple DOM mangling, which is what most of these popular tools assist with. Javascript does not scale complexity and manipulating DOM elements directly is both error-prone and a lousy programming paradigm. We need something in between that offers a sane development model and deals with the compl…
Having worked with GWT for some time, it's a subpar model. Perhaps it's a flawed execution of the concept, but it has extremely long compilation times, the development mode crawls (so developing with it is slow)--at least for a sizable project. Furthermore, it's not as easy to use external JS libraries (you have to create wrappers) and, worst of all, there just is not a vibrant community around it. For example, it's inexcusable for a 2012-era framework to not have a quality form validation library available.
The other downside of GWT is that it's written in verbose Java, with plenty of non-DRY stuff. GWT compiler provides code generation for some things and the Maven plugin has code generation for others. In my opinion, when a framework, that advertises ease of client/server integration, asks you to create TWO same-but-slightly-different interfaces per one service to make remote calls, and does so with a straight face in the documentation, then you know that the authors are missing the point. (Oh and you have to define the new service in three places in two different files.) The point is that brevity of code and DRY are very important. When the authors don't champion this, there is little hope for the whole thing.
GWT was a good idea when it was created, but it failed to evolve in the face of jQuery's competition.
All you need is abstract away enough pain and complexity until things become manageable and it's easier to get the job done. This is what jQuery did by abstracting away browser differences. This is what other frameworks, such as Backbone.js, are doing at the next level.
Moreover, it depends what kind of web development you want to do.
If you want to work as part of a team in a top shop, then sure, know frameworks and write perfectly linted code. However, if you're a freelancer who survives by making small commercial sites, then you're working with people who don't care about a third of a second difference in load times. Or, they'll care way more that you get a button hover-animation to look slick than they will about downloading jQuery uncompressed. And if you're a freelancer/outside-party, you're not going to be able to insist on their IT to use your deploy processes anyway, so minifying/jammiting in a productive way may not even be an option.
Pretty good list. Some comments here mention this is obvious or dated, but I think that in the wild a lot of devs aren't doing these things. I think there are still a lot of back-end devs which this very much applies to. If you are a back-end dev who has been able to get away with not knowing CSS (and possibly even JS) well, then you need to fix that deficiency. For example, I typically work with a team of developers…
I've wondered about client-side MVC. What level of UI complexity justifies it's use?
I have never used these for client work. My concern was that a client might insist on using these despite your preferences. So, as a freelancer you should be familiar with them because they can have a bit of a learning curve.
I'm always amazed to see how people who give advice (and good ones in this case) are totally unable to follow them on their websites. 296 http requests. 1.85mb transfered. Yslow grade D. So yeah, these are good advices. In fact, the OP should follow 'em if he wants to "survive".
he says at the bottom "And a disclaimer – don’t look at the source code of my web page – I rarely work on that, and is using an old blogger template. lol"
Pretty good list. Some comments here mention this is obvious or dated, but I think that in the wild a lot of devs aren't doing these things. I think there are still a lot of back-end devs which this very much applies to. If you are a back-end dev who has been able to get away with not knowing CSS (and possibly even JS) well, then you need to fix that deficiency. For example, I typically work with a team of developers…
Nice list of skills that web developers should have. But the general advice "Learn Your Craft Well" has nothing to do with changing times. (The times are always changing, aren't they?) On the content: Anoop seems to work more on the Backend side of the web and as software architect. It is not uncommon that people who are specialized on backend are not familiar with current frontend standards. So his advice might be a…
I'm always amazed to see how people who give advice (and good ones in this case) are totally unable to follow them on their websites. 296 http requests. 1.85mb transfered. Yslow grade D. So yeah, these are good advices. In fact, the OP should follow 'em if he wants to "survive".
I knew I wasnt missing out on much when an article about advice for the future of web development failed to load correctly on my phone.
As others have pointed out, it's hard to take this post seriously because of how poorly the site is implemented...but beyond that, the advice seems either painfully obvious or outright counterproductive. Moreover, it depends what kind of web development you want to do. If you want to work as part of a team in a top shop, then sure, know frameworks and write perfectly linted code. However, if you're a freelancer who s…
But the points I put forward is mostly what I practice these days, and the basis is the consulting experience I had from revamping the websites/web products across multiple domains for the customers I've worked for.