5 ms·

As someone who last web-dev'd in the day of ASP.NET MVC, GWT, jQuery, and backbone.js, this post reads like one of those modern JS development satires [0] I kn

As someone who last web-dev'd in the day of ASP.NET MVC, GWT, jQuery, and backbone.js, this post reads like one of those modern JS development satires [0] I know you meant well, and this is just the state of the world, but I can't help but feel like a dinosaur just because I spent the last 5 years focusing on server/cloud infrastructure. Is there any hope for someone like me if I ever want to step back into it? I ask sincerely. It seems like every best-practice framework's compelling proposition these days is that it's "like XYZ, but fixes this obscure edge case", where XYZ is something that only came out 2 years ago, so I never used it, never mind understood properly. [0] https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

pavlov 9y ago
The way to step back into it is to ignore the library froth, pick something that looks understandable from the principles you already know, and build something useful. Many people spend X hours a day obsessing about whether css-turd-polish.io is better than Sassy.js v4. If you spend those hours working on something productive, you're automatically ahead. The framework churn is increasingly a perpetual motion machine for conference talks. Don't go to conferences and you won't feel like you're missing anything.
- derefr 9y ago
  What if I want to hire frontend devs for a green-field project—what tech-stack experience do I look for?
  - davedx 9y ago
    My approach with hiring is to try and find solid JavaScript programmers foremost. People with experience in the tech we use, or people with a lot of experience with other languages are nice to haves. Anyone who has a solid grasp of (modern) JavaScript will be fine with any front end tech stack.
    - derefr 9y ago
      Well, I mean, sure... but, having hired all these random "solid JavaScript programmers", what do I tell them to use and/or learn? To do useful work, they all need to be using the same thing—so... how do I figure out what should be the standard for a project, if there's nothing forcing any particular option?
      - sprafa 9y ago
        You can let them decide? Then follow agile principles to make sure they are delivering prototypes/features. Ideally you would get a grasp of what they need to do and some idea on how they need to do it. If you don't then you should hire someone that does, or who you can feel almost absolute confidence in. Then let them do the hiring. Just my two cents.
  - zeta0134 9y ago
    Don't bother with specific tech stacks, because as mentioned, the churn rate is really high. Instead, hire good problem solvers who you can tell from their interviews will be able to choose a framework that works well for your new projects, or adapt to the framework you've chosen yourself for your existing ones. Understand that good programmers are kind of hard to find, but okay programmers with experience in XYZ stack are not. Why? Because any reasonably competent programmer can become familiar with a new framework or library in about a week or two. Being able to separate the signal from the noise, and architecture an application well within that framework? That's what you're looking for. The tools themselves aren't that important.
    - inimino 9y ago
      Of course, to follow this advice you have to be able to identify problem-solving ability, which is hard and why most hiring managers fall back on buzzword bingo--to say nothing of HR departments.
  - TheAceOfHearts 9y ago
    I'd strongly suggest using Webpack to build any new serious frontend projects. It's incredibly powerful and flexible enough to be able to adapt to any changes in the ecosystem without having to throw stuff away. As a data point, I know a large projects that slowly migrated away from AMD, favoring CommonJS, and later ES modules. Since ES modules are part of the standard, it makes sense to converge. This was achieved with comparably minimal effort, without throwing code away, and all while enabling newer code to be written in the modern style. React is an incredibly safe bet as well. Facebook is so heavily invested in it that they have multiple engineers working on it full-time. Furthermore, since they actually use the framework, any breaking changes are required to have a clear migration path. They published a blog post [0] explaining their strategy for how they intend to handle version transitions, which I consider incredibly developer-friendly. Look at angular 1.x for an example of a horribly handled transition. [0] https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html https://facebook.github.io/react/blog/2016/02/19/new-version...
- TheAceOfHearts 9y ago
  You can keep track of big new tools and libraries without hopping on every bandwagon, which I guess is why I haven't felt JS fatigue. I'd argue just knowing certain tools even exist can help you do a better job and enable you to make more informed decisions as you tackle new problems. Just create a mental index, in case you later find yourself having to tackle a problem for with the tool is a good fit.
