12 ms·

Things engineers believe about Web development

155 points by jnord 3y ago

draw_down 3y ago
Who said every site should work without JS, even Figma? Honestly, who is saying that? Who is saying these things?
- gumballindie 3y ago
  I think the points in this blog are made up. No one with a bit of experience “believes” such things.
- diggan 3y ago
  > https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=%22should%20work%20without%20js%22&sort=byDate&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... (25 results) > https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=%22should%20work%20without%20javascript%22&sort=byDate&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... (28 results) So at least some are saying something along those lines. I'm sure if you search Xitter you'll find even more hits. I think the argument is usually not made in isolation like that though, and usually with exceptions. "Websites without heavy user interaction should work without JS", "Websites should work without JavaScript, unless based on live data" and so on, which makes a lot more sense.
  - draw_down 3y ago
    [dead]
- croisillon 3y ago
  fyi you are shadowbanned, write hn an email to clear that up
- brightball 3y ago
  “Every” is a bit extreme but I’ve been a believer in Graceful Degradation for years. This is where jQuery excelled.
- blackoil 3y ago
  A ridiculously small but very vocal minority which is active on forums like HN.
- ryanbrunner 3y ago
  I tend to make all my pages function without Javascript even if I don't expect my users to turn off Javascript. It makes things easier to cover with automated tests if I can just exercise my backend servers with scripts vs. a headless browser, and if something does go wrong with serving Javascript or something it's nice to know my site is functional. Generally speaking the experience will be horrible (what should be a modal or a partial page reload will be a full reload) but using the technologies I use it's not that hard and it makes my development experience easier while delivering some (rarely needed) benefits to end users, so it's an unqualified win for my particular use case.
troupo 3y ago
While I agree with "web engine developers and web spec deveopers have little-to-no idea about web development" I disagree with "web browsers are good at handling complex and long-lived DOM trees with dynamic changes now"
- hyperhello 3y ago
  They are certainly better than before at handling the memory and bookkeeping of a large DOM tree. Every browser had so many unexplainable little bugs, but nowadays they can be relied on to correctly handle their own internal data without crashing. It’s a huge improvement.
- diggan 3y ago
  > "web browsers are good at handling complex and long-lived DOM trees with dynamic changes now" Is there an alternative renderer/something that handles "complex and long-lived $something-trees with dynamic changes" better than web engines does? They've been optimized for just that during decades at this point, with huge investments both in human-hours and money. Hard to imagine there is something else that can handle that better than browser engines.
  - Const-me 3y ago
    On Windows, WPF is better: https://en.wikipedia.org/wiki/Windows_Presentation_Foundation https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio... The critical features missing from HTML are data binding and data templates. Last time I checked, many modern frontend frameworks contain overcomplicated, incomplete, and inefficient implementations of these features on top of HTML DOM.
    - diggan 3y ago
      I'm not super familiar with Microsoft's offerings, but is WPF available cross-platform? It's hard to argue something that is only on one platform is better when it only have to do 25% of what a cross-platform solution would do.
croisillon 3y ago
"it’s hard to imagine how [Figma and Photoshop for web] could work without JavaScript" is a bit of a strawman
ryanbrunner 3y ago
The refrain against the "we should go back to MPA apps with server rendered HTML" is often "well what about Figma and Photoshop", which of course, yes those don't really work in the MPA, server rendered HTML model. The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites because it sounds sexier and cooler to work on something complex than something simple. The phrase becomes "well, what about Figma and Photoshop (and my mostly CRUD SaaS)?" I think a valuable insight that the MPA / minimal JS crowd is bringing to the table is the idea is that you shouldn't strive for cool and complicated tools, you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can.
- endisneigh 3y ago
  > you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can. Why do you believe this? I couldn’t disagree more. People should strive for the most effective tool, and most of the time that’s what they already know, unless some new tools’ efficacy outweighs cost to learn it
  - ryanbrunner 3y ago
    Fair point that my point was overly reductive. But given you understand multiple tools, you should reach for the simplest tool possible to solve the problem. And in some cases you should still reach for the simplest tool possible even if you don't understand it yet. If you've only ever used Kubernetes but someone asks you to host a static HTML file at an address, you should learn how to use a simpler solution for that.
  - Xeamek 3y ago
    >most of the time that’s what they already know, unless some new tools effficacy outweighs cost to learn it ....which any proponent of the new tool will argue it does
    - 3y ago
