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

Yes, 100 times yes if you are really delivering documents to the browser.

It is a totally different thing if one is delivering 'web application'.

Web application is about manipulating data, having lists, text fields and editing content.

Delivering documents is about documentation, blogs, prose, maybe just image browsing.

If company is crapping JS/tracking all over content that can be delivered as a document it is annoying.

Just don't say that everything should be sans JS - because there are legitimate uses of JS and even those heavy JS frameworks if one is building rich editing experience.



> It is a totally different thing if one is delivering 'web application'.

Why? I think the unspoken alternative to boring is gross negligent incompetence.

It really doesn’t have to be that way. The web is 30 years old, JavaScript is 25 years old, and the mature DOM is 23 years old. Surely by now somebody can figure out how to dynamically add text to the screen with less than 10mb of JS taking less than 10 seconds to execute.

As a counter point I have written an OS GUI that is 2mb unminified and loads in the browser in about 55ms (give or take 5ms) including full state restoration. That’s pretty fast. Looking at various benchmarks JavaScript is now executing as fast as Java in many micro-benchmarks.

If this stuff is really that fast why we do we tolerate such incompetence writing frontend code? It’s like incompetence is built in by default as the standard expectation and everybody hires accordingly.


IMO most of the complexity of the web comes from 2 shortcomings:

1 - It's hard to reuse HTML. Consequently, even static sites need some sort of build step.

2 - HTML needed something like htmx, so every component could be updated dynamically without writing JS code.

According to my estimations, if (1) and (2) were native to HTML, 93% of all websites wouldn't need JS.


I have been doing this a long time and one of the largest problems I encounter is an absence of basic communication skills. I look at your comment and see HTML is too hard and if we had something else it wouldn't be too hard. Too hard is empty defensive posturing that announces some form of gap, typically insufficient training/preparation. When people hear too hard they only see you and a goal with a giant mystery in the middle that you cannot articulate. Are you claiming people lack the proper training?


I wrote:

> It's hard to *reuse* HTML

And not:

> It's hard to use HTML

Anyhow, assuming you are not trolling, my point is: writing plain HTML is not productive, as I need to repeat myself all the time. I can't create my own abstractions for reuse, as I would in most programming languages.


HTML is not a programming language. HTML is a data structure as are JSON and YAML. Many people choose to solve for reuse with a programming language.


> Why? I think the unspoken alternative to boring is gross negligent incompetence.

That's.... that's just silly. How would you deliver, say, Trello as a boring website? Or Google Maps? Or Grafana? Do you really think the developers of these apps are grossly negligent?


Considering the "downhill quick" progression of Google Maps, that's perfectly possible, especially if we count the PMs along with the developers.

It's also not like Trello is some wonder of software engineering either (or that impressive functionality wise).


I spend 90+% of my time on the web reading and writing. Only 5 - 10% using web "apps".

The web stack leaned too heavily into application development, but its primary use is still in delivering rich text.


Regardless, why does the experience differ so significantly? It clearly isn’t due to execution speed of the technology. Is it a leadership problem, a training problem, or something else? What’s missing?


> That's.... that's just silly. How would you deliver, say, Trello as a boring website? Or Google Maps? Or Grafana? Do you really think the developers of these apps are grossly negligent?

Of those, I've used only Google Maps. Like Google itself, GMaps was great when it started! And they continue adding new knowledge to it that makes it more useful. But, like Google itself (though not as bad), when it comes to the interface it feels like there's mostly change just for the sake of change, with little thought given to whether it's good or bad change, so long as it's new.

(I compare it to the StackExchange empire, which seems to suffer a similar churn mostly for the sake of the appearance of motion and of novelty.)


> Surely by now somebody can figure out how to dynamically add text to the screen with less than 10mb of JS taking less than 10 seconds to execute.

Yes, we have that now. I made a tiny webpage for playing with substitution ciphers, all in client-side JS (and CSS): https://thaumasiotes.github.io/cryptogram/

Try putting text in the textarea on the left and see how long it takes for the page to update.


I still use only jquery "as a framework" and if I wasn't lazy could probably just move to more modern ecmascript. I stick to simple layouts and CSS and "POST" rather than make everything dynamic unless it absolutely needs to be. Of course I just work on my own and friends' websites and never really branched out from my day job of embedded coding.


You wrote OS GUI can't take that from you.

Who paid for that OS GUI? How often did the requirements change? How many stakeholders your OS GUI has? Is it done project or is it "constantly evolving"? If it is constantly evolving how many developers are working on it? What is team turnover or is it only you working on it?

It is easy to throw "gross negligence" when you work on some pet project where you don't have to change direction every week. You don't have 10 customers wanting things which are mutually exclusive.




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

Search: