3 ms·

Don't take this the wrong way, but perhaps you should rethink your career choice. If tools changing and be supplanted by other tools causes you too much stress

Don't take this the wrong way, but perhaps you should rethink your career choice. If tools changing and be supplanted by other tools causes you too much stress then I have unpleasant news for you - it will never stop. The good news is, it doesn't have to be stressful. If a tool you like works, use it! Don't worry about the shiny new stuff coming out, worry about being productive today, and you will find that your stress level will decrease dramatically. But above all, become comfortable with the fact that you will always be learning new things until the day you retire. You aren't flipping burgers.

MasterScrat 12y ago
Fair point, however his fear of "getting wrecked again" is a very valid concern for companies. Which certainly don't want to end up with webapps relying on obsolete frameworks. At work we have some old projects built on GWT, some newer projects built on AngularJS and both will soon be outdated. Also there is no real choice to build a modern web application, that clients now expect, while being really future-proof. That's the first time I see a situation like this, typically you need to pick between shiny new tech vs old boring one.
- marknutter 12y ago
  Building anything on the web and expecting it to last more than 5 years is foolish in my opinion. But yes, if your company is expecting to build an app that won't be re-written for more than 5 years then by all means do it in vanilla javascript, but you'll likely end up building a custom framework anyways.
  - Silhouette 12y ago
    Building anything on the web and expecting it to last more than 5 years is foolish in my opinion. But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies. You can build excellent web sites that serve valuable business and/or social functions, using nothing but technologies that have been around for 10 or even 20 years. And if we're talking about app-style development, why should someone who invests significant time and resources to build, say, an intranet app to automate some function in their business not expect that app to still work five years from now? This is why standards and stability are important, and it's why "living standards" are a pile of [expletive deleted], and it's why it's a bad thing that some browsers currently have very rapid release cycles with an obvious emphasis on adding new shiny things at the expense of maintaining support for older technologies, and it's why you shouldn't build anything you might need to maintain for more than a year or two with the JS framework du jour. A lot of front-end devs today make building simple user interfaces to access databases seem awfully complicated. Every time I read articles like this one I become more convinced that most of that complexity is of their own making. They talk down to old school developers who put most of the logic on the back end, or who build interactions using jQuery, but sites written 5 years ago using those technologies still work and can still be maintained just fine. I wouldn't bet on that being true for anything built with a framework like Angular or React today.
    - marknutter 12y ago
      > But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies. I agree that it shouldn't be, but I don't agree that it's possible for it not to be, mainly because browsers are constantly changing and improving and assumptions older frameworks had become irrelevant over a long enough time period (certainly over 5 years). This is precisely the reason why Angular is having to make such drastic re-write - they're trying to align better with Web Components and other ECMA6 features that are coming down the pipeline. I hate to stereotype but often people who complain about the volatility of web development tools and frameworks are people who are traditionally server-side developers who have enjoyed a relatively stable deploy target for periods much longer than 5 years. Trust me, I wish it was the same for front-end development. > And if we're talking about app-style development, why should someone who invests significant time and resources to build, say, an intranet app to automate some function in their business not expect that app to still work five years from now? Because building desktop style applications using old web technologies is really freaking hard. If it wasn't, we there wouldn't be such a huge deluge of web frameworks to help do it. > This is why standards and stability are important, and it's why "living standards" are a pile of [expletive deleted], and it's why it's a bad thing that some browsers currently have very rapid release cycles with an obvious emphasis on adding new shiny things at the expense of maintaining support for older technologies, and it's why you shouldn't build anything you might need to maintain for more than a year or two with the JS framework du jour. I can't really disagree with you here and that's why I find React so compelling because they're kind of saying "fuck you" to the standards committees and building something they know works whether or not the promises of ECMA6 and HTML5 come to fruition. > A lot of front-end devs today make building simple user interfaces to access databases seem awfully complicated. Every time I read articles like this one I become more convinced that most of that complexity is of their own making. They talk down to old school developers who put most of the logic on the back end, or who build interactions using jQuery, but sites written 5 years ago using those technologies still work and can still be maintained just fine. I wouldn't bet on that being true for anything built with a framework like Angular or React today. I'm guessing you're not a front-end developer so forgive me if I'm wrong, but what you're saying is absurd. It is hard. Much harder, in fact, than building an iOS or Android App which rely on sane frameworks built by single entities to function perfectly within one sandboxed environment. Web applications like Google Docs are every bit as sophisticated as native mobile apps but must be built without the benefit of native performance and monolithic, corporate-sponsored SDKs. Putting "most of the logic on the backend" isn't a viable solution for native mobile apps, why would it be a viable solution for desktop-style web apps? Just step back for a moment and compare the functionality you get from a framework like Angular or Ember to the functionality you get with the iOS or Android SDK and you will see they are all solving generally the same problem in the same way. The only difference is that there are far more choices of frameworks on the Web (which is both a curse and a blessing).
