5 ms·

It also may be the people that are drawn to it. There are backend/frontend dev stereotypes for a reason. In my experience, the frontend dev teams have tended to

It also may be the people that are drawn to it. There are backend/frontend dev stereotypes for a reason. In my experience, the frontend dev teams have tended to be earlier in their careers and more likely to come from a 'non-traditional' background into tech. You're not seeing code boot camps popping up for Java and .NET developers like you are HTML/JS and Rails. It's not a knock, the younger people usually bring the enthusiasm and fresh ideas to the table- but that enthusiasm and zest hasn't been sobered with a decade of real world experience and a more analytical/engineering background and schooling.

samcodes 11y ago
This is a really interesting point. I think another factor is that if you have a huge amount of users, you need robust server code. But front end code only has one user at a time. And it's much more tied to design, so it gets "stale" faster, so there are just very different pressures on it that make it less amenable to a traditional engineering approach. In that it might be worth trading some robustness for speed of updates.
- manyxcxi 11y ago
  You bring up a good point that I missed in my first comment. The design. God damned designers! I kid- I worked at an agency for years and the hardest part was always getting the build to match the design when they were still laying out the design pixel perfect in Photoshop and Illustrator as if we were doing print work or doing fixed width pages. I've seen some designs that were, frankly, beautiful but it took no more than 5 seconds to highlight the 30 areas that were going to cause massive budget overruns trying to make look exactly right, have decent performance, and work in eleventybillion browsers. I've certainly appreciated what interesting designers can bring to the table, but we're still a ways away from a lot of traditional designers having a good handle of what their design really means when we're building it. Kind of like the contractor who bitches about the architect for designing an angle that is impossible to hammer into. Sometimes there is a disconnect.
mattmanser 11y ago
I would have agreed with this, but I've just been exposed to what's happening in the new .Net core and asp.net 5. It's a clusterfuck of the sublime and the downright stupid. Any new trendy idea has been rammed in to the new ASP.Net with startlingly high churn for a MS product and bizarre choices like forcing you to program in particular (often undesirable overkill) ways. So the JS churn model has begun to infect another language as a model to be emulated rather than reviled.
- manyxcxi 11y ago
  Yeah, that's a good point. In fairness to MSFT, with Roslyn and really trying to make the .NET stack able to run on non-Windows boxes you would think there would have to be a few hiccups along the way. I feel like the JS scene is facing this level of upheaval every 9-12 months right now.
  - mattmanser 11y ago
    That doesn't mean they have to re-architecture their MVC to force you to use DI all over the place whether you want to or not. Or to start running command windows when you used to have a working IDE. Hell, even the new config loading is an utter pain in the ass compared to simply just accessing a static object available from everywhere. There are great bits, don't get me wrong, but I do wonder how much of their larger audience are actually going to enjoy this. It presently feels like a massive step back for very little gain. It just feels, looks and smells like the old JavaFactoryHammerWidgetFactoryFactory of the days of old, i.e. over-engineering which means you can't get any actual functionality done as there's more scaffolding than functional code. You end up drowning in utterly useless code that doesn't really do anything.
nissimk 11y ago
I think it is a combination of what you are saying. The reason there is so much variation is because the userbase is extremely wide in the javascript world. If you want to deliver your application to the web, you are going to have javascript in there somewhere, and pretty much everybody needs to have their applications on the web these days. So you have developers from a native mindset, an embedded mindset, a backend / data oriented mindset. Nodejs is great for rapid development of http based api's, so you get a lot of backend api perspectives, and of course, as you mentioned, there is the whole html5 / javascript frontend crowd. Then you have the situation where javascript is both functional and object oriented, so you get toolmakers who focus on one of those or the other more. Now with compile to javascript being more widely accepted, you get a lot of developers from static typed languages insisting that this missing feature is the panacea which will solve all of the problems. The wide variety of perspectives within the javascript developer community is what sparks the wide variety of new tools and techniques. And popularity of these tools and techniques is definitely based on trends and fads.

samcodes 11y ago

This is a really interesting point. I think another factor is that if you have a huge amount of users, you need robust server code. But front end code only has one user at a time. And it's much more tied to design, so it gets "stale" faster, so there are just very different pressures on it that make it less amenable to a traditional engineering approach. In that it might be worth trading some robustness for speed of updates.

manyxcxi 11y ago
You bring up a good point that I missed in my first comment. The design. God damned designers! I kid- I worked at an agency for years and the hardest part was always getting the build to match the design when they were still laying out the design pixel perfect in Photoshop and Illustrator as if we were doing print work or doing fixed width pages. I've seen some designs that were, frankly, beautiful but it took no more than 5 seconds to highlight the 30 areas that were going to cause massive budget overruns trying to make look exactly right, have decent performance, and work in eleventybillion browsers. I've certainly appreciated what interesting designers can bring to the table, but we're still a ways away from a lot of traditional designers having a good handle of what their design really means when we're building it. Kind of like the contractor who bitches about the architect for designing an angle that is impossible to hammer into. Sometimes there is a disconnect.

mattmanser 11y ago

I would have agreed with this, but I've just been exposed to what's happening in the new .Net core and asp.net 5. It's a clusterfuck of the sublime and the downright stupid. Any new trendy idea has been rammed in to the new ASP.Net with startlingly high churn for a MS product and bizarre choices like forcing you to program in particular (often undesirable overkill) ways. So the JS churn model has begun to infect another language as a model to be emulated rather than reviled.

manyxcxi 11y ago
Yeah, that's a good point. In fairness to MSFT, with Roslyn and really trying to make the .NET stack able to run on non-Windows boxes you would think there would have to be a few hiccups along the way. I feel like the JS scene is facing this level of upheaval every 9-12 months right now.
- mattmanser 11y ago
  That doesn't mean they have to re-architecture their MVC to force you to use DI all over the place whether you want to or not. Or to start running command windows when you used to have a working IDE. Hell, even the new config loading is an utter pain in the ass compared to simply just accessing a static object available from everywhere. There are great bits, don't get me wrong, but I do wonder how much of their larger audience are actually going to enjoy this. It presently feels like a massive step back for very little gain. It just feels, looks and smells like the old JavaFactoryHammerWidgetFactoryFactory of the days of old, i.e. over-engineering which means you can't get any actual functionality done as there's more scaffolding than functional code. You end up drowning in utterly useless code that doesn't really do anything.

nissimk 11y ago

I think it is a combination of what you are saying. The reason there is so much variation is because the userbase is extremely wide in the javascript world. If you want to deliver your application to the web, you are going to have javascript in there somewhere, and pretty much everybody needs to have their applications on the web these days. So you have developers from a native mindset, an embedded mindset, a backend / data oriented mindset. Nodejs is great for rapid development of http based api's, so you get a lot of backend api perspectives, and of course, as you mentioned, there is the whole html5 / javascript frontend crowd. Then you have the situation where javascript is both functional and object oriented, so you get toolmakers who focus on one of those or the other more. Now with compile to javascript being more widely accepted, you get a lot of developers from static typed languages insisting that this missing feature is the panacea which will solve all of the problems. The wide variety of perspectives within the javascript developer community is what sparks the wide variety of new tools and techniques. And popularity of these tools and techniques is definitely based on trends and fads.