Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

" I know this isn't actually true "

It's true.

A confluence of vague definitions, poor implementations, bad documentation ... and this is the web we have. It's the tip of the iceberg, and the painful life of anyone doing html5 work, it's 'not fun' for anyone who's been exposed to regular programming because the problems you spend your day solving mostly should not be problems to begin with.



I agree. I recently started learning front end development. My reaction after grasping what modern frameworks do is “my god, what have we done?” It seems like we’ve expended a huge amount of effort to hack the web into something we can build SPAs in (and what an insightful TLA that is).

I wonder if this sort of situation was inevitable or, given sufficient coordination and standardisation, we could have built a better platform. There are some problems that would have to be overcome regardless (eg arbitrary display size[1]) but languages like CSS and JavaScript look like very bad decisions.

My first instinct is that a new platform should be developed based as far as much as possible on tried and tested languages and technologies, but one that also allows for fast-paced browser dev and a path for future evolution.

For now I’m just embracing it and learning. It’s a lot of fun to see how the web works nowadays - I’m already beginning to understand some of the types of bugs that sites exhibit, and why designs are as they are. One of the outcomes has been to develop serious respect for the developers of MS and Google Web apps - eg OneNote on the web - as what they’ve achieved is pretty miraculous when you consider the stack. And those poor web browser devs!

[1] the idea of allowing arbitrary dimensions displays is a very strange one if you consider traditional graphic design; this may be an instance of us geeks making decisions that don’t make sense to more experienced professionals from other backgrounds. How much did graphic designers, UX experts, psychologists etc impact the evolution of the web standards? I don’t know.


"How much did graphic designers, UX experts, psychologists etc impact the evolution of the web standards?"

They didn't. It's just a mess.

We want to believe there is genius in the commons, but really I don't think there is a lot of coherence. It's just some small group thought it would be good to do this or that, and it made sense at the time.


This is what us older people would like to believe. Meanwhile the young webdevs are having a blast ignoring us and building the apps of the future.


Nah, it's mostly true (I'm one of those young webdevs), but I'd attribute the pain points in front-end development to slightly different problems than the state of browser inconsistencies and spec problems.

IME 70% of the problems people run into are self-inflicted due to overengineered solutions. I spend a lot of time lurking front-end IRC channels and most of the problems that get posted is stuff that I have never had trouble with, with libraries I'd never even consider using, that I don't have the first clue how to fix without going back to square one and re-engineering the solution from the ground up. The advice given by people that do attempt to help with these problems is often awful and creates more confusion.

For the most part, I don't think people realise that libraries add to the complexity of their software, rather than abstracting it away. Every front-end dev desperately needs to go and read the Law of Leaky Abstractions, because they're getting smoked by it on a daily basis and they don't realise.

The other 30% of problems come down to what GP mentioned, ambiguous specs, browser inconsistencies etc. Stuff like the relationship between x-overflow and y-overflow, little flexbox niggles like different behaviour depending on if flex-direction is set to row or column etc etc. This stuff can often be worked around with simple but unintuitive fixes (usually some fuckery with negative marigns and such), the two difficulties lie in discovering the solution to begin with (there's boatloads of bad and outdated advice everywhere), and running into these solutions when they haven't been properly documented (usually the case if some junior programmer has just ripped the hack off SO without understanding the theory behind it).

The secret to being good at front-end dev is to develop strategies to handle these problems, and to pick your resources very carefully (much as you would in any other ecosystem beset with noobs, like PHP back in the day).

I believe (based on my experience) that it's possible to build very successful software with very horrible engineering. Good and successful aren't necessarily synonymous in the world of big VC money. A great example is this: I need two hands to count the critical failure bugs I've run into with Uber's products in the last year. By critical failures I mean things that have flat out stopped me from being able to use it. I strongly suspect (a subset of) their engineering sucks (sorry to anyone here that works for them!). But hey, I don't own a squillion dollar company so what do I know? ;)


Yeah and then they all jump around React as some amazing achievement, having rediscovereed how 90's native UI do event handling.


React isn't really anything like 90s UI libraries. It is, however, very much like the fairly recent native immediate-mode GUIs that have come out (https://github.com/ocornut/imgui, https://github.com/PistonDevelopers/conrod, etc).

The core feature of React is that your UI is a pure function of your application state. In (e.g.) the Win32 UI, you would receive events, and then need to manually transition your current UI state to the new UI state (hide this button, disable this input, etc).


Smalltalk UIs used a pattern called dependency propagation to make objects update themselves based on system wide notifications.

Similar idea was used on Oberon System 3 Gadgets toolkit.

Also java.util.Observable based on the same Smalltalk ideas was already part of Java 1.0.


That's still event handling. You can do basic binding between outputs and values, but more macroscopic changes (closing a dialog, changing tabs, etc) requires tracking the state your UI is in, and manually transitioning.

This is markedly different than React, where the framework diffs the desired UI state (which is a pure function of your application state), and the actual UI state. The minimal number of UI operations necessary is then applied to make the latter match the former.

ImGui above works the same way, which makes it very popular for devtools in game development.


ImGui is quite similar to MS-DOS game UIs, before we migrated to Windows.

The source code of quite a few ones is available around the Net.


Event handling isn't special in React. One-way data flow and UI-as-a-function-of-state are. Which 90s native UI toolkits do that?



and think vi is great


> having a blast ignoring us and building the apps of the future

Building technical debt for the future I tend to think, which I guess is good for keeping future devs employed.


My experience is that young web-devs don't even know the dystopian matrix they live in, and when they discover 'regular programming', in many ways their perspective changes. Both web and regular dev have their faults but the the King of Byzantium is HTML5.


I take it you don't think much of the various libraries/indirection layers/frameworks that are meant to save you from browser-specific tuning?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: