[smoochy]

I was reading your comment and thought of Jonathan Blow's talk. Without even clicking the link, let me guess, that's from Moscow's 2019 conference?

EDIT: yes, it is. He has a very important point there. I recently went on Twitch to see what young devs where coding. One (rather smart, I must say) young lady was creating a simple sign in/sign up page, but there's a twist: with React. Upon me asking, why wouldn't she just code it in plain HTML, she responded with a question: "but how would it connect to the API?". So there you go, ladies and gentlemen. I don't really know what to do about it, but I don't believe we're a bunch of old men yelling at a cloud (quite literally - AT A CLOUD), especially that I don't think we're that old.

[rolisz]

I had a similar experience with my sister in law who is getting her programming degree this month. When I asked her what was her final project and some details about it, she told me the entry point to her frontend was Angular. When asked how it was served and how it got to the browser, all i got was confused looks. When I showed her that the first thing that gets to the browser is an HTML file that then loads Angular and her application, her mind was blown.

[rco8786]

I had a similar experience with a family member. When I asked them how their keyboard strokes appeared on the screen, all I got was confused looks. When I showed them that the first thing that happens is a hardware interrupt, her mind was blown.

Seriously, it's okay that people don't know the ins and outs of every little detail. Abstractions are useful, until they're not. And then when they're not, you go figure out the level below.

Even the most advanced, most skilled front-end devs spend 99.99% of their time not caring that the browser loads an HTML page.

[Mordisquitos]

I think your analogy would be valid if the previous commenter had, for example, asked their sister-in-law how the browser interprets the JavaScript it receives, or how it builds the display from the DOM. Now that would be asking about irrelevant and unnecessary levels of detail which are best abstracted away. However, knowing that the process starts with the browser receiving HTML over HTTP is essential to understand what's going on, even if you know nothing about the details.

If I may, a truly similar experience regarding keyboards would be this:

I had a similar experience with a coworker. When I asked him how the code that he types appears on the IDE on his screen and not on that of any of our colleagues' screens, all I got was confused looks. When I showed him that his keyboard is wirelessly connected only to his computer, which runs the IDE, and his computer is then specifically connected to his own monitor via a cable, his mind was blown.

[rco8786]

It was just a random example, you can literally pick any level in any number of abstraction stacks that exist and make the same analogy.

Sometimes it becomes necessary to know how the level below works. That doesn’t mean it’s a requirement to be affective at the level above.

[Calavar]

> That doesn’t mean it’s a requirement to be affective at the level above.

Not necessarily, but it did have a material effect in the original example. A web developer drug in a complex, unnecessary framework because she didn't realize that HTML forms have the ability to submit post and get data natively.

To me that's like a civil engineer building a suspension bridge over a tiny creek because they never heard of an arch design.

[joshmanders]

> A web developer drug in a complex, unnecessary framework because she didn't realize that HTML forms have the ability to submit post and get data natively.

You're making a massive assumption that she didn't already need to use React and may have been confused at how she would make the two systems work together correctly.

[cmroanirgo]

Agree.

I would add that even good old, rock solid assembler isn't a straight entry point into controlling the CPU, but is now just an abstraction over µOPs. Abstractions surround us these days, and for each of us, we find differing levels of what's tolerable vs what should be known about the next layer below.

I'm personally (kinda) ok with not knowing too much about the sub-assembler processes that happen inside the literal black box called a CPU, but I know that for branch optimisation, it's important.

[Guvante]

I would categorize things as "does someone on the team need to know this":

* Why does a key appear on the screen when I push a button on my keyboard: no

* How is an HTTPS connection created: generally no

* How is the JavaScript library deployed: 100% yes

You might be able to throw something together that works without understanding that it is a JavaScript library with a bootstrap HTML page but if no one on your team understand that you will eventually need to find someone that does to solve a problem.

[Kalium]

> * How is an HTTPS connection created: generally no

I would think that people doing web development probably benefit from a working knowledge of DNS, TLS, and PKI. Without those, I would expect a lot of readily avoidable problems with HTTPS.

In general I advocate that software engineers should have a functional, if abstract, understanding of how computers work on various levels. They might not need a detailed understanding, but people often benefit in unexpected ways from understanding the systems they work with.

[xwolfi]

And one eventually figures it out anyway after one too many blank pages on an angular app :D

[nunez]

Not knowing how Angular bootstraps is how you get super huge SPAs that take forever to load on anything that is not a gigabit connection. Technical details matter.

[rco8786]

Genuinely do not follow this logic

[fmakunbound]

Man that is really sad, but I suspect these code in the cloud schemes will be targeted toward hordes of developers with such a superficial grasp on what’s happening.

[xwolfi]

That may say more about her than CS in general. I remember my very first encounter with Angular I made my seniors investigate how the hell double way binding could even work that way to have them confess to me that yes, we had 40k repeating functions running every n seconds to check variable states... for a static website whose double binding was just a first render time convenience. No wonder our mexican clients with shit phones couldnt load the site as well as our iphone-heavy Hong Kong ones. And it was my very first day on Angular.

How can she not be curious, Angular is so wrong and magical, it blows the mind to understand how it builds all that magic. Maybe your sister in law is the kind of persons who laughs at magic tricks ? I d be raging mad myself, I prefer to avoid them or Ill just be obsessed until I understand them

[flukus]

I like an SPA pile on as much as the next person, but I've seen similar ignorance from asp.net webform developers many years ago. Some of those were even "experienced" developers.

[NoGravitas]

