Hacker News Reader

Comment by abraxas | Hacker News Reader

Interesting. As a developer who's done no front end work since the nineties and has had little appetite for getting back into it (after having seen what modern front end devs seem to contend with) I surmise that all those crap.js frameworks of the month don't do a whole lot of useful stuf after all.

I suspected as much but was always too timid to speak up when I observed how much noise and fury in the office produced so little UI.

View on HN

I always find it interesting that the people who unabashedly admit they have minimal front-end experience usually have the strongest condemnation of the current tools.

Don’t worry. People with a lot of front-end experience, in this case me, also condemn the current tools.

20+ years of web experience, and the current tools are mostly trash.

Can I ask what sort of front-end frameworks/tools you use that you also condemn?

Most of them are merely abstraction layers for capabilities the browsers already provide. Rarely do they offer anything more. The big selling point is that they help organize the logic in a declarative way or automate a bunch of tiresome tasks that wouldn’t be there in the first place had you not used a mountain of tooling.

There are only 2 APIs in the browser: DOM and the web APIs. As far as writing cohesive logic that does wonderful things that’s on you. Most JS developers would rather it not be on them and instead adopt an Invented Here Syndrome mentality. The fear of writing any original code is very real.

https://en.m.wikipedia.org/wiki/Invented_here

It's more understandable if you think about it the other way around: people who don't like the current front-end tools usually try to avoid contact with them. Which these days, mostly means not doing professional front-end development.

I'm a WPF dev. I wouldn't mind learning iOS / Android / QT or whatever heavy client framework and language.

But when I see the mess that front end web dev have to deal with, yes I'm very skeptical !

I've built UI's with Qt, Gtk, swing, VBA, Access, winforms, WPF, TK, html/css and more I can't remember and I stay away from front end webdev these days because the tools are such a tyre fire and way less productive than what we were using > 20 years ago.

I find the people that like most of the current tooling grew up with it, don't know any better and don't want to learn.

> Qt, Gtk, swing, VBA, Access, winforms, WPF, TK

These aren't web-native so I don't think the comparison is particularly salient. Building on the web is a business requirement, all the tools are to make that requirement manageable.

It depends.

You can do quite a fair bit with vanilla JS, HTML, and CSS.

Things get a little tricky when you start having to maintain a lot of state that multiple elements need to be aware of.

It's not impossible to do this with vanilla JS, but the mental model can be a bit difficult and this gets amplified across teams.

What crap.js frameworks do well is provide a contract for how state can be organized and how components should react/interact with the change in state. This scales well across teams as following a set of mutually agreed upon conventions produces more legible code instead of an entire team rolling their own code for everything.

Thanks for stating this so succinctly. This is a vanilla JS thread, but the "frameworks are crap" groupthink is also getting a bit out of hand. If you are building complex dashboards where multiple components are sharing and updating state, using a declarative framework like React or Vue and state management like Redux keeps things manageable as requirements change.

Isn't the DOM your true state anyway? Why does it have to be kept someplace else? I'm genuinely curious because I don't do any front end work.

When you start tracking state in the DOM, you start having to be very imperative on what gets updated as state changes.

For example, if you have a search application and you want to paginate results, you can get pretty far with vanilla js, but you have to evoke changes based on events which is hard to scale beyond one person rolling their own code.

This is a lot nicer with frameworks because you can be less explicit on which elements get updated and rather describe changes in state with elements "subscribing" to these state changes. Furthermore, these frameworks have conventions to follow that makes things consistent which is nice for teams.

I tend to use jQuery for things that require basic JS interactions, but when there are things that require very scoped JS state with a complex set of interactions, I will defer to Vue.js.

Reply on news.ycombinator.com