Hacker News Reader

Comment by phpisatrash | Hacker News Reader

> 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.

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.

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.

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?

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.

I've yet to see a single professional software company use these eztra layers. Though there are no doubt some most people are still using React, Vue or Angular directly.

Here are a few software companies moving to next.js.

https://nextjs.org/case-studies/hulu

https://nextjs.org/showcase/uber

https://eng.lyft.com/changing-lanes-how-lyft-is-migrating-10...

Thw humungous auto-geberated boilerplates are rude goldberg machines. But you don't need those at all. A simple webpack config (including setting up babel, typescript, etc) is less than 100 lines (not nothing, but comparable to build scripts in other langauges).

It's worth noting that there is some inherent complexity in the web platform due to the fact that you are generally targetting multiple platforms. Server side code has it easy here (and indeed Node.js generally needs little in the way of build process)

Regarding error with native NPM dependencies (usually when switching node versionw, or switching between macOS node and linux node in docker): this can almost always be solved witha simple `npm rebuild` once when you change node version.

After all the shebang out comes an html with tables instead of divs.

divs + css in yet another file, you mean. Tables at least do something in and of themselves; divs do not.

1999 called, it wants it's html structure back. lolz!

<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...

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.

Come on. Even if you dispise the js world, plenty of examples of well written JavaScript frameworks and successful end user products.

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?

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.

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.

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.

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.

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".

Genius

Soon it may be Svelte for me as it simplifies the React data model for me a lot... But there goes all the ecosystem again for React/Angular/Vue libs and docs. Then we repeat until someone figures out a better way to develop on the web (aka whats after Svelte?).

I'm hoping https://hotwire.dev/ solves some of my issues, I hope to see it picked up in SpringBoot/Quarkus community more.

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

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

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.

Reply on news.ycombinator.com