To be fair, ASP.NET Web Forms obfuscated the relationship between your code and the HTTP request-response cycle almost as badly as an SPA framework.

[chrisweekly]

Yeah; knowing about the HTML form tag apparently qualifies you as a senior web dev.

[onion2k]

Considering how many web developers get that particular tag wrong I'm not sure that's actually as unreasonable as it first appears. The number of forms out there on the web that are really just used as a way to group collections of input elements, with no consideration for an action, a method, browser native validation rules, fieldsets, a legend, etc makes me wonder if people actually know HTML at all. Every React, Vue, etc form I look at the source for gathers up input into state and then submits it with a fetch, replicating, but also often breaking, the accessibility and functionality built into the browser.

So yes, maybe being able to implement a form tag in HTML is the mark of a senior dev.

[corrral]

I'm very much on the "this shit's too complicated, we should fix whatever's making us not use the standard features and tools instead of piling this garbage on top" train, but I think a valid defense of doing things in Javascript that could be done in HTML is that, as soon as you need to do any e.g. form validation in JS, it may be simpler to just do all of it there.

The accessibility issue is, of course, a solid counter-argument to running too far with that line of reasoning, and is part of why I'd much rather we put 1/10 the effort we do to constantly re-implementing basic HTML features into unfucking HTML standardization so we can finally have elements good-enough that we don't need to pile JS on top to get what ought to be built-in functionality. But, that's a whole different skillset from programming, and requires far more organization than thousands of devs all independently, or in small teams, working on yet another NIH version of an image upload input. :-/

[anyfoo]

I see web development is still trying to make something fundamentally ill-suited for its task work by stacking shoddy layer after shoddy layer on top of it, just like it did when I left web development 10 years ago and went back to system programming.

System programming also has its warts, but at least most of the time you don't feel like you're working against the machine.

[NoGravitas]

We're finally getting lots of things (HTML native validation, date and time pickers, etc.) that make JavaScript unnecessary for the things it was commonly used for in the 2000s. Unfortunately, in the mean time, client side scripting has metastasized throughout web applications to the point that things that browsers and HTML actually do implement well (history, keeping your place in the page, accessibility) are generally re-implemented, poorly, by web applications.

[forty]

Not knowing about it can also qualify you as a very senior dev (though not very up to date with recent improvements) as the form tag was apparently added to the (then informal) HTML format around 1994 ;)

[anitil]

All tags are divs these days.

[com2kid]

The funny bit being react uses regular browser APIs for network requests! Nothing was even gained, just call fetch!

[kevlened]

True! Though the funny bit is you don't need an API at all (at least not a json-driven one). A form post is even simpler.

[bryanrasmussen]

What if the API she wants to call doesn't have a form based version?

Suddenly she needs to change stuff on both backend and frontend, and she might only be allowed to touch one of those ends.

[mwcampbell]

I think the best solution to this is to eliminate the division of labor between back-end and front-end, for the majority of applications that don't actually require deep specialization in either. As DHH put it, integrated systems for integrated programmers [1].

[1]: https://m.signalvnoise.com/integrated-systems-for-integrated...

[aliswe]

I've met such (male) frontend developers before, totally clueless when it comes to the DOM and how it works. Not putting any judgment in that really, tbh, because the React development model is superior for anything non-trivial (like a signin form).

In this case though, I believe she isn't confused as to how to call the APIs, maybe not even as to how to handle the response with JS and update the DOM. I think the question sounded more like you're not allowed to use Javascript at all.

[ericmcer]

I started in 2008 and I would be hopeless at certain things that I am sure were essential 20 years prior.

Thinking React is essential to make an API call is a bit scary, but a future where we just click a few buttons and connect to a hot reloading syncing dev env with all the dependencies and transpiles obfuscated, seem inevitable, and it will be so reliable that we forget or never even learn how it works under the hood.

[shkkmo]

I think this is a question about becoming dependant on abstraction rather than where the abstraction is run.

I don't think that being "in the cloud" makes abstraction that much more pronounced. You can have manually configure dev VMs in the cloud or automatically configured dev VMs locally, the later will probably use more abstraction.

[rglover]

> I don't really know what to do about it, but I don't believe we're a bunch of old men yelling at a cloud (quite literally - AT A CLOUD), especially that I don't think we're that old.

I'm working on it: https://github.com/cheatcode/joystick.

The tl;dr is that I'm offering a full-stack framework that takes advantage of vanilla JavaScript and HTML in a front-end framework combined with a plain ol' HTTP back-end using Node.js. The APIs abstract just enough to make you productive but not so much that you can't reason about how it'd work without the framework.

The long shot of the project being to keep the mental model of "how the web works" intact while reducing the burden of doing everything from scratch.

[c0balt]

Your project looks interesting. Do you plan Typescript support with stubs vor smth similar?

[rglover]

Thanks. If I do, it won't be supported beyond the compiler/build tool (no official recommendation of using it w/ limited support).

It's an unpopular opinion, but I view TypeScript in the same light as I do the OPs assertion about cloud-only development. It's adding yet-another-layer that has some merits but often leads to overcomplicated messes that reduce productivity/add confusion.

I'd rather petition for some sort of structs/arg typing to be included in ECMAScript proper (in a similar fashion as to what happened with a lot of Jon Resig's jQuery DOM selection APIs making their way into ES6).

[heavyset_go]

As to you last point, there are proposals to bring typing to ECMAScript right now.

[heavyset_go]

Your*

[rglover]

Yup