jefftk 3y ago
> As an example, the Eleventy documentation seems to avoid using client-side JavaScript for the most part. As Eleventy supports various templating languages it provides code samples in each of the different languages. Unfortunately, it doesn’t record which language you’ve selected so if your chosen language is not the default one, you are forced to change tabs on every single code sample. A little client-side JavaScript here would make the experience so much more pleasant for users. This may actually be an ePrivacy limitation (cookie law) not a desire to avoid JS. Persisting the setting across pages requires client size storage, which in ePrivacy countries requires either that the setting be obvious to the user that it's persisted, getting per-action consent (ex: a "preferred language" setting) or site-wide user consent (a cookie pop-up).
- Gustek 3y ago
  My understanding of ePrivacy (mostly GDPR) is that this kind of feature does not require consent. It's only features that would allow you for tracking of the user that require consent. Storing some setting in a local storage, never sending it to the server is fine. Things get a bit muddy when sending to server but even then you may not need a consent if it is a feature that is required for correct working of the website or better experience without tracking and profiling.
  - diggan 3y ago
    This is correct. Unless it involves personal data and/or tracking the user somehow, then GDPR isn't relevant. Example: If you're storing lightOrDarkTheme in a cookie/localStorage, then there is no need to try to follow any directives, nor are you required to inform the user about that you're storing the preference.
  - jefftk 3y ago
    GDPR and ePrivacy are different regulations. Under the latter even purely local data storage still requires consent unless it's "strictly necessary" to implement something the user has requested. For example, see the discussion the sibling commenter linked around storing UI customization choices for only the duration of the current session: https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio...
mjburgess 3y ago
> “Web development shouldn’t need a build step” Everything running in a browser is interpreted. There is no reason for webdev to require a build step, and it largely does so because JS standards haven't delivered anything around static typing. Even a "this syntax is valid but ignored" would enable IDEs to provide checks via LSPs, but for no-build running. Build steps and development iteration overhead is something to be avoided at all costs. For it to have been introduced, with multi-second latency, to web dev. is a sign of developer experience dropping off a cliff. Time-to-iterate, tool quality, release speed, etc. are essential to being able to build mental models of code (etc.)
- toasted-subs 3y ago
  Ease of deploying is a huge thing which gets lost. Over focusing on a single area of an application makes things really obvious the big picture was lost somewhere.
- croes 3y ago
  >Everything running in a browser is interpreted. That's exactly the reason for a build step. In a build step the code can be optimized to reduce and/or accelerate the code that needs to be interpreted.
  - ryanbrunner 3y ago
    JS builds today do not appreciably accelerate code, and minimization is of marginal benefit when served assets are appropriately compressed using technologies browsers already support.
    - javcasas 3y ago
      No matter how fancy your compression, that code with comments stripped will compress to less bytes than the same code with comments.
      - vbezhenar 3y ago
JackMorgan 3y ago
Last month a client asked me to build them a crud form only using old school C# MVC with Razor templates. And by golly it was much harder for me than just doing it in React+Next. I had some nostalgic notion that MVC was going to be a smooth ride. That all this JS cruft was slowing me down. Then I needed a search bar, then validation, then I kept running into weird surprises with Razor templates. After a month I ruefully concluded I'd have gotten it done a heck of a lot faster just using my usual stack. I now regret all those times I complained about how much bloat there is in the JS ecosystem. Yes, is it possible to make crud apps with Razor, sure, people do it everyday. But for me, with a project with increasingly complex display logic and validation, I definitely should have tried a little harder to talk them into using Next and TS. As an aside, I was surprised that getting HMR with C# is kind of a pain. I never figured out how to get it while debugging. So every time I wanted to debug some new issue with the template not sending data right to the controller (which felt like every few seconds of work) I'd have to restart the server and wait 10+ seconds for it to restart and then renavigate to where I was, reenter my form fields, and then try again. After I was done and wanted HMR, I'd have to restart the server again. That extra hassle really started to grind on my patience.
- onli 3y ago
  The jump from JS to the microsoft world is always hard. Hell, jumping from anywhere into microsoft environments has to be hard. No surprise that it was a difficult transition if that wasn't in your background so far. The docs alone will cause a culture shock! > But for me, with a project with increasingly complex display logic and validation It always sucks if the requirements are not clear in the beginning, if the dev can't anticipate how they will grow in advance? But what has validation to do with it? That's completely backend, how would that have been easier with React+Next? > As an aside, I was surprised that getting HMR with C# is kind of a pain. Proper systems dynamically interpret their templates on every request in dev mode because of this, like Ruby/Sinatra does.
  - tantalor 3y ago
    What is HMR? Is it edit/refresh?
zb3 3y ago
> Maybe 2024 will be the year where client-side Rust/WASM frontend frameworks start to get traction and if that’s the case, we’d better get used to having a build step! That's nonsense, there isn't any progress here. You're just rebuilding things that could easily be built 20 years ago, but with 10X the complexity. And then to solve slow load times your solution is to add even more complexity..
deleted 3y ago
[deleted]
mgaunard 3y ago
Reminds me of the fact that for a long time C++ compiler engineers didn't themselves write code in C++ or know best practices despite writing the implementation.
throwaway167 3y ago
2024 is the year of Rust and HTMX.
inopinatus 3y ago
The tech sector is riddled with such divisions of perspective. ”In a high-level language like C...” - chip designer ”In a low-level language like C...” - application programmer
- graypegg 3y ago
  “Riddled” has a tinge of negativity to it. I would say it’s actually a useful thing, “level” is a count of abstraction layers relative to the abstraction you’re familiar with. It’s more just a way to communicate some personal responsibility/knowledge range. I’ve heard people call Python “a low level way of using a computer” or similar.
  - inopinatus 3y ago
    Riddles are also explanatory. The best programmer I ever worked with writes drivers for a hobby.
