5 ms·

I think what this doesn't address is why fatigue is more of a problem is JS than in other languages. You rarely hear about Ruby fatigue, Python fatigue, etc. Is

by vlunkr 9y ago

I think what this doesn't address is why fatigue is more of a problem is JS than in other languages. You rarely hear about Ruby fatigue, Python fatigue, etc. Is the insane turnover rate of JS tools really essential to writing great software? I finally started to feel the fatigue with the React and Webpack takeover. I was really into them at first, but I realized that while I was constantly learning new tools, my software wasn't really improving, in fact all the constant changes with upgrading tools was causing a lot of headaches and bugs. And at the end of the day, a good dev can create the same app with react and webpack, or coffeescript and ember, or plain old JS and jquery. In short, JS fatigue game me premature "get off my lawn" syndrome and I actively avoid front end work now.

white-flame 9y ago
I'm quite happily and non-fatiguely doing a lot of JS front-end development for my own projects... without any frameworks except a bit of jQuery for DOM manipulation. Now, my needs don't quite fit the common interface models anyway, and as I'm doing stuff for technical users, I don't bother with any browser backwards-compatibility. But as far as managing data, behavior, socket communications, and CSS-styled DOM manipulation goes, I have zero desire to enter the morass of heavyweight framework churn. JavaScript is a pretty reasonable language that you can be quite productive with even in the browser for front-end tasks.
- mythrwy 9y ago
  It's all fun and games until that little bit of jQuery turns into a lot of jQuery. Sometimes you don't have much of a say into how big things eventually get and sometimes things get a whole lot bigger than you initially imagined. Good organization helps but still, as a jQuery fan myself who has gone through this a few times recently I've started to realize there may just be a better way. Particularly throwing more than one dev in the mix. Going through someone else's tangled box of electrical cords is no fun at all.
  - vlunkr 9y ago
    I hear this sentiment a lot: that jquery projects inevitably become spaghetti, and I can relate, because I've seen it happen, but I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely. At a certain size you should look into frameworks, but it's not always necessary.
    - unclebucknasty 9y ago
      >I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely >At a certain size you should look into frameworks I hear this a lot--the idea that jQuery or vanilla JS can work for smaller projects if well-organized, but larger projects require frameworks--however, I honestly have no idea how it makes sense. Seems to me that if you have a good pattern and foundation, then it should scale up to larger projects; else, what we're really saying is that it's still a mess, but a small mess that's manageable because the project is small and there isn't that much code. But, the framework dogma these days is such that we dare not even suggest undertaking a large project without committing to an "acceptable" framework du juor. I say this as someone who sees some value in frameworks, but also doesn't believe that the ROI is always there, or that it is absolutely necessary to use a framework on even larger projects. After all, frameworks aren't magical. They are just code. More specifically, they are reusable libraries attached to pattern enforcement. Why can't I choose a couple of libs, come up with reusable code, and implement my own patterns without all of the added cruft, opinion, politics, and risk of jumping on someone else's framework? Plus, many frameworks have just gotten way too big and complex, and we too infrequently emphasize the cost of using a framework vs. simply championinig the benefits. I want one-way data binding, but I have to change languages, introduce copious build steps, and generally follow all of your opinionated patterns, introducing layers of cruft and structure? Then, after all of this, you may change course with no upgrade path or the framework may simply become unpopular? No thanks.
      - watwut 9y ago
        Scalling up means more people,new people, and people with different opinions about what is good. It is easier when framework itself encourages common patterns. Own solution tend to be tailored to first use case and work nor as well in general.