rebootthesystem 9y ago
Chasing technology is a huge mistake. Your end users, your clients, where the money comes from, could not care less if you are coding your website in Visual Basic (is that even possible?). Nope. They are after a solution to a problem. That is ALL they care about. Nothing else. Do not waste your time with this ever-repeating nonsense of chasing the shinny objects. That doesn't mean you stop learning. It does mean you inject a slow low pass filter in your life and don't react to every little movement in technology. You can learn about them while realizing your end users don't care and, in general terms, these technologies have no material advantages in delivering what customers are after. Engineers are not business people. Do no follow what someone with no business experience says because you'll find yourself jumping from tech to tech and no servicing your customers.
- ethbro 9y ago
  * If your client is non-technical, endeavor to somewhat describe the trade-off in using simpler technologies, if there are any that matter to them
vmware513 9y ago
Actually, you can learn modern frontend framework quickly from free tutorials, and you are up-to-date again, for example: http://yoember.com http://yoember.com
TheAceOfHearts 9y ago
I think it depends a lot on the kind of app you're building. Many of these tools start to shine for larger and more complicated projects that are being developed by many engineers over a long period of time. The web community is pretty large, so there's constant competition over different ideas and approaches. For most tools and libraries, I usually read through the docs when I hear about it and create a mental index that it exists, in case I ever need to solve a problem for which it would be a good fit. I'll note that plenty of these tools and libraries have been around longer than two years. If I remember correctly, Webpack came out in 2012 and React in 2013. I point out these two projects because they caused a fundamental shift in the way I approached web development, and neither is looking like it'll be going away soon. My suggestion would be to try out create-react-app [0]. There's still some stumbling points, but it does a good job of showcases the general direction many people in the webdev development community have moved towards. It hides all the build stuff into a black box. As you become more comfortable with the ecosystem and the need arises, you can eject and access all these tools directly. I totally agree that the webdev community should strive to do a better job at explaining the purpose of all these tools, but I don't think this problem is limited to them in the slightest. In fact, I can assure you I feel the exact same way you do when I look at many of these cloud / devops / server / backend tools. Do I want chef, puppet, or ansible? Oh, but you need better dynamic configuration management and service discovery, so be sure to pick up consul or etcd. Remember KVM, jails, and vagrant? All those are dead, containers are the new hotness, say hello to Docker. If you wanna be web scale you'll really need Kubernetes, cuz you wanna be like Google, right? But also check out Deis or Flynn, so you can build your own cloud in the cloud. There's a few other HashiCorp products with nice-looking sites, but I don't even understand the problems they solve well enough to even try poking fun at em. Let's not forget databases! Remember MySQL? It cloned itself and changed its name to Maria. But it turns out that it totally sucks and everyone is using PostgreSQL. Those won't work if you're trying to be web scale, turns out RDBMs are a thing of the past, the future is all about NoSQL. Try out Mongo, it's so easy to use! But be sure to also check out Cassandra, CouchDB, and RethinkDB. They're all NoSQL, but different, but still the same [1]. If you're really set on being like Google, then CockroachDB is the only serious choice anyway. Is anything going slow? You'll have to add some caching with redis or memcached. It's time to jump on the real-time train too, so you'll need some pubsub magic, luckily you can use kafka, rabbitmq, or redis. I'll stop now, since I think this is already way too long. However, I'll note I didn't even mention big data, analytics, or monitoring. [0] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [1] http://imgur.com/QXLL0XJ http://imgur.com/QXLL0XJ
theli0nheart 9y ago
I build MVPs for a living, and I still use vanilla JS and jQuery. I can recruit engineers easily, and my clients really don't care. The technology really doesn't matter. Once the apps move past MVP stage, I let the team decide on what framework they want to build it with. It's generally hard to know what the "ideal" FE framework is until after you have something running. Each one has its own strengths and weaknesses. In short, you're fine. Don't worry about it. Keep building things in jQuery. It works, there's plenty of documentation, and everyone's familiar with it.
stephenboyd 9y ago
If jQuery and Backbone worked for you then, they'll still work for you now. The popular new libraries and tools are all things that solve problems, but you can wait to use them until you think they will help you.
eropple 9y ago
I just went from "never touching ES6 and not writing JavaScript for five years" to "shipping a React app" in about two weeks. This stuff is not actually all that complicated. I'd start here: https://github.com/verekia/js-stack-from-scratch https://github.com/verekia/js-stack-from-scratch And then, once you've internalized what's going on here, break out create-react-app and just get to work.