- rramadass 3y ago
  Anecdote: Coming from the application side i had always thought of C as a low-level language but in one company where i worked with chip designers who only did Verilog, i was gobsmacked when in my conversations with them they said they didn't know higher-level languages like C and cannot program in it.
  - flashback2199 3y ago
    We're not gobsmacked when you don't know Verilog, so I'm not sure why you think you can be gobsmacked some chip designers don't know C...
    - rramadass 3y ago
      Because until that point i didn't know much about HDLs like Verilog/VHDL and how they were at a completely different level than "standard" programming languages like C/Python/etc. My then assumption was that since C was a low-level language and chip designers were working at a low-level they would be able to program in Assembly/C in their sleep and that they would be able to initiate me into the mysteries of how my C code was actually translated into electrical signals in the processor circuits. It was a big disappointment for me when i realized we were living in completely different worlds. I actually made a deal with some of them to teach them C/C++ in return for them teaching me Verilog/SystemC but unfortunately that never came to pass. I even got me a couple of Verilog/VHDL books and FPGAs to teach myself what i call "Actual and True Hardware Programming" but haven't really sat down with it. Hopefully sometime in the future so i can finally know everything from the bottom-most layer to the top-most.
bacro 3y ago
Recently I was reading the Learn CSS the pedantic way book and the definition for inline boxes did not match the way that anonymous block boxes were generated when an inline-level element had a block-level element as its child. So I went looking elsewhere for a more appropriate definition for that case and found this issue on standards: https://github.com/w3c/csswg-drafts/issues/1477 https://github.com/w3c/csswg-drafts/issues/1477 It was really interesting to know that I was not the only one confused. My question was: Does the inline-box generated by the inline-level element contains the box generated by the block-level child or there wasn't an inline-box that was a parent of them all but there were 2 siblings inline-level boxes of the block-level box that were wrapped in another anonymous block boxes? Reading that issue I got to know the concept of fragments, which I did not know browsers had. But the issue seems to suggest that the box tree for this case should have the inline-box as being a parent of the block-box. Which led me to another question, in that case, if I apply a border to the parent inline-level element, shouldn't it apply to the overall box that is generated (it does not)? The answer is that borders between block-boxes and inline-level boxes should not intersect but that is really difficult to derive from reading the standards alone. Anyway it was headache-inducing trying to learn the box-model pedantically :) I wish I could learn more about layout in browsers and I trying to read the code of LayoutNG in Chromium but I need more aspirin hehehe
imranhou 3y ago
If what the blog suggests are the optimal ways of doing it, it would have been a larger reality automatically by virtue of people continuing to try to optimize. Idealistic views aren’t necessarily practical, and may not get traction in the real world.
- deleted 3y ago
  [deleted]
danielvaughn 3y ago
> When I worked on animations, I was surprised at how many people believed that some animations “run on the GPU” (the browser can offload some animations to a separate process or thread that updates animations using the GPU to composite or even paint each frame but it doesn’t offload them to the GPU wholesale) Not to nitpick his nitpick, but...I've said this exact thing in the past, and his parenthesized explanation is what I meant. It's too much of a mouthful to try and be super accurate and specific all the time.
mostlylurks 3y ago
> “Web development shouldn’t need a build step” A build step is a huge barrier that makes authoring your own websites require significantly more expretise than it otherwise would. It thus makes web development less accessible, and puts anything even a little bit complicated out of reach of anyone who isn't already an experienced web developer or exceptionally dedicated. It also discourages the slow development of some pet website of a not-primarily-a-web-developer-by-trade into something more featureful, since expanding beyond the point where you can still reasonably avoid a build step suddenly requires acquiring a lot more exprertise and expending a lot of effort all in one go, instead of just being a smooth expansion into a more featureful project. The simpler it is to make your own website without having extensive web development experience, the more people will be able to have their own website instead of being directed to the endless array of corporate silos like social media (which has largely replaced personal websites) and corporate middlemen (which have largely replaced in-house commercial websites for smaller actors) that take care of the burden of making your own website for you, with some rather obvious downsides.
- Yaina 3y ago
  I mean, a build step is not required to build a website, but I'd say anyone who wants to have more than one HTML page and one stylesheet will probably want some sort of build step sooner rather than later. Like, if you have two or more pages, you probably want them to share the same header or footer, and unless you want to A) repeat the same markup on each page or B) inject them with a client-side script, you will need some sort of build step. There are more accessible solutions out there, like Hugo. How else are you going to achieve that? Sure you could use PHP, but I don't see how that is more accessible or maintainable than having a build step.
  - dakna 3y ago
    > How else are you going to achieve that? People already thought about that problem when the World Wide Web was invented and they came up with Server Side Includes [0], a scripting standard that predates the Apache HTTP Server. Looks like this inside the HTML document:   Not many people use this anymore, but it is easy to share common markup and very accessible for people with just basic HTML knowledge. Major web servers of today still support it. [0] https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes.
