4 ms·

> without the difficulties of a JavaScript development stack. Yes. It's very difficult to write a full stack application using JavaScript. I cannot find tools

> without the difficulties of a JavaScript development stack. Yes. It's very difficult to write a full stack application using JavaScript. I cannot find tools or frameworks.

speedgoose 6y ago
I don't know whether it's sarcasm or not.
throwaway-42808 6y ago
The frameworks and tools aren't all that stable, reliable, or intentionally designed compared with what Java programmers might be used to. I don't fault anyone for trying to get off the bus.
- holoduke 6y ago
  Come on. Even if you dispise the js world, plenty of examples of well written JavaScript frameworks and successful end user products.
  - throwaway-42808 6y ago
    Sounds easy enough: Use the well written frameworks as needed, and you can make successful end products too. What would be your advice to someone seeking to do this? e.g. - is it simply a matter of intelligence, perseverance, attitude? - is there a technical or social practice you find helpful?
- forgetfulness 6y ago
  Is JS tooling less of a Rube Goldberg machine nowadays? I remember that the people I knew who got into it but not fully used to use these humongous auto-generated boilerplates that glued together webpack, gulp, babel, had build processes involving native dependencies that would fail with weird errors vaguely related to Node JS versions, and this all to develop in the frontend. Compare: Clojure. You have the project.clj file and put your dependencies there. The you do lein run or build a fat jar and run it like java -cp your.jar your_app.core. The end.
  - gdubya 6y ago
    Not really (any less). A couple of years ago we migrated a project from Spring + GWT to Spring + Vue. The Vue part is nicer, but everything around it feels messy. The team is primarily backend / java developers (we had a frontend expert at the time too), but we felt that the JS frontend part shouldn't be that hard to master. Maybe Vaadin would have been a better option after all?
  - dmingod666 6y ago
    After all the shebang out comes an html with tables instead of divs.
    - michaelcampbell 6y ago
      divs + css in yet another file, you mean. Tables at least do something in and of themselves; divs do not.
      - dmingod666 6y ago
        1999 called, it wants it's html structure back. lolz!
        michaelcampbell 6y ago
        <eye roll> For tables, tables are fine. The only thing worse than jumping on a new thing because it's new is completely abandoning something because it's not. And "lolz"? 2010 called...
  - yepthatsreality 6y ago
    No it’s even more so with the rise of framework frameworks like Next.JS and Cypress. These frameworks are just wrappers around other frameworks. JS will never escape this as its primary reason for existence was a glue layer between Browser and HTML/CSS.
    - nicoburns 6y ago
- isbvhodnvemrwvn 6y ago
  I don't see how using TeaVM, which is not stable at all, has very little activity (a handful of commits since summer) and is going to be extremely niche since most people don't have that weird aversion to modern JS tooling, is a solution.
pjmlp 6y ago
My last four projects, changed from Angular 6 and Ionide, just Angular 6, followed by Vue.js, now doing one with React. Who knows what the FE team will remember to come up on the next assignment.
- marktangotango 6y ago
  I used to work at a large F500 corp and managed a legacy app that used raw js/jquery on the front end. Every two years like clockwork we'd get a mandate that "all apps will now use X" where X was [ext-js, ember, angular]. As the person in charge of the app I ignored all those directives and saved myself a boatload of work. App is still using jquery today last I heard.
  - dmingod666 6y ago
    Genius
  - pwdisswordfish0 6y ago
    Why does everyone keep lumping jQuery in with vanilla JS, in exalted reverence, as if jQuery wasn't a massive source of bloat during its heyday? The practice of pulling in all of jQuery just to add an event listener for showing and hiding a div is _why_ web development looks the way it does today. Normalization of deviance is the vehicle, and jQuery was the payload. I come across stuff "only" using jQuery today, and every time, I end up ripping it out because it's totally unnecessary and often ends up being the source of breakage and logic errors. What's worse is that its APIs are awful, and it's impossible to debug in its blob form. The fix always ends up being to just get rid of it.
    - JAlexoid 6y ago
      That's not the point of the comment above. FYI: The point is that every year or two you get a new "revolutionary" framework. Unless you're working full time on FE - you're not going to be "in with the cool kids".
- bestinterest 6y ago
SamoyedFurFluff 6y ago
I don’t think this is the definition of difficult the author is using. I find JavaScript intimidating and difficult due to too many tools and frameworks. I cannot rely on any of their documentation, either on their site, or the peripheral collective experience of stack overflow, to be accurate to the actual thing I’m trying to use. This makes it difficult to me.
dexterdog 6y ago
Finding them is not the problem. Figuring out which one to use is.
SomeHacker44 6y ago
The obvious way to me for full stack JavaScript is to use JavaScript on the server with node.js and JavaScript on the client via a... Browser.

