4 ms·

Or in other words, this is piling complexity on top of complexity on top of complexity, on top of various abstractions.

jerf 4y ago
I think one of the reasons I like working on the backend more is that every once in a while, you get to do a clean sweep and throw away layers of abstraction. You can work on some app with Ruby on Rails and then load librarys on top of that and then load libraries on top of those that monkeypatch the original libraries... but nothing stops you from grabbing one particular critical API call and reimplementing it in a raw http.Handler in Go that spews simple SQL straight to your DB, sweeping away half-a-dozen layers of abstraction in one fell swoop, or whatever similar story you like to tell. The backend's responsibility ends with delivering the correct bytes in response to some HTTP message and it doesn't matter how you get there. The frontend... well... the equivalent is technically there, if you are willing and able to work with the grain of the browser. When I'm left to my own devices I can successfully front-end a lot of things with just some basic Javascript and some simple HTML. But it doesn't tend to scale, and it really doesn't scale if you've got some manager who loves that prototype of the calendar selector you did (that was just the browser widget), but really needs these three bullet points that are impossible to do with the native widget so now you're pulling in a library to provide a framework that provides the backbone of the actual widget that does the job and there's simply no other practical alternative because, what, are you going to spend six weeks implementing it yourself instead? No. Of course not. It's not that the front end never drops a layer of abstraction. jQuery was pretty successfully dropped, to cite one specific example. But you don't ever get that clean sweep, because that's just... too clean a sweep to satisfy any manager or designer.
- zerocrates 4y ago
  I think the basic issue is that we're neither implementing new widespread patterns in the browser (new widgets, elements, etc.) nor really making it so we provide lower-level building blocks for interaction. Where we did add elements (like the calendar for example) they're so broadly specified that the browsers disagree on them so much you'll find yourself hard-pressed to actually use them. I think type=email is the only "new" element that is uncontroversially useful. You mostly have the "free" decades-old elements, and when you step a toe beyond them you're incurring a huge amount of work to try to emulate what the browser was giving you, or probably a library or framework to do it. On the very simplest end, I'm still baffled that there's no combobox element. `datalist` is kind of a mess and isn't quite the same.

jerf 4y ago

I think one of the reasons I like working on the backend more is that every once in a while, you get to do a clean sweep and throw away layers of abstraction. You can work on some app with Ruby on Rails and then load librarys on top of that and then load libraries on top of those that monkeypatch the original libraries... but nothing stops you from grabbing one particular critical API call and reimplementing it in a raw http.Handler in Go that spews simple SQL straight to your DB, sweeping away half-a-dozen layers of abstraction in one fell swoop, or whatever similar story you like to tell. The backend's responsibility ends with delivering the correct bytes in response to some HTTP message and it doesn't matter how you get there. The frontend... well... the equivalent is technically there, if you are willing and able to work with the grain of the browser. When I'm left to my own devices I can successfully front-end a lot of things with just some basic Javascript and some simple HTML. But it doesn't tend to scale, and it really doesn't scale if you've got some manager who loves that prototype of the calendar selector you did (that was just the browser widget), but really needs these three bullet points that are impossible to do with the native widget so now you're pulling in a library to provide a framework that provides the backbone of the actual widget that does the job and there's simply no other practical alternative because, what, are you going to spend six weeks implementing it yourself instead? No. Of course not. It's not that the front end never drops a layer of abstraction. jQuery was pretty successfully dropped, to cite one specific example. But you don't ever get that clean sweep, because that's just... too clean a sweep to satisfy any manager or designer.

zerocrates 4y ago
I think the basic issue is that we're neither implementing new widespread patterns in the browser (new widgets, elements, etc.) nor really making it so we provide lower-level building blocks for interaction. Where we did add elements (like the calendar for example) they're so broadly specified that the browsers disagree on them so much you'll find yourself hard-pressed to actually use them. I think type=email is the only "new" element that is uncontroversially useful. You mostly have the "free" decades-old elements, and when you step a toe beyond them you're incurring a huge amount of work to try to emulate what the browser was giving you, or probably a library or framework to do it. On the very simplest end, I'm still baffled that there's no combobox element. `datalist` is kind of a mess and isn't quite the same.