lapcat 3y ago
The article title is actually "Weird things engineers believe about Web development".
5350-uiop-1130 3y ago
nothing wrong with build steps until they go wrong. then you will spend 5 hours replacing/updating deprecated/newly incompatible npm/system issues.
- spcebar 3y ago
  The horrifying guidance I've gotten a number of times when I step into a project is "downgrade your node version 5 years and never update anything."
  - 5350-uiop-1130 3y ago
    a pragmatic solution. sometimes you don't have time and stakeholders don't understand or appreciate the side issues you need to deal with.
endisneigh 3y ago
Technology is not a religion and it doesn’t need prophets. Why are people so hell bent on convincing others to join them in their use of whatever technology? Pick what solves your problem. In the context of web development that overwhelming means using whatever is most popular given your preferred programming language.
butz 3y ago
It would be interesting to measure battery savings made by disabling JavaScript on mobile devices. While it might be cheaper to plop website on GitHub Pages or Netlify and others, somehow I feel that all costs are just handed down to the user in bandwidth and battery use.
rramadass 3y ago
Well written informative article. What does it say about this whole domain when, as the author says, Web Apps and Sites/Blogs (also add in Mobile apps) are so very different from each other using a myriad set of technologies each of which has a learning curve? Where is the uniformity and commonality in all this? Why are developers even perpetuating this? That said, this might be a good place to ask for recommendations for study since i am not a "Web Developer"; 1) Comprehensive books/other sources on full-stack Web App and Site development. Bonus points if they use a single language for frontend/backend/everything else. 2) The same as above but using C/C++ languages.
- calderwoodra 3y ago
  Businesses want uniformity and commonality since, in theory, it should lower development costs (see projects like flutter and fuschia, which have the goal to make every platform web based). The problem is that users/customers have higher expectations for their user experiences than the web can offer on mobile/desktop/etc. Robinhood, Duolingo, Slack are a few good examples of UX being huge differentiators.
  - rramadass 3y ago
    I understand what you are saying but am not clear as to why it should be so. Having programmed GUI apps in Microsoft Windows and X-Windows/Motif (which can be remote) on Unix systems i am not sure why we cannot have a similar uniform architecture for "Web Apps". After all the "Browser" is considered a platform in itself. Also given that HTTP has now been munged into practically being a Transport protocol for anything, previous limitations are no longer an excuse.
amadeuspagel 3y ago
> There are Twitter/X polls, for example, but they tend to only be answered by the Web developers on the bleeding edge and are easily skewed by who spreads the word about the poll. Maybe MDN should have a comment section, like the PHP docs. That would be more representative.
- omnimus 3y ago
  The PHP docs comment section is pretty fascinating. I am not sure how these are allowed. But you will find 10year old comments with very distilled specific techniques or super well explained nuances. Not something i've seen in other languages.
cabalamat 3y ago
> Many didn’t know about new CSS features that had shipped 10 years ago. What’s more, even when we told them about them, they didn’t seem too excited. They were doing just fine with jQuery and WordPress, thank you. ...and if jQuery and WordPress do the job, they are sound technical decisions. What is not a sound technical decision is forever chasing the latest fashion in technology. Also known as the "oh look a shiny thing development paradigm".
bbor 3y ago
Absolutely fantastic writing —- clear, kind, authoritative. Don’t agree with it all but I think the last section sums it all up nicely, and is something I’ve felt for a while. With new SSR frameworks like Next.js, I think this whole MPA/SPA dichotomy starts to dissolve a little bit. I’m thrilled that browser standards are evolving to help it along!
eximius 3y ago
I don't mind a build step, per se, just that the JS ecosystem's build step is particularly more painful than others.
m3047 3y ago
I spend a lot of time with DNS (it just happened, man) and I see the same general thing where a lot of intention and expertise is imputed to others. True systems thinking around large systems is rare. Buffer Bloat (and the lack of progress in remediation, and the lawfare and near literal acts of congress due to misattribution and misunderstanding of the problem) as this thing slouches along and utters its phlegmatic growl could be emblematic.
g9yuayon 3y ago
I'd like to add another one: I don't need a separate NodeJS (or whatever engine) service to build my service dashboard. Before NodeJS got popular, backend engineers like me simply put web assets into a folder in my web app, so my service will have an admin page or a dashboard for per-node administrations. For some reason, such practice has become a taboo. My engineers have been insisting that they set up a separate NodeJS service just to build even a simple admin page. But I fail to see why. The reasons I got are usually these three: 1) a NodeJS service gives us optimized performance, though techniques like server-side rendering; 2) a separate service is easier to scale; 3) a separate service offers separation of concerns. However, 1) and 2) are premature optimization to me. All I need is standardized per-node admin page for my service. The QPS is probably one per day by a human. Why would I care about SSR or scalability at all? And 3) is quite hand-wavy. On the other hand, the overhead of managing a separate service as well as the dependencies brought by NodeJS' ecosystem seems high. So, what's wrong with the old way of having embedded web assets in a service for building simple admin pages?

155 points by jnord 3y ago