pavlov 9y ago

The way to step back into it is to ignore the library froth, pick something that looks understandable from the principles you already know, and build something useful. Many people spend X hours a day obsessing about whether css-turd-polish.io is better than Sassy.js v4. If you spend those hours working on something productive, you're automatically ahead. The framework churn is increasingly a perpetual motion machine for conference talks. Don't go to conferences and you won't feel like you're missing anything.

derefr 9y ago
What if I want to hire frontend devs for a green-field project—what tech-stack experience do I look for?
- davedx 9y ago
  My approach with hiring is to try and find solid JavaScript programmers foremost. People with experience in the tech we use, or people with a lot of experience with other languages are nice to haves. Anyone who has a solid grasp of (modern) JavaScript will be fine with any front end tech stack.
  - derefr 9y ago
    Well, I mean, sure... but, having hired all these random "solid JavaScript programmers", what do I tell them to use and/or learn? To do useful work, they all need to be using the same thing—so... how do I figure out what should be the standard for a project, if there's nothing forcing any particular option?
    - sprafa 9y ago
      You can let them decide? Then follow agile principles to make sure they are delivering prototypes/features. Ideally you would get a grasp of what they need to do and some idea on how they need to do it. If you don't then you should hire someone that does, or who you can feel almost absolute confidence in. Then let them do the hiring. Just my two cents.
- zeta0134 9y ago
  Don't bother with specific tech stacks, because as mentioned, the churn rate is really high. Instead, hire good problem solvers who you can tell from their interviews will be able to choose a framework that works well for your new projects, or adapt to the framework you've chosen yourself for your existing ones. Understand that good programmers are kind of hard to find, but okay programmers with experience in XYZ stack are not. Why? Because any reasonably competent programmer can become familiar with a new framework or library in about a week or two. Being able to separate the signal from the noise, and architecture an application well within that framework? That's what you're looking for. The tools themselves aren't that important.
  - inimino 9y ago
    Of course, to follow this advice you have to be able to identify problem-solving ability, which is hard and why most hiring managers fall back on buzzword bingo--to say nothing of HR departments.
- TheAceOfHearts 9y ago
  I'd strongly suggest using Webpack to build any new serious frontend projects. It's incredibly powerful and flexible enough to be able to adapt to any changes in the ecosystem without having to throw stuff away. As a data point, I know a large projects that slowly migrated away from AMD, favoring CommonJS, and later ES modules. Since ES modules are part of the standard, it makes sense to converge. This was achieved with comparably minimal effort, without throwing code away, and all while enabling newer code to be written in the modern style. React is an incredibly safe bet as well. Facebook is so heavily invested in it that they have multiple engineers working on it full-time. Furthermore, since they actually use the framework, any breaking changes are required to have a clear migration path. They published a blog post [0] explaining their strategy for how they intend to handle version transitions, which I consider incredibly developer-friendly. Look at angular 1.x for an example of a horribly handled transition. [0] https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html https://facebook.github.io/react/blog/2016/02/19/new-version...
TheAceOfHearts 9y ago
You can keep track of big new tools and libraries without hopping on every bandwagon, which I guess is why I haven't felt JS fatigue. I'd argue just knowing certain tools even exist can help you do a better job and enable you to make more informed decisions as you tackle new problems. Just create a mental index, in case you later find yourself having to tackle a problem for with the tool is a good fit.

rebootthesystem 9y ago

Chasing technology is a huge mistake. Your end users, your clients, where the money comes from, could not care less if you are coding your website in Visual Basic (is that even possible?). Nope. They are after a solution to a problem. That is ALL they care about. Nothing else. Do not waste your time with this ever-repeating nonsense of chasing the shinny objects. That doesn't mean you stop learning. It does mean you inject a slow low pass filter in your life and don't react to every little movement in technology. You can learn about them while realizing your end users don't care and, in general terms, these technologies have no material advantages in delivering what customers are after. Engineers are not business people. Do no follow what someone with no business experience says because you'll find yourself jumping from tech to tech and no servicing your customers.