pjmlp 9y ago
> I actively avoid front end work now. My solution was to move back to native front end. Still do web, but try to avoid it.
- rpeden 9y ago
  I think a lot of people find developing applications using things like WPF and QT (and probably JavaFX, too) to be more enjoyable than the modern web stack. But those same people also probably worry when they see that a huge percentage of job postings involve front-end web development. The sense I get,though, is that while there are many web-focused jobs available there's also a ton of competition for those jobs. Whereas with native front end development, there's less demand but also far fewer developers qualified for/interested in the work.
  - pjmlp 9y ago
    I don't worry that much, because iOS and Android are also native for any application that actually cares about UI/UX, so there are lots of opportunities, specially for applications that aren't yet another CRUD app.
  - mike_hearn 9y ago
    It can be misleading too. Desktop frameworks date from a time when there was no distinction between backend and frontend developers. There were just software developers, and they were expected to be able to write algorithms and UI and whatever else was necessary to ship the app. This led to a lot of ugly UI, but also pretty tight low latency UI (compared to the web). It also impacted job descriptions and the way people think about hiring. I am the lead developer at a firm with about 25 software developers, we do JavaFX GUIs when we can. We do not mention this in job specs. We do not hire for "frontend" guys specifically. Writing JavaFX code (or WPF or Qt) is just too easy to bother doing a specific candidate search for them - any competent dev can learn these frameworks quickly (and they do). The primary reason to search for UI specific skills in the desktop world is to find people who truly understand usability and graphics design, which is a separate skillset to what the modern kids call "frontend development". There are lots of web UIs out there that look superficially attractive as they just imported a stock CSS theme but which are actually confusing, nonsensical or simply can't scale to the addition of more features. UX design is as much about figuring out your user stories and workflows as it is making nice graphics. In the case where developers need to do their own UI design, I prefer to just train them and push them to consider appearances when doing the work. It's easier to train someone how to make an attractive-enough UI than to train them in great software engineering. So ideally you'd have two specialists tag-teaming but when that isn't possible, desktop UI + some training is the way to go.