draw_down 3y ago

Who said every site should work without JS, even Figma? Honestly, who is saying that? Who is saying these things?

gumballindie 3y ago
I think the points in this blog are made up. No one with a bit of experience “believes” such things.
diggan 3y ago
> https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=%22should%20work%20without%20js%22&sort=byDate&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... (25 results) > https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=%22should%20work%20without%20javascript%22&sort=byDate&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... (28 results) So at least some are saying something along those lines. I'm sure if you search Xitter you'll find even more hits. I think the argument is usually not made in isolation like that though, and usually with exceptions. "Websites without heavy user interaction should work without JS", "Websites should work without JavaScript, unless based on live data" and so on, which makes a lot more sense.
- draw_down 3y ago
  [dead]
croisillon 3y ago
fyi you are shadowbanned, write hn an email to clear that up
brightball 3y ago
“Every” is a bit extreme but I’ve been a believer in Graceful Degradation for years. This is where jQuery excelled.
blackoil 3y ago
A ridiculously small but very vocal minority which is active on forums like HN.
ryanbrunner 3y ago
I tend to make all my pages function without Javascript even if I don't expect my users to turn off Javascript. It makes things easier to cover with automated tests if I can just exercise my backend servers with scripts vs. a headless browser, and if something does go wrong with serving Javascript or something it's nice to know my site is functional. Generally speaking the experience will be horrible (what should be a modal or a partial page reload will be a full reload) but using the technologies I use it's not that hard and it makes my development experience easier while delivering some (rarely needed) benefits to end users, so it's an unqualified win for my particular use case.

troupo 3y ago

While I agree with "web engine developers and web spec deveopers have little-to-no idea about web development" I disagree with "web browsers are good at handling complex and long-lived DOM trees with dynamic changes now"

hyperhello 3y ago
They are certainly better than before at handling the memory and bookkeeping of a large DOM tree. Every browser had so many unexplainable little bugs, but nowadays they can be relied on to correctly handle their own internal data without crashing. It’s a huge improvement.
diggan 3y ago
> "web browsers are good at handling complex and long-lived DOM trees with dynamic changes now" Is there an alternative renderer/something that handles "complex and long-lived $something-trees with dynamic changes" better than web engines does? They've been optimized for just that during decades at this point, with huge investments both in human-hours and money. Hard to imagine there is something else that can handle that better than browser engines.
- Const-me 3y ago
  On Windows, WPF is better: https://en.wikipedia.org/wiki/Windows_Presentation_Foundation https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio... The critical features missing from HTML are data binding and data templates. Last time I checked, many modern frontend frameworks contain overcomplicated, incomplete, and inefficient implementations of these features on top of HTML DOM.
  - diggan 3y ago
    I'm not super familiar with Microsoft's offerings, but is WPF available cross-platform? It's hard to argue something that is only on one platform is better when it only have to do 25% of what a cross-platform solution would do.

croisillon 3y ago

"it’s hard to imagine how [Figma and Photoshop for web] could work without JavaScript" is a bit of a strawman

ryanbrunner 3y ago

The refrain against the "we should go back to MPA apps with server rendered HTML" is often "well what about Figma and Photoshop", which of course, yes those don't really work in the MPA, server rendered HTML model. The problem isn't so much those but how most developers lump themselves in with the incredibly interactive sites because it sounds sexier and cooler to work on something complex than something simple. The phrase becomes "well, what about Figma and Photoshop (and my mostly CRUD SaaS)?" I think a valuable insight that the MPA / minimal JS crowd is bringing to the table is the idea is that you shouldn't strive for cool and complicated tools, you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can.

endisneigh 3y ago
> you should strive for the simplest tool possible, and even further, you should strive to make solutions that require the simplest tools possible whenever you can. Why do you believe this? I couldn’t disagree more. People should strive for the most effective tool, and most of the time that’s what they already know, unless some new tools’ efficacy outweighs cost to learn it
- ryanbrunner 3y ago
  Fair point that my point was overly reductive. But given you understand multiple tools, you should reach for the simplest tool possible to solve the problem. And in some cases you should still reach for the simplest tool possible even if you don't understand it yet. If you've only ever used Kubernetes but someone asks you to host a static HTML file at an address, you should learn how to use a simpler solution for that.
- Xeamek 3y ago
  >most of the time that’s what they already know, unless some new tools effficacy outweighs cost to learn it ....which any proponent of the new tool will argue it does
  - 3y ago

jefftk 3y ago

> As an example, the Eleventy documentation seems to avoid using client-side JavaScript for the most part. As Eleventy supports various templating languages it provides code samples in each of the different languages. Unfortunately, it doesn’t record which language you’ve selected so if your chosen language is not the default one, you are forced to change tabs on every single code sample. A little client-side JavaScript here would make the experience so much more pleasant for users. This may actually be an ePrivacy limitation (cookie law) not a desire to avoid JS. Persisting the setting across pages requires client size storage, which in ePrivacy countries requires either that the setting be obvious to the user that it's persisted, getting per-action consent (ex: a "preferred language" setting) or site-wide user consent (a cookie pop-up).

