5 ms·

To push back a little against this notion—is this even true? On the web front-end, I develop with React and Vue, which were released in 2013 and 2014 respective

by laser 8y ago

To push back a little against this notion—is this even true? On the web front-end, I develop with React and Vue, which were released in 2013 and 2014 respectively. On the backend, I primarily use Phoenix, which was released in 2015. On the iOS front-end, I write apps in Swift, which was released in 2014. For our ML, practically nothing we use existed three years ago (except underlying layers, like language and below). That being said, you don't have to use the newer technologies if you don't want to. People use them because they offer advantages over the older technologies (generally), whether that be in development effort saved or performance and features. You can still build your web front-ends in jQuery, your backends in php or asp.net, and your iOS apps in objective-c. I hear the notion fairly often that web front-end development evolves more quickly, but I'm not sure that it's even true.

quanticle 8y ago
It's been true in my experience. I've had interviewers scoff at me for mentioning Bower and Grunt, saying that the latest best practice was Webpack. Is Webpack really better than Bower and Grunt? It's different, that's for sure. I get the feeling that a lot of the web development community has trouble understanding the difference between different and better. That's why we see so many wheels get reinvented so often. Is React a better way of manipulating the DOM than, say, Angular? I don't know the answer to that. It certainly is a different way. Is Webpack better at combining and packaging code than Grunt and Gulp? It's a different way of of packaging code. In other communities, there's a much more nuanced discussion of whether technologies are appropriate. In the web development community, there's a much greater emphasis on painting technologies as absolutely "good" or "bad", "current" or "obsolete", without the suggestion that this new technology can coexist alongside existing technologies and address new use cases that the existing technologies didn't address. I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer. There was no consideration whether React was a more appropriate framework for the task at hand. There was little consideration of the costs of the transition. It was a knee-jerk decision. "This framework is old, and the code written in it is nasty and buggy. We need to "refactor" (read: rewrite) our code to use React so that we can be current with the state-of-the-art best practices in web development." I compare this with, for example, the Python community, where there is much more of a detente between frameworks like Django and Flask. Even though Flask is newer, there wasn't ever really a question of Flask replacing Django. Flask was merely seen as a solution for cases you'd have to strip out of a lot of Django (like its ORM and much of its middleware) in order to get a simple interactive website up and running quickly. There wasn't nearly as much of a push to use Flask because it was merely newer.
- ng12 8y ago
  > I get the feeling that a lot of the web development community has trouble understanding the difference between different and better I think you're confusing the HN community with the web dev community :) Everything I picked I picked because it was better for a specific reason. React solved the problems I was having with writing reusable code. Webpack takes all the grunt-work out of Grunt. TypeScript purely for the ease of refactoring. > I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer. You can do this with any project The reason these choices exist is because lots of very smart people are thinking very hard about ways to do things better -- it's naive to think there's no merit to them because some people you happen to know are making poorly informed decisions.
  - quanticle 8y ago
    >The reason these choices exist is because lots of very smart people are thinking very hard about ways to do things better Well, that's one way of thinking about it. Another way of thinking about is that it's a lot easier to gain recognition and mindshare for releasing a new framework than there is in refactoring or implementing improvements upon an existing framework. This incentive structure applies at both the corporate and individual level. I've found, from my experience working at large tech companies, that many frameworks get started because a senior engineer wants a demonstrable project to demonstrate their leadership and technical skills in order to get a raise or a promotion. A new framework is definitely a high-impact project with a very clear deliverable and a well-defined set of requirements. So they make a new framework and then market the absolute daylights out of it, since one of their goals isn't just to create a new framework, but also to demonstrate some level of adoption for it. So the framework is pitched as the next big thing, which makes all existing frameworks obsolete. Scale this motivation and approach up to the level of corporations rather than individuals, and you have the modern web development ecosystems. Corporations want goodwill and mindshare, and they know that one of the ways to get that is to release a framework that everyone uses.
    - ng12 8y ago