- grumblestumble 12y ago
  As someone already noted, Google's latest large-scale web app, Inbox, was built with GWT. How is it then "outdated"? When something new and shiny comes along, old technologies don't magically stop working. A maintenance path and new leadership has been established for ng1.x : https://plus.google.com/u/0/+IgorMinar/posts/2Uo6yh4AV7L https://plus.google.com/u/0/+IgorMinar/posts/2Uo6yh4AV7L

MasterScrat 12y ago

Fair point, however his fear of "getting wrecked again" is a very valid concern for companies. Which certainly don't want to end up with webapps relying on obsolete frameworks. At work we have some old projects built on GWT, some newer projects built on AngularJS and both will soon be outdated. Also there is no real choice to build a modern web application, that clients now expect, while being really future-proof. That's the first time I see a situation like this, typically you need to pick between shiny new tech vs old boring one.

marknutter 12y ago
Building anything on the web and expecting it to last more than 5 years is foolish in my opinion. But yes, if your company is expecting to build an app that won't be re-written for more than 5 years then by all means do it in vanilla javascript, but you'll likely end up building a custom framework anyways.
- Silhouette 12y ago
  Building anything on the web and expecting it to last more than 5 years is foolish in my opinion. But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies. You can build excellent web sites that serve valuable business and/or social functions, using nothing but technologies that have been around for 10 or even 20 years. And if we're talking about app-style development, why should someone who invests significant time and resources to build, say, an intranet app to automate some function in their business not expect that app to still work five years from now? This is why standards and stability are important, and it's why "living standards" are a pile of [expletive deleted], and it's why it's a bad thing that some browsers currently have very rapid release cycles with an obvious emphasis on adding new shiny things at the expense of maintaining support for older technologies, and it's why you shouldn't build anything you might need to maintain for more than a year or two with the JS framework du jour. A lot of front-end devs today make building simple user interfaces to access databases seem awfully complicated. Every time I read articles like this one I become more convinced that most of that complexity is of their own making. They talk down to old school developers who put most of the logic on the back end, or who build interactions using jQuery, but sites written 5 years ago using those technologies still work and can still be maintained just fine. I wouldn't bet on that being true for anything built with a framework like Angular or React today.
  - marknutter 12y ago
    > But why should it be? The goal of building web sites and apps isn't to use the latest shiny new technologies. I agree that it shouldn't be, but I don't agree that it's possible for it not to be, mainly because browsers are constantly changing and improving and assumptions older frameworks had become irrelevant over a long enough time period (certainly over 5 years). This is precisely the reason why Angular is having to make such drastic re-write - they're trying to align better with Web Components and other ECMA6 features that are coming down the pipeline. I hate to stereotype but often people who complain about the volatility of web development tools and frameworks are people who are traditionally server-side developers who have enjoyed a relatively stable deploy target for periods much longer than 5 years. Trust me, I wish it was the same for front-end development. > And if we're talking about app-style development, why should someone who invests significant time and resources to build, say, an intranet app to automate some function in their business not expect that app to still work five years from now? Because building desktop style applications using old web technologies is really freaking hard. If it wasn't, we there wouldn't be such a huge deluge of web frameworks to help do it. > This is why standards and stability are important, and it's why "living standards" are a pile of [expletive deleted], and it's why it's a bad thing that some browsers currently have very rapid release cycles with an obvious emphasis on adding new shiny things at the expense of maintaining support for older technologies, and it's why you shouldn't build anything you might need to maintain for more than a year or two with the JS framework du jour. I can't really disagree with you here and that's why I find React so compelling because they're kind of saying "fuck you" to the standards committees and building something they know works whether or not the promises of ECMA6 and HTML5 come to fruition. > A lot of front-end devs today make building simple user interfaces to access databases seem awfully complicated. Every time I read articles like this one I become more convinced that most of that complexity is of their own making. They talk down to old school developers who put most of the logic on the back end, or who build interactions using jQuery, but sites written 5 years ago using those technologies still work and can still be maintained just fine. I wouldn't bet on that being true for anything built with a framework like Angular or React today. I'm guessing you're not a front-end developer so forgive me if I'm wrong, but what you're saying is absurd. It is hard. Much harder, in fact, than building an iOS or Android App which rely on sane frameworks built by single entities to function perfectly within one sandboxed environment. Web applications like Google Docs are every bit as sophisticated as native mobile apps but must be built without the benefit of native performance and monolithic, corporate-sponsored SDKs. Putting "most of the logic on the backend" isn't a viable solution for native mobile apps, why would it be a viable solution for desktop-style web apps? Just step back for a moment and compare the functionality you get from a framework like Angular or Ember to the functionality you get with the iOS or Android SDK and you will see they are all solving generally the same problem in the same way. The only difference is that there are far more choices of frameworks on the Web (which is both a curse and a blessing).
grumblestumble 12y ago
As someone already noted, Google's latest large-scale web app, Inbox, was built with GWT. How is it then "outdated"? When something new and shiny comes along, old technologies don't magically stop working. A maintenance path and new leadership has been established for ng1.x : https://plus.google.com/u/0/+IgorMinar/posts/2Uo6yh4AV7L https://plus.google.com/u/0/+IgorMinar/posts/2Uo6yh4AV7L