Gustek 3y ago
My understanding of ePrivacy (mostly GDPR) is that this kind of feature does not require consent. It's only features that would allow you for tracking of the user that require consent. Storing some setting in a local storage, never sending it to the server is fine. Things get a bit muddy when sending to server but even then you may not need a consent if it is a feature that is required for correct working of the website or better experience without tracking and profiling.
- diggan 3y ago
  This is correct. Unless it involves personal data and/or tracking the user somehow, then GDPR isn't relevant. Example: If you're storing lightOrDarkTheme in a cookie/localStorage, then there is no need to try to follow any directives, nor are you required to inform the user about that you're storing the preference.
- jefftk 3y ago
  GDPR and ePrivacy are different regulations. Under the latter even purely local data storage still requires consent unless it's "strictly necessary" to implement something the user has requested. For example, see the discussion the sibling commenter linked around storing UI customization choices for only the duration of the current session: https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2012/wp194_en.pdf https://ec.europa.eu/justice/article-29/documentation/opinio...

mjburgess 3y ago

> “Web development shouldn’t need a build step” Everything running in a browser is interpreted. There is no reason for webdev to require a build step, and it largely does so because JS standards haven't delivered anything around static typing. Even a "this syntax is valid but ignored" would enable IDEs to provide checks via LSPs, but for no-build running. Build steps and development iteration overhead is something to be avoided at all costs. For it to have been introduced, with multi-second latency, to web dev. is a sign of developer experience dropping off a cliff. Time-to-iterate, tool quality, release speed, etc. are essential to being able to build mental models of code (etc.)

toasted-subs 3y ago
Ease of deploying is a huge thing which gets lost. Over focusing on a single area of an application makes things really obvious the big picture was lost somewhere.
croes 3y ago
>Everything running in a browser is interpreted. That's exactly the reason for a build step. In a build step the code can be optimized to reduce and/or accelerate the code that needs to be interpreted.
- ryanbrunner 3y ago
  JS builds today do not appreciably accelerate code, and minimization is of marginal benefit when served assets are appropriately compressed using technologies browsers already support.
  - javcasas 3y ago
    No matter how fancy your compression, that code with comments stripped will compress to less bytes than the same code with comments.
    - vbezhenar 3y ago

JackMorgan 3y ago

Last month a client asked me to build them a crud form only using old school C# MVC with Razor templates. And by golly it was much harder for me than just doing it in React+Next. I had some nostalgic notion that MVC was going to be a smooth ride. That all this JS cruft was slowing me down. Then I needed a search bar, then validation, then I kept running into weird surprises with Razor templates. After a month I ruefully concluded I'd have gotten it done a heck of a lot faster just using my usual stack. I now regret all those times I complained about how much bloat there is in the JS ecosystem. Yes, is it possible to make crud apps with Razor, sure, people do it everyday. But for me, with a project with increasingly complex display logic and validation, I definitely should have tried a little harder to talk them into using Next and TS. As an aside, I was surprised that getting HMR with C# is kind of a pain. I never figured out how to get it while debugging. So every time I wanted to debug some new issue with the template not sending data right to the controller (which felt like every few seconds of work) I'd have to restart the server and wait 10+ seconds for it to restart and then renavigate to where I was, reenter my form fields, and then try again. After I was done and wanted HMR, I'd have to restart the server again. That extra hassle really started to grind on my patience.

onli 3y ago
The jump from JS to the microsoft world is always hard. Hell, jumping from anywhere into microsoft environments has to be hard. No surprise that it was a difficult transition if that wasn't in your background so far. The docs alone will cause a culture shock! > But for me, with a project with increasingly complex display logic and validation It always sucks if the requirements are not clear in the beginning, if the dev can't anticipate how they will grow in advance? But what has validation to do with it? That's completely backend, how would that have been easier with React+Next? > As an aside, I was surprised that getting HMR with C# is kind of a pain. Proper systems dynamically interpret their templates on every request in dev mode because of this, like Ruby/Sinatra does.
- tantalor 3y ago
  What is HMR? Is it edit/refresh?

zb3 3y ago

> Maybe 2024 will be the year where client-side Rust/WASM frontend frameworks start to get traction and if that’s the case, we’d better get used to having a build step! That's nonsense, there isn't any progress here. You're just rebuilding things that could easily be built 20 years ago, but with 10X the complexity. And then to solve slow load times your solution is to add even more complexity..

deleted 3y ago

[deleted]

mgaunard 3y ago

Reminds me of the fact that for a long time C++ compiler engineers didn't themselves write code in C++ or know best practices despite writing the implementation.

throwaway167 3y ago

2024 is the year of Rust and HTMX.

inopinatus 3y ago

The tech sector is riddled with such divisions of perspective. ”In a high-level language like C...” - chip designer ”In a low-level language like C...” - application programmer