MarsAscendant 8y ago
> That being said, you don't have to use the newer technologies if you don't want to. When you're new to the scene, how on Earth would you know? Seemingly everybody's doing it, there's no sane source on whether it's worth using or its tangible benefits, and you can't make heads or tails of it – you need to be in the game already to even begin doing so. Web dev may not be evolving, but it certainly is developing into new forms fairly frequently. As my newbie coding days went by, I witnessed the rise of Angular as this massive new way to handle web codebase. After some time, it grew into Angular2, with a seemingly indiscernable structure to its apps. Around the same time, came Vue, which is "the same thing as Angular, only better". And that's before I started getting around Github... This kind of development doesn't match the mental model we have for improvement in a technological sphere. If there's something new, it must be better, right? Bigger TVs, smart TVs, 3D TVs... You could still watch your old TV (not really, 'cause the transmission's gone digital, which few, if any, old TVs support), but you'll be behind — and given the frantic pace of the everyday life now, how'd you know better? I'd sworn off frameworks until bigger projects entirely. You can get a lot from regular JS, without the overhead of learning and keeping up the mental model of a new framework. I can afford to, because I'm an independent developer who codes for fun. Could people in the industry afford the same?
- laser 8y ago
  This varies by technology, but often you can get productive within a day or two with these technologies. I mean, the core Vue docs (entire essentials section, from Introduction through Components), is 12k words, including code. At 50 wpm (1/6th of college reading speed on non-technical material), that's four hours of reading. If you wanna skim the thing, you could easily see the gist of what it's about in less than an hour.
  - MarsAscendant 8y ago
    I'm not trying to argue about relative effectiveness behind Vue et al. I'm saying that, as a newbie, you wouldn't be able to know the difference. "Just try it" isn't a good argument when all you see are big, unfamiliar names that you're apparently supposed to know – and without guidance, learning web dev on your own, you effectively do, even if just to see that you don't need it. It's overwhelming. Imagine having to learn color theory and all kinds of subtle differences in the production of crayons you could have before you sit down to doodle something in your spare time. Imagine having to read your literary national treasure section whole before you want to write that cool short story you had when you took that shower. Ridiculous! So, I argue, is the fact that there's seemingly an obligation to read up documentation for major frameworks before you sit down and code your first clicker-number-increaser.
jb3689 8y ago
If you look back another generation the difference is more apparent. What did you use prior to Phoenix? Node was popular for a bit, but Rails/Django was much larger. In their lifetime there have been a number of major players in the front-end (jQuery, Backbone, Ember, Angular, Angular 2.0, a few more obscure libraries). There have also been a number of build tools (Grunt, Gulp, Webpack) and a number of preprocessors (LESS, SASS, etc) The churn has been real

by laser 8y ago

quanticle 8y ago

It's been true in my experience. I've had interviewers scoff at me for mentioning Bower and Grunt, saying that the latest best practice was Webpack. Is Webpack really better than Bower and Grunt? It's different, that's for sure. I get the feeling that a lot of the web development community has trouble understanding the difference between different and better. That's why we see so many wheels get reinvented so often. Is React a better way of manipulating the DOM than, say, Angular? I don't know the answer to that. It certainly is a different way. Is Webpack better at combining and packaging code than Grunt and Gulp? It's a different way of of packaging code. In other communities, there's a much more nuanced discussion of whether technologies are appropriate. In the web development community, there's a much greater emphasis on painting technologies as absolutely "good" or "bad", "current" or "obsolete", without the suggestion that this new technology can coexist alongside existing technologies and address new use cases that the existing technologies didn't address. I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer. There was no consideration whether React was a more appropriate framework for the task at hand. There was little consideration of the costs of the transition. It was a knee-jerk decision. "This framework is old, and the code written in it is nasty and buggy. We need to "refactor" (read: rewrite) our code to use React so that we can be current with the state-of-the-art best practices in web development." I compare this with, for example, the Python community, where there is much more of a detente between frameworks like Django and Flask. Even though Flask is newer, there wasn't ever really a question of Flask replacing Django. Flask was merely seen as a solution for cases you'd have to strip out of a lot of Django (like its ORM and much of its middleware) in order to get a simple interactive website up and running quickly. There wasn't nearly as much of a push to use Flask because it was merely newer.