eksemplar 9y ago
You can frankly do front end the way you've always done. We still use razor with a little jquery and a lot of our older projects still use asp forms. We've used angular on a few projects, but it took time to educate our staff and their time to market as well as the required support increased significantly, and then angular 2 arrived... Honestly it seems like the JS exists to sell a lot of education and a lot of books. Maybe we did it wrong, but as a clean business case angular was a terrible for us.
wruza 9y ago
I think JS has this problem because of constantly high inflow of new developers who easily get on new boats. They cannot differentiate between old and new tools (except for hype and cv-driveness), and new tools don't kill their productivity as much. Personally I never made it into frontend because learning basics makes me sick of html/css/js trinity, and learning advanced tools is a neverending war. Advanced js programmers feel that and try to create more tools, shorting the circuit. (Otoh, programming has changed since our youth time. Back then we programmed for one local, now we do it for thousand remotes. Latency penalties turned upside down literally, storage is faster than SIMM, ui is slower than FDD.) Since web 1.98a* we stopped to look at program as a whole and separated it into frontend and backend. That was a key point that allowed so much divergence and frustration. It may sound crazy, but we need new, more low-level browser (don't even call it browser, it is a network layer) that could seamlessly connect single heterogenous app on two network endpoints, since no one really cares about underlying protocols anymore. Leave www rot in browser and make internet apps great again. All good tools from '95 are still here. * you cannot call something 2.0 until it has at most 2-3 generic and mature ways to do everything.
- flukus 9y ago
  > It may sound crazy, but we need new, more low-level browser (don't even call it browser, it is a network layer) that could seamlessly connect single heterogenous app on two network endpoints XWindows (https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System)?
  - digi_owl 9y ago
    Everything old is new again... https://en.wikipedia.org/wiki/Time-sharing#Time-sharing_business https://en.wikipedia.org/wiki/Time-sharing#Time-sharing_busi...
- icebraining 9y ago
  Why do we need new stuff? What's wrong with the existing ways of connecting processes over the network?
lolive 9y ago
Javascript community has evolved in just a few years from script kiddies to adult architects. Frankly, JS is now much more sophisticated, and definitely requires code design skills. I will probably have to deal in the following years with a Typescript/Purescript + IntelliJ envrionment. And that makes me much happier than having to deal with JS spaghetti code from the Web2.0 era.
zemanel 9y ago
and let's not even talk about NPM which is apparently dead and "you should use yarn" https://github.com/electron-userland/electron-builder/issues/1344 https://github.com/electron-userland/electron-builder/issues...

by vlunkr 9y ago

white-flame 9y ago

I'm quite happily and non-fatiguely doing a lot of JS front-end development for my own projects... without any frameworks except a bit of jQuery for DOM manipulation. Now, my needs don't quite fit the common interface models anyway, and as I'm doing stuff for technical users, I don't bother with any browser backwards-compatibility. But as far as managing data, behavior, socket communications, and CSS-styled DOM manipulation goes, I have zero desire to enter the morass of heavyweight framework churn. JavaScript is a pretty reasonable language that you can be quite productive with even in the browser for front-end tasks.

mythrwy 9y ago
It's all fun and games until that little bit of jQuery turns into a lot of jQuery. Sometimes you don't have much of a say into how big things eventually get and sometimes things get a whole lot bigger than you initially imagined. Good organization helps but still, as a jQuery fan myself who has gone through this a few times recently I've started to realize there may just be a better way. Particularly throwing more than one dev in the mix. Going through someone else's tangled box of electrical cords is no fun at all.
- vlunkr 9y ago
  I hear this sentiment a lot: that jquery projects inevitably become spaghetti, and I can relate, because I've seen it happen, but I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely. At a certain size you should look into frameworks, but it's not always necessary.
  - unclebucknasty 9y ago
    >I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely >At a certain size you should look into frameworks I hear this a lot--the idea that jQuery or vanilla JS can work for smaller projects if well-organized, but larger projects require frameworks--however, I honestly have no idea how it makes sense. Seems to me that if you have a good pattern and foundation, then it should scale up to larger projects; else, what we're really saying is that it's still a mess, but a small mess that's manageable because the project is small and there isn't that much code. But, the framework dogma these days is such that we dare not even suggest undertaking a large project without committing to an "acceptable" framework du juor. I say this as someone who sees some value in frameworks, but also doesn't believe that the ROI is always there, or that it is absolutely necessary to use a framework on even larger projects. After all, frameworks aren't magical. They are just code. More specifically, they are reusable libraries attached to pattern enforcement. Why can't I choose a couple of libs, come up with reusable code, and implement my own patterns without all of the added cruft, opinion, politics, and risk of jumping on someone else's framework? Plus, many frameworks have just gotten way too big and complex, and we too infrequently emphasize the cost of using a framework vs. simply championinig the benefits. I want one-way data binding, but I have to change languages, introduce copious build steps, and generally follow all of your opinionated patterns, introducing layers of cruft and structure? Then, after all of this, you may change course with no upgrade path or the framework may simply become unpopular? No thanks.
    - watwut 9y ago
      Scalling up means more people,new people, and people with different opinions about what is good. It is easier when framework itself encourages common patterns. Own solution tend to be tailored to first use case and work nor as well in general.

pjmlp 9y ago

> I actively avoid front end work now. My solution was to move back to native front end. Still do web, but try to avoid it.

rpeden 9y ago
I think a lot of people find developing applications using things like WPF and QT (and probably JavaFX, too) to be more enjoyable than the modern web stack. But those same people also probably worry when they see that a huge percentage of job postings involve front-end web development. The sense I get,though, is that while there are many web-focused jobs available there's also a ton of competition for those jobs. Whereas with native front end development, there's less demand but also far fewer developers qualified for/interested in the work.
- pjmlp 9y ago
  I don't worry that much, because iOS and Android are also native for any application that actually cares about UI/UX, so there are lots of opportunities, specially for applications that aren't yet another CRUD app.
- mike_hearn 9y ago
  It can be misleading too. Desktop frameworks date from a time when there was no distinction between backend and frontend developers. There were just software developers, and they were expected to be able to write algorithms and UI and whatever else was necessary to ship the app. This led to a lot of ugly UI, but also pretty tight low latency UI (compared to the web). It also impacted job descriptions and the way people think about hiring. I am the lead developer at a firm with about 25 software developers, we do JavaFX GUIs when we can. We do not mention this in job specs. We do not hire for "frontend" guys specifically. Writing JavaFX code (or WPF or Qt) is just too easy to bother doing a specific candidate search for them - any competent dev can learn these frameworks quickly (and they do). The primary reason to search for UI specific skills in the desktop world is to find people who truly understand usability and graphics design, which is a separate skillset to what the modern kids call "frontend development". There are lots of web UIs out there that look superficially attractive as they just imported a stock CSS theme but which are actually confusing, nonsensical or simply can't scale to the addition of more features. UX design is as much about figuring out your user stories and workflows as it is making nice graphics. In the case where developers need to do their own UI design, I prefer to just train them and push them to consider appearances when doing the work. It's easier to train someone how to make an attractive-enough UI than to train them in great software engineering. So ideally you'd have two specialists tag-teaming but when that isn't possible, desktop UI + some training is the way to go.

eksemplar 9y ago

You can frankly do front end the way you've always done. We still use razor with a little jquery and a lot of our older projects still use asp forms. We've used angular on a few projects, but it took time to educate our staff and their time to market as well as the required support increased significantly, and then angular 2 arrived... Honestly it seems like the JS exists to sell a lot of education and a lot of books. Maybe we did it wrong, but as a clean business case angular was a terrible for us.

wruza 9y ago

I think JS has this problem because of constantly high inflow of new developers who easily get on new boats. They cannot differentiate between old and new tools (except for hype and cv-driveness), and new tools don't kill their productivity as much. Personally I never made it into frontend because learning basics makes me sick of html/css/js trinity, and learning advanced tools is a neverending war. Advanced js programmers feel that and try to create more tools, shorting the circuit. (Otoh, programming has changed since our youth time. Back then we programmed for one local, now we do it for thousand remotes. Latency penalties turned upside down literally, storage is faster than SIMM, ui is slower than FDD.) Since web 1.98a* we stopped to look at program as a whole and separated it into frontend and backend. That was a key point that allowed so much divergence and frustration. It may sound crazy, but we need new, more low-level browser (don't even call it browser, it is a network layer) that could seamlessly connect single heterogenous app on two network endpoints, since no one really cares about underlying protocols anymore. Leave www rot in browser and make internet apps great again. All good tools from '95 are still here. * you cannot call something 2.0 until it has at most 2-3 generic and mature ways to do everything.

flukus 9y ago
> It may sound crazy, but we need new, more low-level browser (don't even call it browser, it is a network layer) that could seamlessly connect single heterogenous app on two network endpoints XWindows (https://en.wikipedia.org/wiki/X_Window_System https://en.wikipedia.org/wiki/X_Window_System)?
- digi_owl 9y ago
  Everything old is new again... https://en.wikipedia.org/wiki/Time-sharing#Time-sharing_business https://en.wikipedia.org/wiki/Time-sharing#Time-sharing_busi...
icebraining 9y ago
Why do we need new stuff? What's wrong with the existing ways of connecting processes over the network?

lolive 9y ago

Javascript community has evolved in just a few years from script kiddies to adult architects. Frankly, JS is now much more sophisticated, and definitely requires code design skills. I will probably have to deal in the following years with a Typescript/Purescript + IntelliJ envrionment. And that makes me much happier than having to deal with JS spaghetti code from the Web2.0 era.

zemanel 9y ago

and let's not even talk about NPM which is apparently dead and "you should use yarn" https://github.com/electron-userland/electron-builder/issues/1344 https://github.com/electron-userland/electron-builder/issues...