Live data from Hacker News

Changing times for web developers

amazedsaint.com

91–100 of 147 posts

Re: Changing times for web developers

#91
post #9

Agree with half, but don't worry about: 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.

About JS MVC frameworks - It's about scaling your development teams by putting a re-usable pattern in place so that things will jell together.

HTML5 - My point was, understand the parts you can use now.

Optimization - Again, do it when you are ready to do it.

Re: Changing times for web developers

#92

Earlier quoted context omitted.

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…

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 ow…

Thank you for answering this for me. Even the trigger for this post was a series of interviews I did for .NET web developers in the last few weeks.

Re: Changing times for web developers

#93
post #9

Agree with half, but don't worry about: 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.

About JS MVC frameworks - It's about scaling your development teams by putting a re-usable pattern in place so that things will jell together. HTML5 - My point was, understand the parts you can use now. Optimization - Again, do it when you are ready to do it.

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.

Re: Changing times for web developers

#94

Earlier quoted context omitted.

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 ow…

Thank you for answering this for me. Even the trigger for this post was a series of interviews I did for .NET web developers in the last few weeks.

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.

Re: Changing times for web developers

#95
post #32

Earlier quoted context omitted.

Quality code ages well. Old is not an excuse for crappy or slow, neither you can so easily disclaim your own code. Would you take fashion advices from someone with horrible and smelly clothes ?

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...

Yes, but when great web developers on HN are a dime a dozen, I don't want to waste time on content that isn't polished.

Re: Changing times for web developers

#96
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.

Re: Changing times for web developers

#97
post #3

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…

I think the 'stupid typo' argument is not really valid if you're using syntax checking (e.g. jshint/jslint) in your stack.

Re: Changing times for web developers

#98

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…

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.

Re: Changing times for web developers

#99

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…

I agree with the gist or your post, but as others have pointed out, GWT is essentially depricated and really not the right direction to go.

I think the angle that TypeScript is taking may prove to be more fruitful.

Re: Changing times for web developers

#100

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…

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 wrapp…

>> There is no future in GWT.

I think there is. This doesn't look like the site of a failing project: https://developers.google.com/web-toolkit/

>> 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.

http://code.google.com/p/gwt-validation/

>> 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.

Post reply on HN