Live data from Hacker News

The deskilling of web dev is harming us all

baldurbjarnason.com

61–66 of 66 posts

Re: The deskilling of web dev is harming us all

#61

Earlier quoted context omitted.

I have been saying this for years. The opinion has become even firmer since moving into DB specialization – the horror show of schemata and queries that even dedicated backend teams dream up is unreal. I don’t even really blame them; relational databases are hard . Yes, anyone can install Postgres (or spin up a managed service) and get decent results for quite some time, but at scale you absolutely have to know what…

> at scale you absolutely have to know what you’re doing There's a lot of runway you hit that magic scale : https://news.ycombinator.com/item?id=39276069

Yes, but the runway is a good deal shorter if you’re doing things as most dev teams without RDBMS knowledge do. The biggest three issues unfortunately build on each other:

Using JSON when you really should be properly normalizing your schema (or using a DB better suited for JSON).

Using UUIDs – especially UUIDv4 – for any indexed columns, especially as PKs.

Using Postgres for no actual reason other than it’s popular.

MySQL / InnoDB is a clustering index RDBMS, which can have massive performance improvements over others IFF you build your schema around it. If you use anything non-k-sortable (e.g. UUIDv4) as your PK, it suffers massive performance degradation instead. So you use Postgres instead, and think you’re immune. Wrong – its MVCC implementation means you’ll have approximately 7x read amplification for Visibility Map lookups under the same circumstances, and huge amounts of WAL bloat, which can also lead to increased network latency.

JSON[B] in Postgres is frequently TOASTed due to its size. The overhead from TOAST/DETOAST isn’t small, and you also have to deal with difficulties indexing the column, and you can’t as of yet do a partial update to a JSON column. MySQL can do partial updates, doesn’t have TOAST, and has better (still annoying) strategies for extracting scalars from them to be indexed as a quasi-sidecar lookup, but it lacks GIN/GiST index types.

I’ve personally ran a single MySQL instance with over 100K QPS, and it had the plenty of runway, and a ton of vertical scaling left. This was with very careful tuning, and a suboptimal schema. I’m sure it could go far higher if everything was done correctly from the start.

Re: The deskilling of web dev is harming us all

#62
post #56

Earlier quoted context omitted.

HTML has been stagnant for so long that as a document-oriented language... it doesn't even have a table of contents element! Or a bibliography!

HTML Custom Elements would allow you to define and provide support for your own element, so you could use it, and all browsers would understand it, and dev tools and CSS and JavaScript and all other HTML would work fine with it.

All that can be done without semantics. But HTML is also a document-oriented semantic language. Your way would just have idiosyncratic elements, which is little different than a div from the perspective of the rest of the world.

Re: The deskilling of web dev is harming us all

#63
post #43

I think the “full stack” trend is harmful. Yes it sounds nice in theory but there’s so many things to learn both in front and back end parts that I’m yet to meet a true “full stack web dev” even if they all claim to be. Yes a guy who’s done backend all his career can write some basic HTML and CSS and some JS. And some frontend guy can write a simple server side code that writes and reads from a datastore. But they’re…

Like another commenter here, I've been full stack since my first working day, and to this day, 1.5 decades in the industry. I've always touched on infrastructure, on the database, on the server side and on the client side. Vertical implementations of features. I can't begin to imagine life as just a ... database guy, or a backend guy or just a frontend guy. Perhaps it needs to be aligned in everyone's eyes that we ca…

this is fine when you're a junior learning but it's asking to get shit dumped on you later on. I think it's a good idea to pick a lane later on in your career and settle into it.

Re: The deskilling of web dev is harming us all

#64
post #56

Earlier quoted context omitted.

HTML Custom Elements would allow you to define and provide support for your own element, so you could use it, and all browsers would understand it, and dev tools and CSS and JavaScript and all other HTML would work fine with it.

All that can be done without semantics. But HTML is also a document-oriented semantic language. Your way would just have idiosyncratic elements, which is little different than a div from the perspective of the rest of the world.

I think what you're calling "my way" is just what HTML is designed to be in its own specification. Custom elements have been in the spec for over a decade and are supported everywhere, they're as legit as any other part of standard HTML.

Re: The deskilling of web dev is harming us all

#65

As a backend guy I uhh.. have long been of the opinion that web dev was always on the slippery slope of deskilling. I remember working on a project where I was lone backend guy doing data storage/retrieval/aggregation/caching/entitelement/etc all behind a discoverable API that fed the UI everything it needed in a handful of calls. Meanwhile the web dev guy took 6 weeks of iteration to create a date selector that wasn…

Sounds like you worked at squarespace... The date picker of their events creation feature works just like that, among other problems with their date selection support like not handling recurring dates...

Re: The deskilling of web dev is harming us all

#66
post #64

Earlier quoted context omitted.

All that can be done without semantics. But HTML is also a document-oriented semantic language. Your way would just have idiosyncratic elements, which is little different than a div from the perspective of the rest of the world.

I think what you're calling "my way" is just what HTML is designed to be in its own specification. Custom elements have been in the spec for over a decade and are supported everywhere, they're as legit as any other part of standard HTML.

To descriptively move the needle on the semantics of custom elements you must first move the world. Any semantics you attach to your custom elements really is just your semantics. If you want this to change then start persuading everyone that your custom elements ought be semantically observed.

Until then, a custom element is just a div. Semantically opaque.

When we have actual consensus on elements and semantics, that enables very rich clients that can provide an alternative view over the same information, regardless of prior styling. For example, imagine if hovering over any time element will also show you a visual ticking clock or calendar. We wouldn't be able to do that if we didn't have consensus on the semantic meaning of time as something more than a valid token for a parser.

Post reply on HN