Things engineers believe about Web development • Hacker News Board

Re: Things engineers believe about Web development

#41

Post by diggan » Sun, Jan 07, 2024, 1:40 PM UTC

Gustek wrote: post #20

jefftk wrote: post #7

> 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 JavaScr…

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 webs…

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.

Re: Things engineers believe about Web development

#42

Post by rezonant » Sun, Jan 07, 2024, 1:40 PM UTC

ryanbrunner wrote: post #38

The_Colonel wrote: post #31

Earlier quoted context omitted.

I think there's a similar dynamic as behind "nobody got fired for choosing Oracle" - it's safer to choose a more complex, but also more flexible technology. If you're a tech lead, your worst nightmare is when you have to say - "this is very difficult to do with the current stack. When we were choosing this stack, we assumed you'll never want these things". You're not going to extract a binding promise from product/bu…

Particularly with the web though, you're very rarely completely locked into one front end technology. It's 100% reasonable to say "this particular complex interaction should use React" without needing to port the entire application. I'm sure even Photoshop and Figma could build their account management or settings pages with MPA if they wanted to - I don't use them and have no idea if they do, but "some parts of my a…

Absolutely, but it's a matter of tradeoffs and where you place them. It's still plenty common to use an MPA framework like Rails or Django for the management or CMS portion of your solution, while using an SPA framework for your front presentation. It's much more acceptable to say "doing that for this staff workflow is hard to do with our stack" than "doing this for our customers is hard to do with our stack".

Re: Things engineers believe about Web development

#43

Post by diggan » Sun, Jan 07, 2024, 1:41 PM UTC

traverseda wrote: post #37

diggan wrote: post #25

Earlier quoted context omitted.

I don't think that workflow was even a realistic option when Figma development was initiated, or even when it first launched.

(300MB download warning) Here's an example of libreoffice running entirely in the browser: https://lab.allotropia.de/wasm/ Once it does it's painfully long download and bootstrap it works pretty nicely. This is a big complicated legacy app, but I'm sure if reasonable file sizes and graceful loading was an actual goal you could get some pretty good results. Sure, it's not going to be as easy to hire for right now, but…

Are you saying that that was built back in 2016/2017?

Re: Things engineers believe about Web development

#44

Post by seszett » Sun, Jan 07, 2024, 1:41 PM UTC

dustingetz wrote: post #14

ryanbrunner wrote: post #6

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…

"the problem" "you should" – this is the language of special interests developers are salarymaxxing first, second virtue signaling to support their case in their employers' selection process, third work-minimization and pain-minimization. Even the Simplicity Paladins are min/maxxing the same three priorities, perhaps weighing pain-minimization above salarymaxxing, yet still subject to the same invisible macro forces…

I feel like we live in completely different worlds.

Re: Things engineers believe about Web development

#45

Post by throwaway167 » Sun, Jan 07, 2024, 1:42 PM UTC

2024 is the year of Rust and HTMX.

Re: Things engineers believe about Web development

#46

Post by rezonant » Sun, Jan 07, 2024, 1:44 PM UTC

traverseda wrote: post #40

grose wrote: post #33

Earlier quoted context omitted.

I believe Figma is indeed written in C++ and uses emscripten. It's pretty much the polar opposite of your standard CRUD app. Old article: https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

Huh, Guess I was right :p So neither of those are a good argument in favour of these complicated javascript stacks, are they?

Just because Figma opted for this route doesn't make it right for all interactive web applications.

Re: Things engineers believe about Web development

#47

Post by croes » Sun, Jan 07, 2024, 1:44 PM UTC

mjburgess wrote: post #11

> “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…

>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.

Re: Things engineers believe about Web development

#48

Post by brightball » Sun, Jan 07, 2024, 1:44 PM UTC

draw_down wrote: post #4

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

“Every” is a bit extreme but I’ve been a believer in Graceful Degradation for years. This is where jQuery excelled.

Re: Things engineers believe about Web development

#49

Post by ryanbrunner » Sun, Jan 07, 2024, 1:45 PM UTC

rezonant wrote: post #39

The_Colonel wrote: post #31

Earlier quoted context omitted.

I think there's a similar dynamic as behind "nobody got fired for choosing Oracle" - it's safer to choose a more complex, but also more flexible technology. If you're a tech lead, your worst nightmare is when you have to say - "this is very difficult to do with the current stack. When we were choosing this stack, we assumed you'll never want these things". You're not going to extract a binding promise from product/bu…

This exactly. And with modern approaches (not that it's not without a fair amount of effort), you can achieve both an MPA style with SPA features via "isomorphic" JS (SSR).

The converse is also true, you can add a lot more interactivity than you used to in a server rendered HTML world with stuff like LiveView in Phoenix or Hotwire in the Rails world.

I think a good heuristic is looking at whether the UX of your app feels more multi-page or single page, that should be a pretty big factor in your decision.

Re: Things engineers believe about Web development

#50

Post by Const-me » Sun, Jan 07, 2024, 1:48 PM UTC

diggan wrote: post #10

troupo wrote: post #2

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"

> "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…

On Windows, WPF is better: 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.