> without the difficulties of a JavaScript development stack. Yes. It's very difficult to write a full stack application using JavaScript. I cannot find tools or frameworks.

speedgoose 6y ago

I don't know whether it's sarcasm or not.

throwaway-42808 6y ago

The frameworks and tools aren't all that stable, reliable, or intentionally designed compared with what Java programmers might be used to. I don't fault anyone for trying to get off the bus.

holoduke 6y ago
Come on. Even if you dispise the js world, plenty of examples of well written JavaScript frameworks and successful end user products.
- throwaway-42808 6y ago
  Sounds easy enough: Use the well written frameworks as needed, and you can make successful end products too. What would be your advice to someone seeking to do this? e.g. - is it simply a matter of intelligence, perseverance, attitude? - is there a technical or social practice you find helpful?
forgetfulness 6y ago
Is JS tooling less of a Rube Goldberg machine nowadays? I remember that the people I knew who got into it but not fully used to use these humongous auto-generated boilerplates that glued together webpack, gulp, babel, had build processes involving native dependencies that would fail with weird errors vaguely related to Node JS versions, and this all to develop in the frontend. Compare: Clojure. You have the project.clj file and put your dependencies there. The you do lein run or build a fat jar and run it like java -cp your.jar your_app.core. The end.
- gdubya 6y ago
  Not really (any less). A couple of years ago we migrated a project from Spring + GWT to Spring + Vue. The Vue part is nicer, but everything around it feels messy. The team is primarily backend / java developers (we had a frontend expert at the time too), but we felt that the JS frontend part shouldn't be that hard to master. Maybe Vaadin would have been a better option after all?
- dmingod666 6y ago
  After all the shebang out comes an html with tables instead of divs.
  - michaelcampbell 6y ago
    divs + css in yet another file, you mean. Tables at least do something in and of themselves; divs do not.
    - dmingod666 6y ago
      1999 called, it wants it's html structure back. lolz!
      - michaelcampbell 6y ago
        <eye roll> For tables, tables are fine. The only thing worse than jumping on a new thing because it's new is completely abandoning something because it's not. And "lolz"? 2010 called...
- yepthatsreality 6y ago
  No it’s even more so with the rise of framework frameworks like Next.JS and Cypress. These frameworks are just wrappers around other frameworks. JS will never escape this as its primary reason for existence was a glue layer between Browser and HTML/CSS.
  - nicoburns 6y ago
isbvhodnvemrwvn 6y ago
I don't see how using TeaVM, which is not stable at all, has very little activity (a handful of commits since summer) and is going to be extremely niche since most people don't have that weird aversion to modern JS tooling, is a solution.

pjmlp 6y ago

My last four projects, changed from Angular 6 and Ionide, just Angular 6, followed by Vue.js, now doing one with React. Who knows what the FE team will remember to come up on the next assignment.

marktangotango 6y ago
I used to work at a large F500 corp and managed a legacy app that used raw js/jquery on the front end. Every two years like clockwork we'd get a mandate that "all apps will now use X" where X was [ext-js, ember, angular]. As the person in charge of the app I ignored all those directives and saved myself a boatload of work. App is still using jquery today last I heard.
- dmingod666 6y ago
  Genius
- pwdisswordfish0 6y ago
  Why does everyone keep lumping jQuery in with vanilla JS, in exalted reverence, as if jQuery wasn't a massive source of bloat during its heyday? The practice of pulling in all of jQuery just to add an event listener for showing and hiding a div is _why_ web development looks the way it does today. Normalization of deviance is the vehicle, and jQuery was the payload. I come across stuff "only" using jQuery today, and every time, I end up ripping it out because it's totally unnecessary and often ends up being the source of breakage and logic errors. What's worse is that its APIs are awful, and it's impossible to debug in its blob form. The fix always ends up being to just get rid of it.
  - JAlexoid 6y ago
    That's not the point of the comment above. FYI: The point is that every year or two you get a new "revolutionary" framework. Unless you're working full time on FE - you're not going to be "in with the cool kids".
bestinterest 6y ago

SamoyedFurFluff 6y ago

I don’t think this is the definition of difficult the author is using. I find JavaScript intimidating and difficult due to too many tools and frameworks. I cannot rely on any of their documentation, either on their site, or the peripheral collective experience of stack overflow, to be accurate to the actual thing I’m trying to use. This makes it difficult to me.

dexterdog 6y ago

Finding them is not the problem. Figuring out which one to use is.

SomeHacker44 6y ago

The obvious way to me for full stack JavaScript is to use JavaScript on the server with node.js and JavaScript on the client via a... Browser.