[HN Gopher] How do you do, fellow web developers? A growing disc...
___________________________________________________________________
How do you do, fellow web developers? A growing disconnect
Author : todsacerdoti
Score : 133 points
Date : 2024-12-19 13:39 UTC (9 hours ago)
(HTM) web link (rakhim.exotext.com)
(TXT) w3m dump (rakhim.exotext.com)
| freetonik wrote:
| Thanks for posting. Earlier I submitted the original video which
| motivated me to write this blog post:
| https://news.ycombinator.com/item?id=42461182
| simonw wrote:
| Given that every inch of that YouTube gameshow is "Sponsored by
| Jetbrains" (their logo even shows up multiple times on the spinny
| wheel thing) I'm not surprised they feature screenshots of
| Jetbrains IDEs showing off their type-related features.
| sesm wrote:
| Also, it makes sense to target this show at complete beginners,
| because experienced programmers rarely change their tools.
| k__ wrote:
| Not a fan of these "old man screams at cloud" posts, but I had a
| similar experience.
|
| Suddenly, everyone was talking about HTTP APIs, when they said
| API.
|
| With the rise of IOS and Android, I expected the mobile devs
| would build something better than HTTP, without all the cruft
| from the past. But somehow that didn't happen.
|
| Now API is synonymous with HTTP.
|
| Strange how things turn out in the end.
| penjelly wrote:
| > Suddenly, everyone was talking about HTTP APIs, when they
| said API.
|
| I always try my best to delineate for people asking, but often
| I find they only care about the web API case, so me harping on
| about how an API can be used to control a robot OR a web server
| often just confuses them more.
| Kim_Bruning wrote:
| I ... I may have made a web API that can control a robot?
|
| Err.... I realize I'm not helping. I'll see myself out.
| alibarber wrote:
| I had the same awakening a while back when changing industry. I
| was proud of my "API Design" that included header files,
| perhaps a python wrapper etc - whereas everyone else was
| talking about HTTP verbs, which luckily I was fairly well
| versed in.
| fidotron wrote:
| > With the rise of IOS and Android, I expected the mobile devs
| would build something better than HTTP, without all the cruft
| from the past. But somehow that didn't happen.
|
| Google, in particular, early on went for the php developer
| audience. Frankly this destroyed the technical credibility of
| people in the mobile space and we have been living with it ever
| since.
| freetonik wrote:
| Had a similar moment at one job. We were discussing possible
| API design choices for an integration project, and more than an
| hour into the meeting we realized half of the room was assuming
| HTTP. This rendered the majority of arguments spoken so far
| irrelevant.
| gollum999 wrote:
| > Suddenly, everyone was talking about HTTP APIs, when they
| said API.
|
| I had a junior dev try to correct me when I used "framework"
| and "API" outside of a web context.
|
| It caught me off guard at first, but the more I've thought
| about it, it seems inevitable as time goes on. The more
| abstractions we build, the more unreasonable it becomes to
| expect every developer to start with "bare metal" and work
| their way up. Schools are forced to teach with "the other side"
| (i.e. the highest-level abstractions) as the benchmark for
| graduating, because that's what employers need. So at some
| point they have to cut some of the more esoteric CS
| fundamentals and concepts to make room.
| hahn-kev wrote:
| They did that before, it all depends on your definition of
| bare metal. They probably don't teach assembly, or circuit
| design even though that used to be bare metal
| 01HNNWZ0MV43FF wrote:
| I had another dev mix up "object" and "response" and say
| "JSON response" in reference to a request that sent JSON. I
| asked 2 or 3 times, "Response to _what_?" before figuring it
| out. That still lives in my head.
| layer8 wrote:
| From the point of view of the server, the request might be
| a response. ;)
| blackoil wrote:
| Because HTTP is ubiquitous and now performant enough. It has a
| whole ecosystem of battle tested tools that can handle any
| usecase you throw at it. So, unless you are writing an app used
| by billions of users or some game hyper-sensitive of latency or
| backend service for similar size platform, you'll do better
| with HTTP.
| alibarber wrote:
| I think this comment misses what we're saying here in that
| there are many people working on things like operating
| systems, specialist desktop software and libraries, for whom
| API design has nothing to do with any form of network
| transport at all.
|
| In my case, the company I worked at shipped a product that
| came with a set of header files and dynamically linked
| libraries that exposed some of the core functionality to the
| customers for use in their own software, and designing this
| API was a specific task in itself.
| netsharc wrote:
| API stands for "application programming interface". E.g. a
| graphics card driver can provide an API for an application (a
| web browser, a game, a calculator app) to draw an image on
| your screen... should it speak HTTP to do that?
| 01HNNWZ0MV43FF wrote:
| Over the years I've come to like HTTP. It's mostly text-based,
| but you can send arbitrary binary data through it. The request-
| response pattern is a decent match for a world where most
| computers have no clue where they are, need help learning their
| own IP address, and are stuck behind trapdoor firewalls anyway,
| so the only really usable case is to reach out to a well-known
| server at a well-known address and ask it to do something.
|
| Of the whole web stack, HTML is the only part I've consistently
| hated since the big web revolution that started around 2007.
| It's just such a piece of shit. JS got faster and TS redeemed
| it substantially. HTML still sucks.
| berkes wrote:
| Is it really a disconnect? Or just a single poorly made game
| show?
|
| The article doesnt really get into this. It just describes the
| mistakes in a show, and hints at a few other anecdotes to then
| conclude there's a disconnect.
|
| I believe there may be such a disconnect (34 years of programming
| under the belt, here) but it's hardly more than a feeling, or
| belief. This article doesn't substantiate this.
| airstrike wrote:
| _> My growing feeling of disconnect gets fueled mostly by
| seemingly shifting notions. Some examples I 've heard are
| people saying "vanilla JS" when talking about Node, or saying
| "JS without frameworks" when talking about React. The "woah"
| moment from the first paragraph is another example._
| simonw wrote:
| It's genuinely fascinating to me how many professional web
| developers these days - smart people who produce good work -
| don't know how to build interactive features using HTML on its
| own (and maybe don't even know it's possible).
|
| Being able to do things like this is really useful:
| <form action="https://simonwillison.net/search/" method="get">
| <input type="text" name="q"> <input type="submit"
| value="Search"> </form>
|
| I've seen teams estimate a full day to add a link to a contact
| form because they need to refactor a bunch of React components to
| achieve that. I like being able to do this: <a
| href="/contact">Contact us</a>
| jetbalsa wrote:
| I'm love old school HTML, need a autoscaling page, lets break
| out some FRAMESETs and some tables/iframes
| geoffeg wrote:
| I worked with a team of developers tasked with creating a few
| 100% static websites. Single page, no interactivity, nothing
| dynamic. They were talking about which React components to use,
| server APIs to build, etc when I asked why they didn't just
| write HTML or use a static site generator and host the page in
| S3. They didn't know how to write vanilla HTML, they had never
| used it for more than bootstrapping a React app.
| amelius wrote:
| Yes, but remember: static HTML is a one-way street. Better
| tell your manager otherwise they will one day come up with
| functionality that can't be done in your website and it's
| your fault.
|
| EDIT: For example: manager/designer wants to add an assistant
| to the website; it should be draggable; it should also
| animate and keep animating smoothly no matter where the user
| navigates on the website. If your website is a SPA, this is
| conceptually easy. If your website is static this is going to
| be a nightmare and suddenly a simple change requires lots of
| work.
| epistasis wrote:
| You can't add interactivity to a static HTML site? Or shift
| the static pages into modern frameworks?
| willsmith72 wrote:
| I mean let's not go too far and pretend there is 0
| advantage to JS
| frostiness wrote:
| You absolutely can, but it's way more common to only know
| how to create a blank site with a framework than to
| migrate an existing site. React used to have a section in
| its documentation for how to add it to your site without
| adding a build system (not common knowledge, unless it's
| setting up a blank site through a script) and they've
| since replaced it with a brief tutorial telling you to
| migrate your website to a JS module with a link to a
| suggested build system.
|
| All of this matters because the person that has to do
| this setup might not be you. It's certainly a problem
| with the frameworks themselves that porting a website
| (even just to add a little functionality) isn't as easy
| as setting one up initially but there's not really much
| an individual can do here. It's one reason I like
| frameworks like Preact so much, they're actually trying
| to fix this.
| epistasis wrote:
| Understood. Makes me think of YAGNI though.
|
| https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
| amelius wrote:
| No because a page-load e.g. breaks the animations.
| epistasis wrote:
| Are these frameworks incapable of having the static
| content as something that can be served? Are the links in
| the existing content unable to be updated to whatever
| need to happen for the page transitions?
| WorldMaker wrote:
| CSS does support page change transitions now.
| theamk wrote:
| Not at all.
|
| There are plenty of things you can do with static websites,
| especially given you can have site generators and/or can
| write javascript by hand too (shock!).
|
| For example if the requirement is to have website editable
| by non-programmers, that's where static site generators
| shine. Sure, one has to press "deploy" button and wait a
| minute before changes are visible... but you get to keep
| all the features of static pages, like trivial scalability
| and very high security and availability.
|
| Even if you have to have dynamic functionality (like a
| shopping cart), there is no need to do the whole website
| dynamically. Sure, have an API server which may even render
| the cart page, but the rest of the website can be fully
| static, maybe with a tiny bit of javascript to render the
| "number of items in the cart" icon.
| towelrod wrote:
| Yes, but remember the much more important rules of
| programming:
|
| You aren't gonna to need it[1]
|
| Do the simplest thing that can possibly work[2]
|
| 1. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
| 2. https://www.ronjeffries.com/xprog/articles/practices/pra
| csim...
| xnx wrote:
| You can make an example that will invalidate any technology
| choice. Design for the requirements you have.
|
| "That's a very nice car you've made. Unfortunately, if the
| designer later decides that it needs to survive artillery
| rounds, you'll wish you had built it out of armor steel as
| I recommended in the first place."
| exe34 wrote:
| YAGNI should be tattooed on some people's eyelids.
| ASalazarMX wrote:
| On the outside of their eyelids it would do nothing for
| self-awareness, so I'm assuming written on the inside...
| which they won't be able to see unless they look at
| something super bright, like the sun, with their eyes
| closed.
|
| ... I guess this season some of us have more time to
| overthink things.
|
| Still, YAGNI needs careful consideration. What looks like
| YAGNI right now might be reasonable flexibility that will
| be needed as the project matures. YAGNI makes perfect
| sense when delivering a proof of concept, but it's not
| that straightforward when designing for long-term use.
| ffsm8 wrote:
| It's not anymore!
|
| Multiple options around, I personally love this
|
| https://lit.dev/
|
| You can develop that element and then just drop that onto
| your static page via /assets/ and you're golden. Easy to
| develop, simple to deploy and tiny file size.
| scotty79 wrote:
| You can easily put React components into static website
| once you need them wherever you need them.
|
| That's one of the selling points of react that was
| initially important that you can use it in limited fashion.
| amelius wrote:
| It's because submitting a form interferes with all the other
| stuff running on the same page. E.g. after submission
| animations stop or disappear or skip a frame, annoying
| designers, etc. etc.
| moron4hire wrote:
| I don't think there is really anything in your "etc. etc." I
| have never heard from any real user a complaint about
| animations stopping mid-flow. I think people know how pages
| work, in that I think they expect clicking things to do
| something disruptive, altering, changing. It's only been the
| design astronauts that have argued these discontinuities are
| "confusing" to users.
|
| If anything, sometimes I think they make the transition too
| smooth, to the point that it can be possible to miss it.
| Sharp changes are generally easy to notice.
| amelius wrote:
| > I don't think there is really anything in your "etc.
| etc."
|
| "etc. etc." = anything with state, so this can be quite a
| lot actually ...
| BiteCode_dev wrote:
| HTMX.
|
| Or worst case scenario, fetch().
|
| But honestly, forms are fine. Not all apps need beautiful
| animations.
|
| It's better to have great UI, but it's not free.
| jmathai wrote:
| It's not _always_ the right tool but in more cases than
| modern devs believe, it _is_.
|
| I've built several web applications recently that don't use
| any modern JavaScript framework. You'd be surprised how
| quickly a page can fully reload and equally surprised at how
| okay of a UX it is to not always persist state.
|
| Here's an example video of an app that does a mix of "state
| persistence" and "good ol' reload the page" approaches.
| https://withlattice.com/documentation#nav-create-application
|
| 1) Chat interface maintains state (but uses minimal
| JavaScript)
|
| 2) Application status requires a reload
|
| Is this the absolute best UX? Possibly not, but users haven't
| said anything about it and it's such little code with almost
| zero dependencies.
| edoceo wrote:
| Nobody complaining isn't necessarily a "good thing".
| Absence of evidence and all that.
|
| I've found that it's only like 1/1000 that will.
|
| And this thread (few days ago) about why it's hard to buy
| nice things touches it
| https://news.ycombinator.com/item?id=42430450
|
| Many (most?) don't raise issues because they've been
| conditioned that things won't get fixed.
|
| I'm with you that overdone JS isn't necessary; and we
| should also consider user-silence to issues to bloat,
| slowness and jank.
| jmathai wrote:
| I agree with all of that. Perhaps what I meant to say was
| that these weren't the things users _were_ complaining
| about.
|
| I love a beautiful UI and experience. Listen to users and
| prioritize what helps them.
| oblio wrote:
| Forms are the real problem, not the tons of ads, auto playing
| videos, notification pop-ups, etc :-p
| epistasis wrote:
| As the old man screaming at the cloud, about the insane
| complexity of modern JavaScript frameworks, who hasn't done
| much with them and kind hates the experience of dealing with
| them at all, I hope you are right.
|
| Can I still use my basic HTML knowledge and be productive? I've
| instead just given up doing any frontend work because I don't
| want to spend my time in React. Give me something simple,
| concrete, and understandable like an advanced algorithms
| textbook, and I'll go to town. Reading user guides or
| documentation of Typescript/Javascript frameworks feels
| impossibly hard in comparison.
| ecshafer wrote:
| Working with Turbo and Stimulus with Rails is such a breath
| of fresh air for me for this reason. Sure its not just
| writing HTML, but its such a vastly simpler framework for
| creating a responsive web page than React, Vue, Angular, etc.
| I don't know how React and the like became the de jour of Web
| development, its quite a complicated beast. I am partial to
| DHH's interpretation it was off of zero interest rates and
| free money.
| hnthrow90348765 wrote:
| I can't think of any job postings I've seen recently that
| only wanted straight-forward web development. Everything was
| asking for a major framework + other supporting libraries for
| the front end. I'm only 40 and also screaming at the clouds,
| but I simply don't have the luxury of ignoring some of the
| larger things like React that gave me a job today.
|
| This is the market pressure which is driving things towards
| more abstraction. Another iteration will add more abstraction
| on top of that. I'm fairly certain it can't be stopped now.
| Doing so would mean convincing tech leadership to start
| actively managing what technologies go into their products
| and striving for a "less is more" or minimalism approach.
| epistasis wrote:
| I'm in the fortunate position of not needing to care much
| what people are hiring for. Instead I'm more interested in
| what can I create, and to a lesser extent what sort of team
| could be scaled on the technology. One of the projects I'm
| currently contributing to is a massive web app that's
| nearing 30 years old, all written with a C core and served
| over CGI in Apache, from an age when C was necessary to
| process the amount of data that was getting processed per
| request...
|
| I do think there are somewhat perverse incentives in the
| job market to be up to date on the latest trend in order to
| maximize the ability to hop onto the most in demand
| platform. Which makes sense from the developer perspective!
| But then it also means that devs and even management feel
| pressure to churn the tech stack on existing working code
| continuously, to keep abreast of the changes. There's a lot
| of devs that don't want to be considered stuck on an "old",
| e.g. PHP, stack, and sometimes management wants to be
| hiring the devs that are trying the hardest.
|
| So to me it feels like a lot of change for changes sake, or
| in other words the design space of web languages are being
| fully explored at a great pace, using real world projects.
| I don't think it's technically incorrect or wrong, but it
| is probably just a "not for me" part of the ever expanding
| tech world.
| fragmede wrote:
| PHP just released version 8.4.2 today, so if that's your
| ball of wax, and you're working on your own projects,
| have at it. I wrote some PHP earlier this year for this
| one project. React pulls together a bunch of language
| features so that writing full blown apps in html, css,
| and JavaScript is less of a multi-level, multi-language
| templated nightmare for the developer who's writing it.
| Facebook was built on PHP so it's possible to build a
| fully featured web app using PHP and JavaScript, but
| that's also that's where React came from. React isn't
| just change for changes sake. PHP and hand rolled
| JavaScript can take you where you want to go, but getting
| there with React is just a bit more comfortable because
| it isn't a pile of templates with two languages you have
| to keep in your head simultaneously, and you can more
| easily debug it. For the cost of learning new ways of
| doing things, there's inheritance and composability. it's
| far from perfect, but, imo, it got popular because of how
| much easier it is to wrap your head around a pile of
| react components than it is a pile of php templates and
| its attached pile of JavaScript.
| MatejKafka wrote:
| Yes, if looking at the right places. :)
|
| https://help.kagi.com/kagi/company/hiring-kagi.html
|
| """
|
| Core Front-end Team (we are currently full, check back later)
|
| - Passion for creating delightful and swift user interfaces.
|
| - Proficiency in HTML, CSS, and an understanding that
| JavaScript can be used sparingly to enhance, not create,
| product experiences.
|
| - You are comfortable not using any FE frameworks, and rather
| like to be in full control of the DOM and as close to browser
| as possible.
|
| Fun fact: At Kagi, we prioritize speed, to the point where
| all functionalities of Kagi Search (except Stripe checkout
| and Maps) work perfectly without JavaScript. We see
| JavaScript as a tool to enhance the UX, not create it.
|
| """
| alexashka wrote:
| > I've seen teams estimate a full day to add a link to a
| contact form because they need to
|
| Has it ever occurred to you that maybe it only takes them 15-30
| minutes (still too much, obviously) but that it is great to be
| able to only work 15 minutes/day?
|
| Estimates reflect what managers will say ok to, not how much
| real work it takes.
| simonw wrote:
| No, I've seen them do the work. Refactoring those React
| components genuinely takes ages.
| sgarland wrote:
| To spend the other 400 minutes learning something new, right?
| someothherguyy wrote:
| I strongly encourage new junior hires to read MDN,
| specifications, etc. However, for some, it is like they cannot
| absorb information if its not in video format.
| rikthevik wrote:
| I totally agree. It's like we've forgotten what browsers and
| HTML are meant to do.
|
| Back in the day we used to rail on Flash websites because while
| they looked nice, they weren't accessible to screen readers
| etc, sites weren't consistent, links didn't turn purple, and
| the back button didn't work.
|
| Now we've done that again with HTML and React.
|
| Flash is dead, long live Flash.
| freetonik wrote:
| React and similar frameworks are still generally better for
| accessibility compared to Flash, but at the same time can be
| worse because pages may behave sporadically and in unexpected
| ways, whereas Flash would be a blindspot for many
| screenreaders and related software.
| nunodonato wrote:
| this is why I dislike the modern web so much. I love to find
| websites that are nice and simple, load fast, and have no JS
| bullshit to render "modern" UIs. But yeah, old man yelling at
| cloud and stuff... but you know what, I'm fine with that. And I
| do have the hopes of building something useful and successful
| that gives the middle-finger to all these "modern" frameworks.
| blackoil wrote:
| It looks all these rants are from people who need "Hello World"
| equivalent of web and are angry that there are tools for more
| complex use cases. I am primarily a backend developer with
| couple of decades of experience, who is now working on his own
| startup. I have built a simple HTML/JS site as our launch page.
| But I would kick out anyone who'll suggest that we should use
| plain HTML/JS instead of a frontend framework for our main app.
|
| A form submission is not just a post submit. You have to do
| client+server error handling, dynamically show/hide/add fields,
| show char count, handle intermittent state and still more. All
| of these are possible with JS but is faster and more reliable
| with a purpose-built library. Same goes for a draggable
| dashboard, filters for search results...
| MatejKafka wrote:
| > A form submission is not just a post submit.
|
| Can be. And still work better than a lot of JS-heavy
| monstrosities.
| intelVISA wrote:
| Only one day? They must be juniors, that's at least a month or
| two - few hundred story points, dozen alignment meetings, QA,
| stakeholder buy-in, A/B tests, security consult, PM/PO/SM/EM/TL
| sign off, heck just catching up with the UX team alone would
| add a day's worth of calls.
| Buttons840 wrote:
| An underappreciated reason people pad estimates is that it
| gives them some time to breath and know what business goals
| they personally need to deliver.
|
| In the case of 1 day to add a button, let the developer have a
| day of knowing "today, my goal is to add a button". Without the
| padding the developer would be thinking "I'll add that button,
| but after that I have no idea what's coming, whatever bullshit
| comes down the pipe I guess".
|
| It's really hard to shift mental gears. People can do multiple
| tasks well, but only if there is a coherent thread they can
| follow through those tasks. Current software management
| philosophies are very hostile to those coherent threads.
| exe34 wrote:
| I don't do web stuff for a living, but I've been hacking since
| the early days of JavaScript - what I don't understand is what
| happened to separation of content, layout and interactivity -
| most of these react et al. monstrosities start with a big mess
| of JavaScript generating the html as lisp-like nested trees of
| tags. in that case, why not just use lisp?
| phist_mcgee wrote:
| Because not everyone likes writing lisp?
| exe34 wrote:
| writing lisp in JavaScript is so much worse!
| ozim wrote:
| It worked for documents and maybe sprinkling jQuery here and
| there.
|
| For web apps it breaks especially for SPAs really quickly.
|
| So I believe it went out of the norm like 10 years
| floydnoel wrote:
| woah! i couldn't agree more. i built my own router for React
| because i was exhausted by having every link be some overly
| heavy abstraction around... a few characters of text. KISS is
| key for me.
| behnamoh wrote:
| I really liked the font and found it, it's "IowanOldStyle":
| https://font.download/font/iowanoldst-bt
| cannibalXxx wrote:
| because I felt this strong disconnection between our class, I was
| and still am working on https://chat-to.dev which, despite being
| only a year old and a fairly small community, I feel that in some
| way I'm contributing to a healthy environment among developers.
| agentultra wrote:
| The Jblow and Muratori rants are contentious. Try arguing for
| formal methods some time.
|
| The industry has had enough time to expand to include many
| different zeitgeists. I find myself smirking when I read old ewd
| essays decrying how programmers then didn't understand
| programming. Seems like we've continued down that path.
|
| From my part of the pond you'd expect the _Computer Science_
| questions to cover areas of combinatorics, abstract and linear
| algebra; satisfiability, search, and the like.
|
| But we are talking about a pop culture type of show and what is
| the most popular form of programming today?
| mattgibson wrote:
| I wonder if every generation is doomed to feel this way. Socrates
| was horrified about the corrosive effect of reading upon young
| people's ability to memorise speeches. Plus ca change etc.
|
| https://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext....
| commandlinefan wrote:
| On the other hand, as the guy on twitter recently said, "it's
| not fair that I spent my childhood teaching my parents to use a
| printer and as an old man I'm spending my old manhood teaching
| my adult children to use a printer".
| freetonik wrote:
| To be fair, it's not fair that printer manufacturers do this
| to us for decades.
| layer8 wrote:
| My older relative is complaining that their working life
| roughly coincided with the time where computers became
| mainstream but were still hard to use, and now that computers
| have become easy to use (think smartphones and tablets) their
| (the relative's) productive days are more or less over and
| all their hard-earned difficult computer knowledge is
| becoming obsolete. So they were the generation that had it
| hardest, because they had to deal with computers (unlike
| earlier generations) but had to do so before computers became
| easy to use (unlike later generations).
| iterance wrote:
| To some extent I'm sure the answer is yes, so I think the
| operative question is not "Are kids learning what I learned?"
| Instead it has to be something more subtle.
|
| Perhaps "Is kids' knowledge broadened and deepened by the media
| they consume?" more generally would do. It allows us to
| evaluate extent, change, and appropriateness more broadly. Not
| just the accessibility of a given topic, but how readily one
| can dive into the details and truly learn something.
|
| The landscape of media then _can_ change, but this question
| does not react to _any and every_ change in the landscape the
| way a nostalgic argument does. Socrates would have no reason to
| worry; a book can broaden and deepen knowledge, too. Are we?
| bitbasher wrote:
| To be fair, "reading" in Socrates' time was viewed as social
| media or Netflix is seen today. Mindless entertainment. There
| was more of an emphasis back then to focus on a few solid
| works, memorize and really chew on the content and not consume
| religiously.
|
| Times haven't really changed.
| psychoslave wrote:
| https://www.youtube.com/watch?v=GE-_U8qOp3g
| sesm wrote:
| So the programmer mentioned in the first sentence didn't know
| about 'preserve log' checkbox?
| MortyWaves wrote:
| I'm guessing not which seems about right for someone that also
| doesn't know about non-SPA web sites. Sad.
| oxidant wrote:
| Preserve log is still helpful for SPAs when you want to
| compare requests across full app loads.
| 7bit wrote:
| Did you read more than the first sentence? The answer is there.
| seanw444 wrote:
| The level to which "kids these days" don't have to consider
| memory usage, cache locality, and clock cycles, is frustrating.
| But it is cool to realize how good our technology is now that
| most things aren't unbearably unusable, despite being designed
| horribly.
| kittikitti wrote:
| It doesn't matter if you're a kid, if you're not considering
| memory usage you were either trained by Google, became a
| developer through nepotism, or both.
| s5fs wrote:
| It's also possible to work on projects, or in languages, or
| on systems where resource consumption isn't a high concern. I
| wrote cobol for sun and hpux and these big old systems had
| plenty to go around. Important software comes in all shapes
| and sizes, as do their developers.
| icedchai wrote:
| Hardware giveth and software taketh away.
|
| My desktop today has 64 gigs memory, 12 cores. 10 years ago, it
| was 16 gigs, 4 cores. 20 years ago, it was 1 gigs, 1 core. 30
| years ago, it was 16 megabytes, 1 core.
| listenallyall wrote:
| It cost me over $500 to upgrade my 4mb RAM to 16.
| sircastor wrote:
| My professional career has largely been web dev, where I
| haven't really had to worry about resource constraints
|
| It was quite a lot of fun in my university final project to be
| developing on a 6502 (NES) in Assembly and find myself working
| in a very restrictive environment. Likewise, when I was working
| with a powerful microcontroller, but still only 2k of memory
| and 16k of flash and not being able to use some libraries I
| typically do. I was left having to reimplement stuff on my own
| for my own purposes.
| mywittyname wrote:
| You could have said that 20 years ago. I've never needed to
| worry about clock cycles or cache locality, I don't even know
| how to measure cache misses in my code (I have a CS degree
| too). And the most consideration I give to memory consumption
| is whether to process data in a stream, or in memory.
|
| It's absolutely the case that some developer still need to care
| about those things, but by the time I started my career 20+
| years ago, it was possible to make a good career as a dev who
| didn't know how to work with computers at an extremely low
| level.
| sgarland wrote:
| > how to measure cache misses
|
| Run it under dtrace, probably others as well.
| Swizec wrote:
| As a fellow 37 year old, I had a realization yesterday after a
| prolonged debate about HTMX vs React. For context: I'm a long
| time React fan, think htmx is neat, and remember all the reasons
| why HTML-over-Ajax didn't catch on in the 2007 web development
| era. Been a primarily web guy since 2003 or so.
|
| The problem with React (and friends) isn't React (and friends),
| it's _react developers_. People who aren't web developers first
| and react users second.
|
| I have interviewed (and worked with) _so many_ frontend engineers
| with years of experience whose minds were completely blown by the
| idea of using a form submit event to handle form submission. Or
| my biggest pet peeve - button + onclick to change location.href
| instead of just making a link. Argh.
|
| So yeah I think we're lucky to have grown up with this stuff and
| seen it evolve over time. Many folks these days come to the field
| backwards and miss a lot of the good stuff that's available to
| them.
| edoceo wrote:
| The problem with X isn't X, it's the devs.
|
| I've heard that about PHP, JS, shell, .Net, VB6 and damn near
| every framework ever.
|
| But aren't we the devs? We're just in their code saying their
| baby ugly?
|
| There's gotta be a better way than just blaming noobs.
| Swizec wrote:
| > There's gotta be a better way than just blaming noobs.
|
| Here's an alternative read of what I said: It is amazing that
| these frameworks empower so many people to build working
| software that solves users' problems and creates value. This
| is awesome!
|
| Sure the code sucks and we gripe about how many of the people
| don't even care to learn the depths of the tech they use and
| _clearly they don't need to_. This is a win. We can teach the
| ones who want to learn more and constrain those who don't to
| where they can be effective without causing too much damage.
|
| And most babies are ugly. It's fine.
| rkozik1989 wrote:
| You've noticed two things:
|
| 1. Every generation of programmers typically only has a certain
| window of knowledge, and everything before their time is simply
| foreign to them. Most developers aren't programming history
| buffs, they don't read books from the past to learn about
| technologies or how they work, how we got to now, etc.
|
| 2. When you're starting off on your journey as a programmer
| you're using a lot of things without understanding their
| implementation, and that understanding for most individuals whom
| I've worked with comes from having to debug issues.
| commandlinefan wrote:
| > Every generation of programmers typically only has a certain
| window of knowledge
|
| That's true, of course, but I think the disconnect he's
| pointing out is: a) deeper than that and b) new. I grew up a
| ways before he did and my first serious computer was a
| commodore 64. Like his 286, there was nothing you could do with
| it _except_ program it, and programming was hyper accessible. I
| immediately understood C's pointer syntax when I first came
| across it because the only way to show graphics on a C64 is to
| write to a specific memory address and the only way to
| intercept keypresses is to read from one.
|
| Fast forward to the 21st century. My son is a smart kid -
| graduated valedictorian of a competitive high school - but he
| grew up with "computers" that hid the programming interface
| down so far that most of his experience with actual programming
| has been through emulators so the whole thing feels (and is!)
| artificial. He still struggles differentiating between what's
| "real" and what's emulated and I can tell from interacting with
| other programmers his age that he's not alone.
| simpaticoder wrote:
| The GP's point is more general and stands. Technologists
| inevitably start off "in the middle" of a stack of
| technologies, and then choose to dig down and/or build up
| from there. It is inevitable that newcomers will not
| understand the technologies upon which their current work
| rests. A certain fraction of those will become fascinated and
| drawn to understand the underpinnings of their work, for an
| edge, or for the love of it, or both.
|
| This process happens more naturally over time if you grow
| with the technology. For example, if you started programming
| with HTML in 1995 you not only have ~30 years of experience,
| but you've also seen the changes as they occurred, and have a
| great deal of context about the how and why each of them
| happened. That kind of experience can only happen in real-
| time, unless some kind soul is willing to write a manual to
| help newcomers speed-run it. Such a manual is often called a
| "textbook".
| layer8 wrote:
| Until maybe 15-ish years ago, it was common for programmers
| to "bottom out" on the machine code level. In other words,
| they came to roughly understand the whole software stack
| _in principle_ down to the software-hardware interface (the
| CPU executing machine code). The topic of this thread is
| that this has (allegedly) changed, developers at large
| don't go down in their understanding until they hit
| hardware anymore.
|
| Okay, you might argue that in earlier decades programmers
| also tended to have an understanding of hardware circuit
| design and how a CPU and memory etc. works in terms of
| logical gates and clocks. But arguably there is a harder
| abstraction boundary between hardware and software than at
| any given software-software abstraction boundary.
| ikanreed wrote:
| Nah, I entered the industry in 2008, and I know enough FORTRAN
| to know I never want to use it.
| commandlinefan wrote:
| I often help younger developers with problems that involve
| absolute vs. relative paths - their code doesn't work because
| they're invoking it with the wrong working directory. It's
| immediately obvious to me because I grew up using the command
| line, where files and paths are elemental. They're usually
| _really_ interested in properly understanding what's actually
| happened here, but they've been so intentionally shielded from
| the fundamentals of files and directories that they need quite a
| bit of time to let it all sink in. The solution, of course, is to
| teach things bottom up, but I have some sympathy for beginners
| who lose patience with spending so much time dealing with
| something that doesn't even _look_ like a computer from their
| perspective.
| moribvndvs wrote:
| It has been very eye opening watching young and brilliant
| programmers who have grown up with mobile devices struggle when
| it comes to traditional environments. Many struggle with things
| that seem basic, like file systems, processes, memory
| management, how to use desktops and even mice, etc. However,
| once you solve or abstract away those things, many are able to
| churn out complex software at an impressive rate, particularly
| when they are able to assemble tool chains and frameworks
| together like legos. Then they go back to the struggle bus when
| something in that chain fails or functions unexpectedly.
|
| Differences in the types of environments and how they interact
| with them between age groups makes sense in a pretty boring
| sort of way, and at any rate is solvable through simple
| experience. It's more interesting to me that this observation
| is another point of correlation in the notion that the industry
| has aligned itself with productivity over any other metric.
| While productivity is important, this unbalanced favor has
| introduced fragility and unsustainability into the industry and
| end user market.
| recursivedoubts wrote:
| The blame falls on us olds for not communicating the benefits of
| the hypermedia approach to the younger generation, and allowing
| flashy front end boosters to bully us into silence on the topic.
|
| The tide is turning to an extent though. Here is my contribution:
|
| https://hypermedia.systems
| codazoda wrote:
| I've been feeling this same way but didn't want to articulate it,
| possibly out of fear. I also wrote a little book based on "old
| school" or "pure JavaScript". I'm sure you could make some of the
| same criticisms of that, but I tried to make it pure and down to
| the basics.
|
| It's on Amazon at the URL below but if you're willing to give
| feedback, reach out and I'll send a free copy.
|
| https://a.co/d/bwF4YF5
| jillesvangurp wrote:
| It's not so much a disconnect as more of a reluctance to
| specialize in what is an increasingly legacy/archaic way to build
| applications. I studied in the nineties and I've seen it all.
| Server side model view controller style UIs where each click
| results in a completely new page being fetched that is completely
| static slowly died over the last two decades plus (ever since MS
| pioneered XmlHttpRequest and AJAX became a thing in 2001).
|
| Not doing requests via javascript still works. And for quick and
| dirty stuff where you don't care about how things look and feel
| it's a perfectly valid way of doing things. A lot of developer
| tools fall in that bucket. And a lot of developers are in any
| case a bit challenged on the UX front anyway so there's a good
| argument for not using too many ways to shoot at your feet. But
| having every request wiping the current page, scrolling to the
| top, etc. can be a bit jarring as a UX as well. And there's the
| whole round trip latency for fetching pages too, which can be
| noticeable.
|
| In other words, if paying customers are involved you probably
| should not go there. Mostly people expect things to look and feel
| nice and have some designers involved with the whole thing.
|
| End users don't care about any of this of course. They also don't
| care if the app is native, a webapp, or something you could have
| hosted on geocities 25 years ago. But they do notice if things
| look dated, crap, or otherwise a bit meh.
|
| They especially don't care how things look under the hood. The
| whole notion of semantically pure HTML, vue vs. react, and all
| the other nonsense web developers obsess about. It does not
| matter to them at all. You could use divs for every freaking HTML
| element and they couldn't care less. Or render the whole thing
| with some native UI toolkit to a canvas (which is an option these
| days). As long as it does the job.
|
| You don't have to do a SPA. But you kind of do have to deliver
| something that works and looks and feels nice. With WASM, we are
| kind of getting a lot more ways to do things. The whole game of
| working around browser quirks and limitations with dom trees,
| CSS, and what not is not necessarily the way of the future.
| MatejKafka wrote:
| My personal issue with SPAs is that the experience is often not
| really better than the old school way, it's just the the issues
| and failure modes are different. SPAs tend to be slower to
| load, break platform conventions by re-implementing browser
| behavior and they're are more stateful, making invalid states
| harder to recover from.
|
| Personally, unless the interactivity is needed (i.e. web apps,
| not web pages), I prefer a more basic site where I can be
| reasonably sure that UI will work the same way as everywhere
| else, even if it's not as fluid.
| openrisk wrote:
| People talk about software "technologies" and it is true, there
| _is_ some technology underlying them, but its mostly economics.
|
| The nature of software with its multiple abstraction layers means
| that when the economics is "right" you can pretty much
| transmogrify anything into anything. E.g., you can setup a JS-
| based web server as a classic web framework serving good old html
| and thats not a joke, its reality.
|
| Is web software economics today any different than it was in the
| past? You bet it is.
| relaxing wrote:
| > Which method removes and returns the last element of an array?
|
| The answer is "pop", right? I think that's a fairly generic data
| structures question (if you treat the word array as a standin for
| any modern iterable collection type.)
| shahzaibmushtaq wrote:
| A growing disconnect begins to grow when coders learn from
| bootcamp/courses that web development is an ocean, and this ocean
| is as big as the well.
|
| Strong fundamentals are essential in every field, otherwise the
| disconnect will continue to grow and no one can do a thing about
| it.
| purple-leafy wrote:
| I'm a new developer (2-4 years experience, all self taught) and I
| get what they are saying.
|
| I obviously have gaps in my knowledge (started with Python, moved
| to frontend). Frontend is too abstracted from actual CS.
|
| But I actively take University papers in my spare time on CS, and
| do C in my spare time to appreciate the lack of abstraction in
| low level code.
|
| I really enjoy this (learning and C) more than economic
| programming (frontend, web, career).
|
| I just love learning and realising how little I know. The latest
| thing I've learnt is that structs can have holes, and struct
| packing for situations where you need specific address offsets.
| Made my own bitmaps from scratch etc.
|
| Next I'm thinking of picking up a Lisp.
| JohnMakin wrote:
| I think people just focus on problems entirely within their own
| domain and rarely branch out to anything else. The amount of
| times I've had to explain to senior devs of 20+ years how DNS
| works at a very simple level would astound you, which is
| something that I would assume should be picked up if not by
| learning, through sheer osmosis, but you'd be surprised. If you
| lack a formal education, and maybe went through a bootcamp -
| which there's nothing wrong with - you may not know a lot of
| things that would surprise this author.
___________________________________________________________________
(page generated 2024-12-19 23:01 UTC)