graypegg 3y ago
“Riddled” has a tinge of negativity to it. I would say it’s actually a useful thing, “level” is a count of abstraction layers relative to the abstraction you’re familiar with. It’s more just a way to communicate some personal responsibility/knowledge range. I’ve heard people call Python “a low level way of using a computer” or similar.
- inopinatus 3y ago
  Riddles are also explanatory. The best programmer I ever worked with writes drivers for a hobby.
rramadass 3y ago
Anecdote: Coming from the application side i had always thought of C as a low-level language but in one company where i worked with chip designers who only did Verilog, i was gobsmacked when in my conversations with them they said they didn't know higher-level languages like C and cannot program in it.
- flashback2199 3y ago
  We're not gobsmacked when you don't know Verilog, so I'm not sure why you think you can be gobsmacked some chip designers don't know C...
  - rramadass 3y ago
    Because until that point i didn't know much about HDLs like Verilog/VHDL and how they were at a completely different level than "standard" programming languages like C/Python/etc. My then assumption was that since C was a low-level language and chip designers were working at a low-level they would be able to program in Assembly/C in their sleep and that they would be able to initiate me into the mysteries of how my C code was actually translated into electrical signals in the processor circuits. It was a big disappointment for me when i realized we were living in completely different worlds. I actually made a deal with some of them to teach them C/C++ in return for them teaching me Verilog/SystemC but unfortunately that never came to pass. I even got me a couple of Verilog/VHDL books and FPGAs to teach myself what i call "Actual and True Hardware Programming" but haven't really sat down with it. Hopefully sometime in the future so i can finally know everything from the bottom-most layer to the top-most.

bacro 3y ago

Recently I was reading the Learn CSS the pedantic way book and the definition for inline boxes did not match the way that anonymous block boxes were generated when an inline-level element had a block-level element as its child. So I went looking elsewhere for a more appropriate definition for that case and found this issue on standards: https://github.com/w3c/csswg-drafts/issues/1477 https://github.com/w3c/csswg-drafts/issues/1477 It was really interesting to know that I was not the only one confused. My question was: Does the inline-box generated by the inline-level element contains the box generated by the block-level child or there wasn't an inline-box that was a parent of them all but there were 2 siblings inline-level boxes of the block-level box that were wrapped in another anonymous block boxes? Reading that issue I got to know the concept of fragments, which I did not know browsers had. But the issue seems to suggest that the box tree for this case should have the inline-box as being a parent of the block-box. Which led me to another question, in that case, if I apply a border to the parent inline-level element, shouldn't it apply to the overall box that is generated (it does not)? The answer is that borders between block-boxes and inline-level boxes should not intersect but that is really difficult to derive from reading the standards alone. Anyway it was headache-inducing trying to learn the box-model pedantically :) I wish I could learn more about layout in browsers and I trying to read the code of LayoutNG in Chromium but I need more aspirin hehehe

imranhou 3y ago

If what the blog suggests are the optimal ways of doing it, it would have been a larger reality automatically by virtue of people continuing to try to optimize. Idealistic views aren’t necessarily practical, and may not get traction in the real world.

deleted 3y ago
[deleted]

danielvaughn 3y ago

> When I worked on animations, I was surprised at how many people believed that some animations “run on the GPU” (the browser can offload some animations to a separate process or thread that updates animations using the GPU to composite or even paint each frame but it doesn’t offload them to the GPU wholesale) Not to nitpick his nitpick, but...I've said this exact thing in the past, and his parenthesized explanation is what I meant. It's too much of a mouthful to try and be super accurate and specific all the time.

mostlylurks 3y ago

> “Web development shouldn’t need a build step” A build step is a huge barrier that makes authoring your own websites require significantly more expretise than it otherwise would. It thus makes web development less accessible, and puts anything even a little bit complicated out of reach of anyone who isn't already an experienced web developer or exceptionally dedicated. It also discourages the slow development of some pet website of a not-primarily-a-web-developer-by-trade into something more featureful, since expanding beyond the point where you can still reasonably avoid a build step suddenly requires acquiring a lot more exprertise and expending a lot of effort all in one go, instead of just being a smooth expansion into a more featureful project. The simpler it is to make your own website without having extensive web development experience, the more people will be able to have their own website instead of being directed to the endless array of corporate silos like social media (which has largely replaced personal websites) and corporate middlemen (which have largely replaced in-house commercial websites for smaller actors) that take care of the burden of making your own website for you, with some rather obvious downsides.

Yaina 3y ago
I mean, a build step is not required to build a website, but I'd say anyone who wants to have more than one HTML page and one stylesheet will probably want some sort of build step sooner rather than later. Like, if you have two or more pages, you probably want them to share the same header or footer, and unless you want to A) repeat the same markup on each page or B) inject them with a client-side script, you will need some sort of build step. There are more accessible solutions out there, like Hugo. How else are you going to achieve that? Sure you could use PHP, but I don't see how that is more accessible or maintainable than having a build step.
- dakna 3y ago
  > How else are you going to achieve that? People already thought about that problem when the World Wide Web was invented and they came up with Server Side Includes [0], a scripting standard that predates the Apache HTTP Server. Looks like this inside the HTML document:   Not many people use this anymore, but it is easy to share common markup and very accessible for people with just basic HTML knowledge. Major web servers of today still support it. [0] https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes.