ethbro 9y ago
* If your client is non-technical, endeavor to somewhat describe the trade-off in using simpler technologies, if there are any that matter to them

vmware513 9y ago

Actually, you can learn modern frontend framework quickly from free tutorials, and you are up-to-date again, for example: http://yoember.com http://yoember.com

TheAceOfHearts 9y ago

I think it depends a lot on the kind of app you're building. Many of these tools start to shine for larger and more complicated projects that are being developed by many engineers over a long period of time. The web community is pretty large, so there's constant competition over different ideas and approaches. For most tools and libraries, I usually read through the docs when I hear about it and create a mental index that it exists, in case I ever need to solve a problem for which it would be a good fit. I'll note that plenty of these tools and libraries have been around longer than two years. If I remember correctly, Webpack came out in 2012 and React in 2013. I point out these two projects because they caused a fundamental shift in the way I approached web development, and neither is looking like it'll be going away soon. My suggestion would be to try out create-react-app [0]. There's still some stumbling points, but it does a good job of showcases the general direction many people in the webdev development community have moved towards. It hides all the build stuff into a black box. As you become more comfortable with the ecosystem and the need arises, you can eject and access all these tools directly. I totally agree that the webdev community should strive to do a better job at explaining the purpose of all these tools, but I don't think this problem is limited to them in the slightest. In fact, I can assure you I feel the exact same way you do when I look at many of these cloud / devops / server / backend tools. Do I want chef, puppet, or ansible? Oh, but you need better dynamic configuration management and service discovery, so be sure to pick up consul or etcd. Remember KVM, jails, and vagrant? All those are dead, containers are the new hotness, say hello to Docker. If you wanna be web scale you'll really need Kubernetes, cuz you wanna be like Google, right? But also check out Deis or Flynn, so you can build your own cloud in the cloud. There's a few other HashiCorp products with nice-looking sites, but I don't even understand the problems they solve well enough to even try poking fun at em. Let's not forget databases! Remember MySQL? It cloned itself and changed its name to Maria. But it turns out that it totally sucks and everyone is using PostgreSQL. Those won't work if you're trying to be web scale, turns out RDBMs are a thing of the past, the future is all about NoSQL. Try out Mongo, it's so easy to use! But be sure to also check out Cassandra, CouchDB, and RethinkDB. They're all NoSQL, but different, but still the same [1]. If you're really set on being like Google, then CockroachDB is the only serious choice anyway. Is anything going slow? You'll have to add some caching with redis or memcached. It's time to jump on the real-time train too, so you'll need some pubsub magic, luckily you can use kafka, rabbitmq, or redis. I'll stop now, since I think this is already way too long. However, I'll note I didn't even mention big data, analytics, or monitoring. [0] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [1] http://imgur.com/QXLL0XJ http://imgur.com/QXLL0XJ

theli0nheart 9y ago

I build MVPs for a living, and I still use vanilla JS and jQuery. I can recruit engineers easily, and my clients really don't care. The technology really doesn't matter. Once the apps move past MVP stage, I let the team decide on what framework they want to build it with. It's generally hard to know what the "ideal" FE framework is until after you have something running. Each one has its own strengths and weaknesses. In short, you're fine. Don't worry about it. Keep building things in jQuery. It works, there's plenty of documentation, and everyone's familiar with it.

stephenboyd 9y ago

If jQuery and Backbone worked for you then, they'll still work for you now. The popular new libraries and tools are all things that solve problems, but you can wait to use them until you think they will help you.

eropple 9y ago

I just went from "never touching ES6 and not writing JavaScript for five years" to "shipping a React app" in about two weeks. This stuff is not actually all that complicated. I'd start here: https://github.com/verekia/js-stack-from-scratch https://github.com/verekia/js-stack-from-scratch And then, once you've internalized what's going on here, break out create-react-app and just get to work.