> Non-JS developers mystified and irritated at a bunch of practices they've never really internalised

My current explanation goes something like this:

"I'm a smart guy. Front end development looks simple. If I find it hard to do, that must be the fault of javascript somehow"

▲

abustamam 4 days ago | parent | next [-]

I started my career in FE and still consider myself a FE dev despite technically being a full stack dev.

Sometimes I'd be working with my team on something and they'd be like "why is this needed?" and I'm like "because javascript" or "because react."

While I agree with your sentiment that FE dev is certainly not simple, JS and front end architecture ad a whole does have its faults. That's why highly skilled FE devs who can build scalable, beautiful FE apps (whether using SPA or SSR) can be highly paid.

▲

dataflow 4 days ago | parent | prev [-]

Note those are not mutually exclusive. It's entirely coherent to believe you find a tool hard to use for reasons relating to the tool itself, and that the task you're trying to accomplish is also difficult independently of that.

Analogy: imagine trying to give a good presentation with a horrible text-to-speech (or translation) system. Just because good presentations are hard that doesn't mean you don't get to complain about the program being terrible.

▲

wredcoll 4 days ago | parent [-]

Yes, but now you're getting into "there are two types of languages, the ones people complain about and the ones nobody uses".

There are obviously flaws and issues and annoyances in js world, but a lot of those come from having to solve much harder problems (compared to say, do a sql query and turn the results into json).

▲

vanviegen 4 days ago | parent [-]

I'll bite. In essence a user interface just presents the data it got from the server in some nice looking shape, and sends any edits and button presses back. Should be simple, right?

▲

wredcoll 3 days ago | parent | next [-]

The "Just" is doing a lot of heavy lifting there.

Think about the presenting data part of it. Perhaps you have a table of data, prices of tickets or some such. You could literally just wrap each item in a <td> tag and each row in a <tr> tag and that would indeed be easy.

But people generally want and expect more. How about color coding the rows to make them easier to scan left to right or sorting the table by each column or paginating through more data than can easily displayed on one screen or maybe you're doing "infinite scroll" instead.

None of these things are impossible of course, and people have done them so many times and in so many different ways that there are dozens of libraries you can use and hundreds of tutorials, but even so, compare that to the "select from table turn to json" equivalent.

The SQL can be more than a bit tricky, but aside from that, JSON is extremely well defined and specified, even without a library you can just read the specs and do it. Wrapping it in a HTTP response and returning it and so on is likewise very well specified and if you can read, you can follow the instructions on how to do it.

Creating a UI that works the way a user wants to is the opposite of all that.

Of course, one of the major differences here is that at any point you can just stop improving the UI. Maybe you stop after wrapping it in the table html. The UI will certainly work, for a very specific definition of work. JSON is considerably more boolean. It either is a valid JSON document or it isn't. You can ask a computer to check for you. You can't ask a computer to check if your users enjoy using your table.

	▲	hasanhaja 3 days ago \| parent [-]
		How does something like React help with any of the trickier UX problems you're describing?

▲

3 days ago | parent | prev [-]

[deleted]