ng12 8y ago
> I get the feeling that a lot of the web development community has trouble understanding the difference between different and better I think you're confusing the HN community with the web dev community :) Everything I picked I picked because it was better for a specific reason. React solved the problems I was having with writing reusable code. Webpack takes all the grunt-work out of Grunt. TypeScript purely for the ease of refactoring. > I've heard of numerous (and participated in two) projects which migrated from an existing framework (such as Angular, Ember, or Knockout) to React, solely because React was newer. You can do this with any project The reason these choices exist is because lots of very smart people are thinking very hard about ways to do things better -- it's naive to think there's no merit to them because some people you happen to know are making poorly informed decisions.
- quanticle 8y ago
  >The reason these choices exist is because lots of very smart people are thinking very hard about ways to do things better Well, that's one way of thinking about it. Another way of thinking about is that it's a lot easier to gain recognition and mindshare for releasing a new framework than there is in refactoring or implementing improvements upon an existing framework. This incentive structure applies at both the corporate and individual level. I've found, from my experience working at large tech companies, that many frameworks get started because a senior engineer wants a demonstrable project to demonstrate their leadership and technical skills in order to get a raise or a promotion. A new framework is definitely a high-impact project with a very clear deliverable and a well-defined set of requirements. So they make a new framework and then market the absolute daylights out of it, since one of their goals isn't just to create a new framework, but also to demonstrate some level of adoption for it. So the framework is pitched as the next big thing, which makes all existing frameworks obsolete. Scale this motivation and approach up to the level of corporations rather than individuals, and you have the modern web development ecosystems. Corporations want goodwill and mindshare, and they know that one of the ways to get that is to release a framework that everyone uses.
  - ng12 8y ago

MarsAscendant 8y ago

> That being said, you don't have to use the newer technologies if you don't want to. When you're new to the scene, how on Earth would you know? Seemingly everybody's doing it, there's no sane source on whether it's worth using or its tangible benefits, and you can't make heads or tails of it – you need to be in the game already to even begin doing so. Web dev may not be evolving, but it certainly is developing into new forms fairly frequently. As my newbie coding days went by, I witnessed the rise of Angular as this massive new way to handle web codebase. After some time, it grew into Angular2, with a seemingly indiscernable structure to its apps. Around the same time, came Vue, which is "the same thing as Angular, only better". And that's before I started getting around Github... This kind of development doesn't match the mental model we have for improvement in a technological sphere. If there's something new, it must be better, right? Bigger TVs, smart TVs, 3D TVs... You could still watch your old TV (not really, 'cause the transmission's gone digital, which few, if any, old TVs support), but you'll be behind — and given the frantic pace of the everyday life now, how'd you know better? I'd sworn off frameworks until bigger projects entirely. You can get a lot from regular JS, without the overhead of learning and keeping up the mental model of a new framework. I can afford to, because I'm an independent developer who codes for fun. Could people in the industry afford the same?

laser 8y ago
This varies by technology, but often you can get productive within a day or two with these technologies. I mean, the core Vue docs (entire essentials section, from Introduction through Components), is 12k words, including code. At 50 wpm (1/6th of college reading speed on non-technical material), that's four hours of reading. If you wanna skim the thing, you could easily see the gist of what it's about in less than an hour.
- MarsAscendant 8y ago
  I'm not trying to argue about relative effectiveness behind Vue et al. I'm saying that, as a newbie, you wouldn't be able to know the difference. "Just try it" isn't a good argument when all you see are big, unfamiliar names that you're apparently supposed to know – and without guidance, learning web dev on your own, you effectively do, even if just to see that you don't need it. It's overwhelming. Imagine having to learn color theory and all kinds of subtle differences in the production of crayons you could have before you sit down to doodle something in your spare time. Imagine having to read your literary national treasure section whole before you want to write that cool short story you had when you took that shower. Ridiculous! So, I argue, is the fact that there's seemingly an obligation to read up documentation for major frameworks before you sit down and code your first clicker-number-increaser.

jb3689 8y ago

If you look back another generation the difference is more apparent. What did you use prior to Phoenix? Node was popular for a bit, but Rails/Django was much larger. In their lifetime there have been a number of major players in the front-end (jQuery, Backbone, Ember, Angular, Angular 2.0, a few more obscure libraries). There have also been a number of build tools (Grunt, Gulp, Webpack) and a number of preprocessors (LESS, SASS, etc) The churn has been real