Hacker News Reader

Comment by adlpz | Hacker News Reader

These examples are very reassuring to me. Sometimes, after a long day of fighting whatever trendy JS framework my current project uses, I may be tempted to advocate for a "back to the basics" approach with vanilla JS or even jQuery.

Anything after the temperature converter example makes it painfully obvious that it would not be a pleasant experience.

View on HN

The whole environment around JS frameworks had got to be especially intimidating for new developers. There's this false sense that you can't do "anything" these days in JS without a package manager, a build pipeline, a local server, a view library, a state management library, etc...

Meanwhile all the functionality of vanilla JS is still there, and the language and runtime are arguably much better than they ever were.

It's worth experimenting with these things every now and then on your own, even if you don't have a simple setup at work.

nodemon was my build tool.

Yep,it has become popularity contest for frameworks, and in the end they make developing even harder.

That's simply not true. You know better than thousands of developers who are using React or Vue in their projects, and they are just making their life harder?

I don't know what the "correct" answer is (and highly doubt there is a one size fits all answer). But there are thousands of developers not using them as well, so this argument is not valid.

So let's look at the data: According to stateofjs survey: 100% of JS developers know what React is, 80% are using it, 88% are satisfied. There is no "one size fits all" but saying that

> they make developing even harder

is saying

> These people are stupid and make their jobs more difficult

I'm not saying that majority is always right, but I think these devs might be onto something. I'm also trying to show how idiotic is the logic of tonis2 who throws such a slogan around without giving a single argument WHY these frameworks make development more difficult.

Alas, the common thing I see this days is devs fighting infrastructure instead of developing product.

> intimidating for new developers

Or in my case seasoned developers who have been away from that front (concentrating on database/infrastructure/security matters) for some time and might like to catch up a bit. I can still do things the vanilla (or jquery/similar) way but that might not be ideal, but beyond that the sea of choice is daunting to think about navigating.

Or maybe I've been away so long I should consider myself to be a newbie in a new environment, instead of just a bit out-of-date in one that has moved forwards rapidly in my absence!

Not arguing your point, because I believe its really valid.

However, the issue is, any moderately complex application will soon develop its own in-house Framework. Its the natural progression, very soon the head Dev will say "lets create a library to handle all our form validation requirements....lets create library separate UI from business logic...etc"

That's the real "slippery slope" from a management perspective.

Do we wind up developing our own in-house Framework which our current developers are very productive in (but new hires don't understand)? Or do we bite the bullet and opt for an already existing Framework that already has a dev community? I'm not suggesting its an easy answer as there are pros/cons to each. In the end for 90% of cases I think starting with an existing Framework (or at least "Framework-lite") is best approach.

It works well until you need to manage many states in one page. Even with knockout js, when an application become a little complex, it become hard to develop.

Reply on news.ycombinator.com