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 complexity and anachronism of the underlying platform. GWT cross-compilation is an excellent example. It has enabled the painless development of complex Javascript-based web UIs[1], with the tool support of any other software development project. This is what I'm going to look to for the future of web application development, not patchy solutions to the complete mess that is barebones Javascript development.
EDIT: By the way, it is only a matter of time until we have complete canvas-based UI libraries, frameworks and tools suites akin to Flex (probably from Adobe, too). When that happens the web will really have arrived as a rich client platform. I would be very surprised if there isn't a few projects in this space nearing completion at this point, since the underlying technology is basically ready.
There is no future in GWT. Even Google is running away from it and is working on Dart now.
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.
>> but it has extremely long compilation times, the development mode crawls
When you go to create the deployment package it's slow. When doing development, which is most of the time, it's fast to me. I can change things in the client or server code, save and see the results instantly.
>> 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
That is a huge, major win dude. Seriously. What else would we all program the web in? JavaScript? The language that has to be excused for all the weird things it does when you thought your code would do something different?
>> ...Java, with plenty of non-DRY stuff.
DRY is a principle, you can repeat yourself or not in any language you choose.
I'd quote more and respond to more but most of your arguments are clearly in favor of JavaScript programming, it makes no sense to compare a Java to JavaScript technology to a simple JavaScript library (jQuery) because with jQuery I still have to program in the weird unpredictable, odd behavioral world of JavaScript.
While I think GWT is a pretty good project and has some way to go before it can be categorized as failing, some of your other remarks make me think that you have not given appropriate consideration to the alternatives to its approach.
First and foremost, you can write javascript in such a way that your code does nothing weird and only what you intended. A good place to start is still "JavaScript: The Good Parts"[1]. Then I suggest finding some examples of nicely written javascript code on GitHub or some such site. I personally think underscore.js[2] and backbone.js[3] are rather nice.
If you have really given javascript a fair shot, and still strongly dislike it, there are many other languages that compile into javascript, but match its style more closely that Java does. I have been enjoying working in CoffeScript[4]. There is an excellent interactive book[5] that shows the javascript generated by the constructs in the language, which is also a good resource for discovering idioms to do things that are not obvious in javascript, like creating classes. TypeScript[6] and Dart[7] are both interesting languages with syntax more familiar to Java. There are a lot more languages that compile to javascript that I haven't mentioned[8].
It's possible that GWT and Java are the best fit for you, but don't pigeonhole yourself by thinking that they are the only good options out there.
It's not that the project is about to fail, it's that even with that I still don't see a future. The project is mostly driven by the now-disinterested Google and a bunch of large companies with huge and different GWT-based frameworks (SmartGWT, Vaadin, Sencha GXT). The latter players only have an interest in keeping the core of GWT alive, not in advancing the regular GWT experience. Other players are small and on the whole don't seem to be contributing in promising ways (in my opinion). For example, the GWT-P framework, despite some good ideas, is quite verbose and provides false time savings.
>> I can change things in the client or server code, save and see the results instantly.
I work on a medium-sized code base (compared to some enterprise code I used to work on in the past). I am using 1-yr-old top-of-the-line MBP with best-available SSD and let's just say we disagree on the definition of the term instantly. I experience anywhere from 15 to 30 second waits on refreshes (that trigger recompilation), plus server restarts if server-side hot code deploy fails. That's far from instant.
>>>> it's inexcusable for a 2012-era framework to not have a quality form validation library available.
Have you written forms that had to be validated? GWT CellTables that had to have contents be validated?
There is another GWT validation library out there that helps with forms/tying into GWT controls, but it's quite lackluster.
>>>> The other downside of GWT is that it's written in verbose Java
>> That is a huge, major win dude. Seriously. What else would we all program the web in? JavaScript?
Java is verbose and you have to recognize that downside. I will often pay those costs of verbosity on the server-side in exchange for performance. Someone else here gave a good alternative perspective, but yeah, JavaScript.
>>>> ...Java, with plenty of non-DRY stuff.
>> DRY is a principle, you can repeat yourself or not in any language you choose.
The problem with GWT, and this applies to the non-DRY comment, is that they did not aggressively go after eliminating that. They just said, "it's Java, things are just going to have to be verbose." C'mon, you wrote a Java-to-Javascript compiler for Pete's sake, surely you can put some talent into making the core development experience better! Especially in the face of competition like jQuery or Rails.
Creating two files per page/view sucks (or 3 files with GWT-P, be warned), or coding up your views w/o UI binder, you end up coding the layout of the page in pure Java (verbose and far from directly relatable to the layout). I already mentioned the pain of doing GWT RPC calls in my previous comment. I could go on all day.
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. However, I don't think there's a need for that, and ditching all HTML standards in order to reimplement them in the canvas sounds like a step backward for me.
I need it specifically for games, building an interface on a canvas without even layout managers or mouse click aware components feels like the stone age, so I am in the market for a wheel actually. Though it does seem like a bit of a waste as the other poster also said.
That works fine to an extent, but sometimes you want your menus integrated with your game and have consistent graphics and animations and so on. I used dom elements for snaketron, but in hindsight I think it felt tacky (it might partly have been because I used Bootstrap). For most games, which are more complicated, I can imagine it would be a pain to maintain dom menus.
FYI, famo.us is not Canvas, it's DOM. IMHO, since AJAX and div-hell designs became commonplace, we've been needing to have a long overdue discussion about the right role of semantics in HTML. There definitely is a place, the <article> for example was a step in the right direction because it indirectly acknowledges that an html document is not really any longer a document, but in many cases is simply a collection of documents. Take Twitter for example. Each tweet is a document, but is twitter itself a document? no, it's an app. We still need standards and semantics and all the goodness of the DOM, but we need it for things on the web that are in fact still documents and not some chimera.
At famo.us, we're focusing on turning the top level DOM elements into something compatible with the app approach that is capable of being made performant. However, we're not going to throw the baby out with the bathwater. DOM and the original ideas behind HTML are still valuable. It's just time to reassess the role of apps and how to make it so they can live in the same space as documents (i.e. the browser viewport), especially when they are ephemeral apps, because the "install" is dead. It's been usurped by the almighty hyperlink.
the promise of the web is "build once , run everywhere" , not "read the source code, ripoff that work". Nobody cares how it is done. the web is a plateform , the only things that matters is that the software runs on that plateform, without the need of going native.
The DOM is indeed too low-level. We need higher-level components, and the ability to develop custom components. We also need a way to firewall segments of a page, so we can reason about it at a higher level of abstraction. This technology is coming, it's called shadow dom ( http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/ ).
I've been developing a 100.000 line single page javascript app for the past few years. You can't build an app like that if you code at the level of dom elements. Encapsulation and abstraction is essential. Because the shadow dom didn't exist i used extjs as a crude alternative (extjs's component framework is really nice, but the dom structure it produces is ugly). However, with shadow dom I can imagine a way of writing javascript in the large without needing the heavy abstraction layer that extjs provides.
Have you tried using the Dojo/Dijit Framework at all? I have been using it for medium to large sized web applications recently. I break pages and components into dijit widgets and everything becomes separated very nicely. It has a similar declarative markup to the link you posted.
I feel you, but so far I haven't seen any such solution that isn't full of leaky abstractions. As far as I've come to understand, GWT is no exception.
What's the point of a high level powerful tool if you need to understand the underlying technologies and the transformations to it well in order to use it?
>> What's the point of a high level powerful tool if you need to understand the underlying technologies and the transformations to it well in order to use it?
Building UI libraries on top of canvas feels like reinventing the weel, HTML/SVG/CSS already provide you advanced APIs for accessability, text layout, theming and drawing. All you really need is a tiny abstraction layer.
But here's the thing: CSS is a stone soup of non-local, action-at-distance effects -- it's "goto" programming. HTML lacks decent layout primitives (border layout, grid layout) because it's a document-oriented abstraction. It's just really obnoxious to get a single screen application look working correctly on all browsers.
So, I'd welcome a reimplementation of, say, WPF on canvas. Something that works without Microsoft's, Google's, and Mozilla's explicit blessing really is needed.
CSS is not that hard. Many developers simply put off doing it at any cost, then throw together a messy unorganized stylesheet and blame the language.
I'll agree with you on the layout shortcomings, such as using excessive floats etc. But once flexbox is fully implemented as a standard, this will become much easier.
It is not hard, it is just not fit for laying out UI because it is was not developed with this purpose in mind. CSS3/flexbox is an afterthought attempt to fix that.
I think there's quite a wide gulf between "direct DOM manipulation" and "use GWT". I've been using Backbone's views to make my JS more manageable, for example, and there are some nice MVVM frameworks out there that really help you build complex JS applications without it turning into spaghetti.
"Dart and GWT both share the goal of enabling structured web programming. In fact, many of the same engineers who brought you GWT are working on Dart. We view Dart as an ambitious evolution of GWT's mission to make web apps better for end users, and we're optimistic about its potential. As Dart evolves and becomes ready for prime time, we anticipate working closely with the GWT developer community to explore Dart."
"Meanwhile, rest assured that GWT will continue to be a productive and reliable way to build the most ambitious web apps—and even games like Angry Birds. Key projects within Google rely on GWT every day, and we plan to continue improving (and open-sourcing) GWT based on their real-world needs."
I personally don't care what it's called, or even the language, as long as it builds on the strong foundation that has been laid with GWT.
Ok thanks, so Google wants us to use their browser, their OS (Chromebook) their systems language Go, their web language Dart, I'm not sure where this is headed. An old expression about putting all ones eggs in one basket comes to mind.
Google is no longer leading GWT. it is run by a committee of companies that have deep vested interest in the toolkit. Google is still on this committee, but they no longer have the same number of resources working on it.
"Changing times"? What exactly is he talking about? Many of the things he mentioned have been pretty standard, even among the least-knowledgeable web developers, for years now.
jQuery has had pretty significant traction for 4 or so years now.
Crockford's work is extremely well-know, as well, and has been for some time now.
Minifying JavaScript and CSS files isn't new, nor are REST and HTML5.
The times did change, but it looks like he's still just catching up with where the rest of us were years ago.
> jQuery has had pretty significant traction for 4 or so years now.
One could probably assume you already know it. Right? =)
> Minifying JavaScript and CSS files isn't new, nor are REST and HTML5.
Being new and being widely practiced are two different things. Also, REST is something people still struggle with today, because they assumed they knew it because it's deceptively easy. And HTML5? Really? It takes just 10 seconds to scroll through the thread here and see how just because HTML5 is more than 6 months old doesn't mean everyone sees it as ready.
> but it looks like he's still just catching up with where the rest of us were years ago
The rest of who specifically? Not HN'ers, that's for sure. Not web developers. Who, specifically?
I'm going based on the hundreds of web developers I've interviewed over the past few years. These include people with no formal training, through to people with a decade or more of experience.
While I don't specifically ask for experience with jQuery in job postings, there have only been a small handful of those candidates who have never used it. But even they have often just focused on using YUI, MooTools, Dojo, or some other similar framework instead. The "changing times" the article author talks about happened years ago when it comes to these frameworks.
The same goes for HTML5, minifying, REST, and basically everything else he listed. These concepts are common knowledge these days, and basically everyone in the field that I've deal with has been aware of them, and in most cases has actively used them.
I really don't know what to say to you, if you actually are a web developer and you found many of those concepts to be new. A lot of what the article author lists are pretty well-established and widely-used. "Changing times" doesn't really apply at all well after the change has happened.
The author explicitly called out .NET developers (" and I see a lot of web developers still lagging behind especially in the .NET world.") So do I.
A trip to my local .net user group last month had presenter going over ASP.NET MVC v4 and some of the reactions and comments were... hard to believe. I'm not saying all .NET devs are behind the times, but there seems to be a disproportionate amount of them, based on my own anecdotal info from attendance at various conferences and user groups over the last couple years.
We get sucked in to the bubble of HN, and the majority of people we interact with on various boards/forums/etc are indeed aware of these technologies, but they do not (yet?) represent the majority of developers.
Agreed. The problem always seems more pronounced when it comes .Net.
In my own observation, it seems to be a culture/mindset that gets adopted, and I have to say, I feel it's largely driven by Microsoft.
This whole idea of developing everything yourself, not paying as much attention to subtleties in UI and so on. If you notice most .Net blogs, they're mostly behind the times when it comes to this stuff.
It's like when Ruby on Rails came out, there seemed to be this notion that because something was developed in Ruby, that was the reason why it was "pretty", yet it just happened a culture driven by 37Signals and so the result was that a large portion of Ruby work was decent looking.
In the same vain, I feel Microsoft has set a particular culture in motion when it comes .Net.
Disclaimer: I realise these are generalisations and i may have a skewed view, but these have been my observations for the last several years.
The number of devs I hear complaining about "but but but... I want my webforms!" when confronted with "use a client-side JS tool with REST/AJAX/etc" is staggering. How do they think the rest of the world works?
Adopting these 'new fangled' approaches will increase their ability to move between worlds - perhaps even leaving the .NET compound from time to time. And perhaps more importantly, it will make it easier for people already skilled in front-end JS to contribute more effectively on otherwise-.NET-only teams.
You will almost never find top-notch JS talent (freelance or full-time) who also know how to interop with webforms and older ASP.NET tech. Widen the pool, by changing your practices, and you'll be able to compete more effectively.
agree wholeheartedly about HTML5. Its a broad API with lots of loose parts, and frankly its not ready in the sense that I can take the specs, program an app in HTML5 and be confident that its gonna work. I'm pretty confident in saying no browser supports HTML5 100% - though I'd be happy if someone could prove me wrong :)
And it won't be ready, ever. It is like building the skyscraper on the swamp without proper foundation, or trying to convert your truck to a race car.
HTML was born and evolved around hyperlinked content. Using it for apps was an afterthought and it shows and there is no escape from that. You cannot start from scratch and you cannot keep pilling on without breaking the thing.
That's why I don't subscribe to the optimism of those claiming that HTML will soon win everything.
Really, just try to implement anything moderately complex in web technologies, and then the same thing using any of the native sdk's and compare the level of pain.
Which is most developers. Maybe you work with exceptionally well-informed and talented people but 90% of the web devs I know don't know squat about responsive and MVC frameworks, REST or how to optimize JS. And by "don't know" I mean they have never even heard of the concept, not just that they haven't had the time to learn about it. Sometimes I get funny looks for mentioning even jQuery or modernizr.
Maybe our experience is different because of where we live. I'm Hungarian and most people here speak poor English (due to various reasons - the education system is not exactly stellar and also Hungarian is very, very different from any other European language except Finnish). So few programmers I know read blogs or news sites about programming.
A couple of reactions: You guys seem to hate each other a lot, and love javascript frameworks. Me, I've tried to snipe at my fellows a lot less on sites like this, which has improved my online experience, and I prefer to learn standards over frameworks.
The kind of discussion going on here is reminiscent of old timey C vs. java vs. perl, or maybe vi vs. emacs slashdot discussions from the late 90s: pointless. Focus on the code, not the tool, it will make you a better engineer.
For the comments about the web not being ready for HTML5 yet because it is too young: nonsense. Every phone supports HTML5, and every Apple computer. Every time someone goes to google, they are suggested an HTML5 browser. My non-tech friends are mainly on Chrome and Firefox on their Windows machines, and only my older relatives who want to mash a button to get pictures of their grandkids are using IE... of course, your mileage may vary.
As for the comments about humility being the same as getting overlooked in a competitive world, I disagree. Focus on the code, not on developing a cult of personality. If your work stands out, and you can solve problems other people can't, you need to beat your chest a lot less.
What aspect of HTML5 isn't yet ready for mainstream? JS polyfills make almost all of it possible for the ~4% of global IE7 users (according to the site above... no idea how accurate it is). Just using modernizer, json2.js, and underscore enables about 90% of the HTML5 feature set for IE7. Raphael, excanvas (or whatever) and accepting the lack of drop-shadows/rounded corners in shitty browsers make up the rest.
Seriously. 99.9% of the time it's possible to develop in "HTML5" and drop in a few conditional comments that load extra libraries for IE 7.
maybe it depends on how you view the specs, but I think what most people mean by HTML5 is the full spectrum of new features outside markup that enable app building, ie. filesystem API, Websockets, web workers, webgl, etc, which is to no where near getting a 90% coverage even by using tons of shims/libs. just browse this site to see how far along HTML5 is: http://caniuse.com/
Yeah, fair enough, it's a moving target. Two years ago when people said HTML5 wasn't ready for prime time they were talking about audio and video tags, canvas, SVG, CSS media queries, and websockets (which, by the way, are pretty usable with a shim like socket.io or sockJS). Now those things are all more or less feasible across browsers with some (or a lot) of JS (localStorage and the app cache can also be used as long as they're not relied on, which is a reasonable long term strategy for most web apps anyway) but web workers and webgl have picked up steam since then. If we keep moving the HTML5 goalpost (I've given up on paying attention to the spec), it will never be ready for production use.
I guess I'm only saying this because the HTML5 brand has created enormous confusion in the marketplace. That's largely because it was touted as "the replacement for Flash" and my point is that it is already quite capable of doing that in most cases.
Same here. This site and Steve Yegge's site fail to load in the stock cyanogen browser. Also they fail with Opera Mini. They do work with the Firefox Android browser at least.
I had my disclaimer, lol. As I already clarified some where else, these points are what I learned from what I was doing in the last few years, consulting for my customers modernizing their web sites/apps. And thanks for the advice, in fact I'm surviving pretty well ;)
Mind you, I know builders who still have unfinished jobs around their house. Car mechanics whose own vehicle could use work. Electricians etc...
I think valid advice is still valid, regardless of whether they practice what they preach. I also know how little time I have to work on my own sites with various project work I've got on...
This is like writing some crappy code, then adding a comment for the next coder that will work on that (when you probably have already moved on) that you didn't had time to make anything better. It changes absolutely nothing.
JS MVC frameworks: MVC in JS is almost always overkill.
HTML5: Most of the web doesn't have support for it yet.
Optimization: Sure, but don't preoptimize so rather go looking for the tools once your app tells you it's slow. Also minified JS is great to save a tiny bit of bandwidth and obfuscate, but damn it's a pain to debug your live site.
> "JS MVC frameworks: MVC in JS is almost always overkill."
This depends entirely on what you're making. JS frameworks like AngularJS really ease the pain of building rich, interactive web apps.
> "HTML5: Most of the web doesn't have support for it yet."
HTML5 is a moving target, modules are now versioned separately so there is no true/false for support. The fact is you can use a lot of the really useful changes so far in the most used modern browsers and there's polyfills/shivs to help IE9 and below. Now that we're all moving to auto-updating browsers we should see a much faster rollout of new features than we have in the past.
> "Optimization: go looking for the tools once your app tells you it's slow"
If you can solve a problem before it happens then you should do it, it should be part of your deployment process. If you're just making simple sites then apps like CodeKit can take care of everything for you.
> "damn it's a pain to debug your live site."
So don't try to debug a live site, that's silly!
I disagree. The last thing you want is JS spaghetti, no matter how small or simple your pages may be. Full MVC frameworks like, say, Backbone, are usually overkill, but I haven't seen many web pages with JS that couldn't use MVC patterns in some capacity.
> JS MVC frameworks: MVC in JS is almost always overkill.
Unless your bread and butter is modern web apps (ie. json driven sites with websockets/long polling) which, at least in my neck of the woods, seem to be rapidly becoming the norm.
Without backbone.js it would not be possible for me to do any of my current client's projects on the timelines I'm doing them, simple as that.
That said, learning every client-side mvc is probably a mistake too. Just research them and learn the one that you feel is best.
You can scale development teams and put re-usable patterns in place without pushing all your templates and view logic to the client. That's what libraries like Backbone are made to do, and I would agree it is generally overkill to implement a site that way.
> "HTML5: Most of the web doesn't have support for it yet."
Say what? You probably meant to say "most of the internet explorer installed base doesn't have support for it" which is a far, far cry from "most of the web".
Yeah, but IE is huge. It really is, and I wouldn't have believed it before I started working on a large site in Europe (approx 900K uniques per day). At least a third of our visitors are using IE, sometimes even IE8 or 7 (we've finally gotten rid of 6).
I often wonder who these people are, and then I talk to my boss, who uses IE8 and complains constantly that we all use Chrome (on Windows, FF for the win on a decent machine/machine running Linux). So yeah, unfortunately, if you're doing ecommerce for ordinary people, you're stuck with supporting IE and the whole host of issues that entails. Seriously, 100char limit? WTF Microsoft, fix that already.
No, what he said was correct. Even my beloved chrome does not have 100% compliance. Now combine the incomplete implementations, coupled with the rate of browser adoption, HTML5 simply isn't ubiquitous for a number of years. So you will be looking at polyfills and excanvas scripts for the foreseeable future.
What he could have said was 100% of the web does not have 100% support for HTML5.
And when "HTML5" (whatever that means anymore) finally is ubiquitous it'll be the old tired standard and everyone will be dying for the day they can finally use all that hot new stuff in the next version.
Thus is the nature of any technology whose design is controlled largely by a committee of companies who are each other's top competitors.
Is CoffeeScript a higher abstraction level from JavaScript? Whenever I've taken a casual look at coffeescript I came away with the impression it was just syntax sugar.
It is. For one thing, classes (or objects you 'new') are much cleaner in CS than any trivial implementation in vanilla JS. Splats, loops, string interpolation and comprehensions are like added bonus (they are technically syntactic sugar, but make thing so much easier, cleaner and more readable that it's worth using CS for these features alone). True, CS makes debugging a bit harder (though SourceMaps might make that a thing of the past), but as CS code is much cleaner and easier to read, stupid typos are less likely to happen and most of the time, bugs are logical not because you accidentally didn't put a semicolon there, or used ; instead of ,
In my experience (I wrote substantial amount of CS code during last year) overhead for CS debugging is so small it is not even worth mentioning.
In theory it looks much more serious than appears in practice.
Does anyone have any recommendations for good REST books? For example, the book cited in the article - is it good?
I understand the basics of REST, but I want to get a deeper understanding. Also, I still regularly encounter situations where I'm not sure what the "best" thing to do is (collections of items, linked items, etc. - how to represent this with REST?).
I took a look at Steve Klabnik's a few days ago. Honestly, I couldn't get into it - I'm not sure why, but I felt it was disorganized. I felt there was no way to really jump in from the beginning, get a good ground-level understanding, and then progress to more advanced topics. It felt more like a collection of articles targeting people with various backgrounds and levels.
Maybe I'll be back to it after I've read another resource - it's quite possible Steve's is simply for someone who understands more about these concepts than I do.
I've been working through it. It's pretty interesting, although it's definitely arranged around the "Cookbook" concept - specific questions and answers. I feel it's missing a "let's show an example REST api - here's the resources, here's how you do things, here's why we built it this way and not another".
Of course I'm still on the 3rd chapter, so it might be heading in that direction. An interesting book in any case.
Let's say I have a "Student" resource and a "Course" resource. And there's a many-to-many link between Students and Courses. How do I connect them? How do I get a list of the Courses the Student is enrolled in? How do I add to this list? Let's say I want to see a "latest courses" list in my homepage, some of which I'm enrolled in - how do I know which ones? This I solved, for example, by adding a paramater "enrolledIn" to every course, which returns true or false based on the user making the request. New courses I'm enrolled in are added by updating this field (even if the rest of the Course object isn't editable, because I'm not its owner). But is this the correct solution? Is there a better way? I'm not sure.
Let's say I have a Course, which has a "Textbook" resource associated with it (1 to 1). How do I represent this? When getting a Course, should I return the Textbook resource embedded in this? When updating a course, how do I change the Textbook the Course uses? By passing in a new object? Alright, so can I update the Textbook by passing in the same Textbook object to the Course resource, but modifying some of its paramaters?
Let's say my system has a "User" resource that has several paramaters like "Name". Let's say my Student, in the database, has a foreign key to the User (it's a 1-1 relationship, but not every User is a Student, of course). Note that Students are the ones that are enrolled in courses, not Users.
How do I model this in my classes? Do I model this as a Student that "Has-a" User object? When I log in, do I keep a copy of my User object? But what if I'm a student and want to do different things if I'm a student? Also, let's say I have comments somewhere in my application. Comments are owned by users. So let's say I get a list of comments, and their authors - do I return a User object? But what if I want to highlight all the comments posted by Students? How do I differentiate?
This almost feels dated, like many recent articles making the same point about web development trends. Unfortunately, a lot of this is still news to a lot of practicing professionals.
When it comes to coding in general, and especially web, I find (I admit anecdotally) that many people who appear in the know are living roughly five years in the past. In a recent discussion, a friend explained that JavaScript is an example of a strictly client-side language.
I suspect many developers are delayed by books and classes, paradoxically, even though all the information on the new sexy things is theoretically a click away.
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 where I rarely have to touch CSS issues, but on my own projects, I get a lot of enjoyment on this, maybe because it's just a change.
Client side MVC is overkill in a lot of cases, but when doing client work you will come across these, so this is a good suggestion.
Optimization is something that can get left out if you have a dev team in which nobody picks up that piece. For me, I don't do things the client hasn't authorized payment for me to do and I'm generally busy enough that I hit those paid items and then I'm immediately switching to another project. Often my client is another developer who has pieced together a team. Nobody gets paid to do the optimization, maybe because the main developer is sloppy, lazy, or just doesn't know. It's just one of many details which should be covered but is often left out because of deadlines or a tight budget.
I would suggest that you should start applying MVC practises as soon as you start adding Javascript to your page. You don't necessarily need a complex framework, so long as you stick to the separation of concerns.
I think that's something that's best described by "you know it when you run into it" perhaps at the time when stuff starts getting away from you.
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.
It's not like you have to actually do something to minify, unless you are still doing it manually. It should be part of your default stack, any decent framework can do that.
#1 has a bunch of links for JS but none for the CSS part of its title. What are some good CSS resources for a developer who typically isn't suited for design.
I would start by looking at some of the available CSS frameworks. There are a million, but first to pop in my head are bootstrap , kube, blueprint, 960.
Also I would familiarize myself with pre processed CSS ie. SASS and LESS
Being familiar with 5 MVC frameworks is required to be considered as web developer? ;)
Some people also don't like web pages stuffed to the limit with JS code, so I wonder whether everybody agrees that you should take for every task a specialized library. (Responsive framework, modernizr, ...)
That's what I stopped on... FIVE javascript MVC frameworks? Maybe five WEB frameworks for the top languages, but knowing five JS MVC frameworks seems like a complete waste.
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 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.
My blog is still on blogger, I havn't modified it much for the last few years, and the template is due for renewal as I put in the disclaimer towards the end of that article.
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.
As there are lot of comments here, thought about clarifying few points in that article
1) About clean separation of concerns.
A lot of customers expect you to cleanly separate your client side javascript/css/artifacts from your server side implementation. Even to an extent where you can just take it and repackage the same with minor modifications using a container like Phonegap, and distribute it for mobile devices later. HTML5's significance is beyond web - it can take your app beyond the browser.
2) About the REST Layer
Anyway you are investing in building a web application, so you need to ensure the plumbing portion is re-usable beyond your traditional 'website'. If you want to build a native phone application or a Chrome plug in tomorrow, you should be able to use the same service layer.
Tips to learn to survive? I don't know how anyone can even begin without familiarity with most of these. Some of them are somewhat mind boggling though. "...familiarize yourself with at least five..." MVC frameworks? What?
I remember when I was coding ASP sites with tables. We were happy because the CC hover property was implemented for the first time in IE4. Web development is always changing. We are professionals sandcastles builders.
What I like about web development is that it is always changing. Each day something new to learn and try. Those are nice tips, but hardly a revelation for the HN crowd. A bit surprised it's the top story.
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.
only if the cost of supporting <noscript> is less than the benefit, which for a lot of sites it probably isn't. The people who turn off javascript are in the extreme minority
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 addressed to these guys?
Someone mentioned that .NET people is lagging on these things. Personally, I've noticed that they like using HTTP, HTML, JS, and CSS abstractions, they generate the code within their server-side language, so they don't try to learn these technologies.
I couldn't help but notice the self-aggrandizing "most valuable professional evah" logo front-and-center on this guy's blog, so I feel compelled to add the 7th tip to his list. Here goes.
I find people who use "evah" to mock others "douchey" as well. And fairly egotistical.
You might consider that for some people, that little logo might actually mean something. Whether it does for you isn't important. After all, your immature reaction and comment is far worse in my eyes then any offense the author of the article committed. Not that you'll care.
Humility makes you better at your job, but in many places it will prevent you from developing that job into a career.
Humility is what makes us recognize the weaknesses in our skill and knowledge, and what makes us seek feedback from others to hone that skill. I'm convinced that not being self-satisfied is key to becoming a master craftsmen. But, if you don't advertise your own skill, people will think less of you than you really are, and you won't get the jobs that you really want.
Code once and run in all platforms is pretty much a myth no matter the framework you use, including the web ecosystem.
I've lost count of how many times I wished we could run in the browser a decent language like python or ruby. Or describe the data of documents in something more meaningful like JSON instead of HTML. And then there's the DOM, CCSS, and all the browser specific nonsense.
Can I just ignore this crap and code my applications already?
I'm confused about the JSON > HTML part of your comment. Independent of which one is better overall, wouldn't HTML be more meaningful than JSON because it has semantics attached to tags?
I've been working working working on a relatively complex user interface in JS at work lately (merging suspected duplicates from a CRM together, and specifying which fields from each duplicate contact is the "correct" field) . It involves a lot of DOM manipulation and user input/feedback.
We make use of a jQuery in our app, and I was quite happy to see that although I develop in Chrome and Linux, the UI worked pretty much flawlessly on Firefox and Opera on Linux, and IE8 (and methinks 7, but can't remember) on Windows.
We may be lucky in that we can ignore IE6 and earlier Firefox and Chrome, but my point is that something like jQuery does a damn fine job of abstracting away browser differences. May not be perfect, but better than we can afford to do.
I say this because we probably all aware that we're stuck with JS in the browser for a while...
You're right, I didn't go far enough to make myself clear on that point. The semantics of HTML tags could be pretty easily covered by reserved words for keys, and something like markdown for text formatting.
From that we'd get all the benefits of a cleaner syntax, such as a saner grammar which could lead to cleaner APIs, less bugs, less maintenance, etc.
We need something in between that offers a sane development model and deals with the complexity and anachronism of the underlying platform. GWT cross-compilation is an excellent example. It has enabled the painless development of complex Javascript-based web UIs[1], with the tool support of any other software development project. This is what I'm going to look to for the future of web application development, not patchy solutions to the complete mess that is barebones Javascript development.
For examples of what I have done with GWT: TeampostgreSQL (http://www.teampostgresql.com), a rich PostgreSQL web interface, and my HTML5 game engine (http://www.webworks.dk/enginetest).
EDIT: By the way, it is only a matter of time until we have complete canvas-based UI libraries, frameworks and tools suites akin to Flex (probably from Adobe, too). When that happens the web will really have arrived as a rich client platform. I would be very surprised if there isn't a few projects in this space nearing completion at this point, since the underlying technology is basically ready.