lapcat 3y ago

The article title is actually "Weird things engineers believe about Web development".

5350-uiop-1130 3y ago

nothing wrong with build steps until they go wrong. then you will spend 5 hours replacing/updating deprecated/newly incompatible npm/system issues.

spcebar 3y ago
The horrifying guidance I've gotten a number of times when I step into a project is "downgrade your node version 5 years and never update anything."
- 5350-uiop-1130 3y ago
  a pragmatic solution. sometimes you don't have time and stakeholders don't understand or appreciate the side issues you need to deal with.

endisneigh 3y ago

Technology is not a religion and it doesn’t need prophets. Why are people so hell bent on convincing others to join them in their use of whatever technology? Pick what solves your problem. In the context of web development that overwhelming means using whatever is most popular given your preferred programming language.

butz 3y ago

It would be interesting to measure battery savings made by disabling JavaScript on mobile devices. While it might be cheaper to plop website on GitHub Pages or Netlify and others, somehow I feel that all costs are just handed down to the user in bandwidth and battery use.

rramadass 3y ago

Well written informative article. What does it say about this whole domain when, as the author says, Web Apps and Sites/Blogs (also add in Mobile apps) are so very different from each other using a myriad set of technologies each of which has a learning curve? Where is the uniformity and commonality in all this? Why are developers even perpetuating this? That said, this might be a good place to ask for recommendations for study since i am not a "Web Developer"; 1) Comprehensive books/other sources on full-stack Web App and Site development. Bonus points if they use a single language for frontend/backend/everything else. 2) The same as above but using C/C++ languages.

calderwoodra 3y ago
Businesses want uniformity and commonality since, in theory, it should lower development costs (see projects like flutter and fuschia, which have the goal to make every platform web based). The problem is that users/customers have higher expectations for their user experiences than the web can offer on mobile/desktop/etc. Robinhood, Duolingo, Slack are a few good examples of UX being huge differentiators.
- rramadass 3y ago
  I understand what you are saying but am not clear as to why it should be so. Having programmed GUI apps in Microsoft Windows and X-Windows/Motif (which can be remote) on Unix systems i am not sure why we cannot have a similar uniform architecture for "Web Apps". After all the "Browser" is considered a platform in itself. Also given that HTTP has now been munged into practically being a Transport protocol for anything, previous limitations are no longer an excuse.

amadeuspagel 3y ago

> There are Twitter/X polls, for example, but they tend to only be answered by the Web developers on the bleeding edge and are easily skewed by who spreads the word about the poll. Maybe MDN should have a comment section, like the PHP docs. That would be more representative.

omnimus 3y ago
The PHP docs comment section is pretty fascinating. I am not sure how these are allowed. But you will find 10year old comments with very distilled specific techniques or super well explained nuances. Not something i've seen in other languages.

cabalamat 3y ago

> Many didn’t know about new CSS features that had shipped 10 years ago. What’s more, even when we told them about them, they didn’t seem too excited. They were doing just fine with jQuery and WordPress, thank you. ...and if jQuery and WordPress do the job, they are sound technical decisions. What is not a sound technical decision is forever chasing the latest fashion in technology. Also known as the "oh look a shiny thing development paradigm".

bbor 3y ago

Absolutely fantastic writing —- clear, kind, authoritative. Don’t agree with it all but I think the last section sums it all up nicely, and is something I’ve felt for a while. With new SSR frameworks like Next.js, I think this whole MPA/SPA dichotomy starts to dissolve a little bit. I’m thrilled that browser standards are evolving to help it along!

eximius 3y ago

I don't mind a build step, per se, just that the JS ecosystem's build step is particularly more painful than others.

m3047 3y ago

I spend a lot of time with DNS (it just happened, man) and I see the same general thing where a lot of intention and expertise is imputed to others. True systems thinking around large systems is rare. Buffer Bloat (and the lack of progress in remediation, and the lawfare and near literal acts of congress due to misattribution and misunderstanding of the problem) as this thing slouches along and utters its phlegmatic growl could be emblematic.

g9yuayon 3y ago

I'd like to add another one: I don't need a separate NodeJS (or whatever engine) service to build my service dashboard. Before NodeJS got popular, backend engineers like me simply put web assets into a folder in my web app, so my service will have an admin page or a dashboard for per-node administrations. For some reason, such practice has become a taboo. My engineers have been insisting that they set up a separate NodeJS service just to build even a simple admin page. But I fail to see why. The reasons I got are usually these three: 1) a NodeJS service gives us optimized performance, though techniques like server-side rendering; 2) a separate service is easier to scale; 3) a separate service offers separation of concerns. However, 1) and 2) are premature optimization to me. All I need is standardized per-node admin page for my service. The QPS is probably one per day by a human. Why would I care about SSR or scalability at all? And 3) is quite hand-wavy. On the other hand, the overhead of managing a separate service as well as the dependencies brought by NodeJS' ecosystem seems high. So, what's wrong with the old way of having embedded web assets in a service for building simple admin pages?