Ask HN: Is web programming a series of hacks on hacks?

That's the first time I've heard that about React, can you elaborate?

Have you looked at the microservices craze lately? You need a new one of these each time you scratch your head.

This is because employers are demanding that candidates know the latest and greatest technologies (eg. looking for 5 years of experience in 1 year old technology). I'm an FE dev, and during my last round of interviewing 3-4 months ago I was asked about my thoughts on Redux, CSS Modules, Radium, Docker, GraphQL/Relay, ClojureScript/Om, etc.

If I need to be experienced with this stuff to stay employable because just doing my job isn't enough, then I'm going to learn it.

https://www.commitstrip.com/en/2016/07/11/a-bad-workman-blam...

Jokes aside, the history of mathematics is a pretty worthwhile subject to study to truly appreciate the importance and implications of tools (or mathematical discoveries in this case). There's a reason why it took humans 2000 years after Euclid first wrote his 'Elements' to discover non-euclidean geometry...

I'd say building Win32 GUIs in C++ was easier than current Web stack.

Same with Java AWT and Swing libraries.

Objective C / Cocoa is more complex - never really managed to learn it beyond basic stuff, maybe with Swift it's easier.

Elm is close to those desktop GUI frameworks, but functional instead of OO.

But Tcl/Tk is the most easiest GUI toolkit ever, too bad the resulting UI does not look professional.

However, displaying a modal window and handling messages in a local window-specific message loop is easy in Win32, and much more difficult in HTML/JS. In general, the browser makes it much more difficult to deal with synchronous operations like modal windows and server requests that require the application to wait on the response. This is how you end up with the overly-complicated mess that is callback-hell, which is then solved by another overly-complicated mess called promises.

So, presentation functionality = A+, foundational functionality for UIs = D.

The problem now is nobody can rationally understand the complexity. At least that was known before.

Perhaps the language may have been a barrier to some back in the day, but complexity vastly transcends that small issue.

The initial learning curve was higher, but once you had that knowledge it remained correct and relevant for years- sometimes decades.

And your application UX was faster and smoother. The minor lag between user interaction and UI action that we take as a given today in all but the most basic applications simply didn't exist if you wrote your UI to conform with the platform guidelines.

Even poor performing complex UIs typically did better than today's well written complex UIs - on hardware quite a bit less capable.

We've accepted he current hodgepodge because of portability, but if you've ever worked with the base platforms for any length of time , the difference is painfully clear.

This doesn't touch on how you could expect a consistent ui experience across all applications on an entire platform. It's hard to get that across even two web sites.

We are currently well into a full generation of developers and consumers who are unaware of what's being lost, because most of their interactions are with browser base applications and mobile phones. Waiting a few dozen to a few hundred extra ms for ui to respond is considered normal, if it's noticed at all.

I'll answer that: every single one. I haven't ever seen a GUI system more complicated than the HTML/CSS/JS mess. The problem with these is that at first glance they look easy. Doing 'hello world' in HTML is little more than actually typing 'Hello world'. They only become a mess if you try to do something reasonably complex. The end result of this is that there are many people who start out with HTML and stick with it. They simply never experienced anything different.

> Why then so many devs choose to use WebBrowser wrappers to render their desktop/mobile UIs because it's way faster and easier to develop with?

No, it's cheaper to develop with. There are many more 'web developers' out there than mobile developers and they are usually very cheap to hire. The goal of corporations is not to build the best UI or to use the best tools, it is to make the most profit. A web-UI is usually considered good-enough by the suits and web 'developers' are a dime a dozen.

The answer to your second question is manyfold. First, it makes a false presupposition, web development is not faster and easier. Second, most devs probably chose the browser as a platform because Apple was so tremendously successful at creating artificial "application barriers" -- making it uneconomical, problematic or even impossible to create well-behaving cross-platform applications. Building application barriers used to be Microsoft's primary concern (they invented the term for internal correspondence), they fought hard against Sun's original vision of Java, but has become Apple's main trump card for while, after Apple decided to give up making great and innovative hardware. Third, mobile apps became sexy but the fragmentation is too high (even just Android is way too fragmented).

So many devs and companies bite the bullet and decided to make a web page for desktop and mobile phones/tablets as a least common denominator.

If you disagree, show me one non-trivial web application with the performance and a user interface that matches or outscores a corresponding native application, and we can discuss why it's better than the rest and an exception. So far, I haven't seen a single example but there should be one or two.

We old timers have native experience.

Many of those that use WebBrowser wrappers never used anything else other than web tools and aren't even aware of the RAD tooling we used like Delphi, for example.

There is the Unix Hater's Handbook (http://web.mit.edu/~simsong/www/ugh.pdf).

However, Unix doesn't suck half as bad as web development. Web development keeps a lot of problems alive that have been overcome in Unix development and everywhere else.

Like, most game dev frameworks (especially for mobile) leave you with device-level looping, under language-level looping, under framework-level looping, under code-level looping. This, obviously, is hell.

The result is that something as simple as "play this sound file, looping when finished" ranges from awkward to literally impossible. Memory access, garbage collection, and framework timing all collide and leave you with mysterious multi-second gaps while everything tries to sync up. And so everyone building something serious has to dive down past LibGDX into awful, ground-level things like Hammer or un-frameworked C++/Java/etc.

I'm not sure what the cure is - unlike a AAA game, there's room for a tiny bit of inefficiency in a webpage. 0.1-0.5 second loads are reasonable, instead of 0.01 second frame renders. But right now the endless layers are spitting out far too many 10 second load times, and no one even seems to notice the redundancy.

I've been programming since before the web was invented. The web, as a development platform, is the worst layer-cake of kludges I've ever seen.

Ref: https://medium.com/javascript-scene/what-is-webassembly-the-...

All these javascript and css transpilers however, they force you to know the higher level, the lower level and many of the intricacies of how one translates to the other.

(Oh, BTW, JavaZone 2016 was Oracle-free and all talks seems to have been uploaded to vimeo with no restrictions on downloading.)

The computer for the Apollo missions had approximately 64Kbyte of memory and operated at 0.043MHz. My wrist-watch is many orders of magnitude more powerful than that. But the programming effort that went into it was huge (literally: https://cdn-images-1.medium.com/max/800/1*qJnPOGdtk1q7dq17tx... ). If we were stilling coding things that way, we might be able to go to the moon but we wouldn't have self-driving cars.

> Pick a language, any language, and then restrict yourself to features only ten years old.

C# 2.0 in 2006 added:

    Generics
    Partial types
    Anonymous methods
    Iterators
    Nullable types
    Getter/setter separate accessibility
    Method group conversions (delegates)
    Co- and Contra-variance for delegates
    Static classes
    Delegate inference

JavaScript is so far away from this it's not even funny. It doesn't even have proper numeric types. It's casting rules compare favorably with PHP!

So I don't buy the argument that JavaScript isn't suitable for large projects because browser makers aren't keeping up with the latest standards. JavaScript is a scripting language that's been pushed into tasks it's not suitable for because it is everywhere.

Slack and atom though? Both are simple client UI's and both have much less bloated alternatives.

As a side note, when I read this, I thought you forgot a word. Then I realized expanding the contraction yields a complete sentence.

Interesting choice of construction. Out of curiosity, is English your first language?

1. And it certainly was fun - HyperNeWS was brilliant (e.g. I remember drawing a "broken window" of multiple unconnected parts, pasting it as the shape of a terminal window and everything continued to work - this was '91 or '92).

Also I vaguely remember logging into another users environment and manually tweaking the transformation matrix for the terminal window they were using to rotate it very slightly as they were working...

It's better to have everyone experimenting, blogging and doing their thing, and the best ideas rise to the top.

2015 was probably the worst time to be a web developer on a greenfield project. You had Angular deprecation and the Flux wars, and Babel 5 -> 6 migration.

I do agree its a mess and a freaking nightmare most of the time. I've spent hundreds of hours setting my toolchain up and if something like webpack were to lose favour, I would be devastated.

I think we are in need of a Rails for modern JS. My prediction is that we will see this emerge soon. A shift from project-templates to simple, generic plugin system. Webpack seems quite strong as the packager. Angular 2 CLI just migrated to webpack from Brocolli for example. React and Redux are standard now. And npm is the package manager of choice.

[0] http://blog.runnable.com/post/149000201856/think-before-you-...

[1] if you haven't used angular, ask someone who has

[0] http://blog.runnable.com/post/149000201856/think-before-you-...

[1] if you haven't used angular, ask someone who has

If we're going to count frameworks, there'd be no end it. As I once said, programming is abstraction upon abstraction.

Like an onion, a Russia doll or better still, inception.

Frameworks abound everywhere, at every layer. You just need to adjust your scope as you see fit, to find them.

Lots of projects are already doing this: Elm, ClojureScript, PureScript, etc.

    const results = await sql.query`
      SELECT ...
      WHERE foo = ${bar}
    `;

    if (!results && results.length) return;
    await myQueue.add(results);

The syntax/semantics/instructions option seems like a way better basis. And honestly, most of us can get by with a Potter Stewart style standard of "know it when I see it".

Just like with C++ you don't have to use all of those fancy features. You can use CSS as simply properties on many web applications. They can be as complex or as simple as need be.

> With respect, almost everyone else in this thread seems to disagree with you. I'd challenge you to find a major public-facing web app written with - let's be charitable - fewer than two of the frameworks on that list.

I actually work on one during my day job that is used by millions of people :). Though in fairness we're transitioning to a single framework rather than the hand rolled one.

Frameworks have their use cases. Native also has its. For whatever reason people today are taught they have to use at least one otherwise they're throwing their time away or they can't interoperate with others which are both not true.

I'm beginning to think I need to work on a web series around creating web applications without frameworks.

> I do tend to agree with you on the merits of SQL, though. We built a very simple database for Anvil, that doesn't do anything except store and retrieve tuples of data, and for anything more complicated, we say "great, SQL is over there" :-P

This seems to be the exact type of scenario I've seen played out countless times in my career but the easy start of ORMs sucks people in every time (though I honestly think starting without an ORM is also super simple but I think many of them abstract away schemas which, if you just want to jump into something, can seemingly get in the way.

HTML is akin to translating. I know devs who have done front end for 20 years who can't begin to wrap their heads around scripting because it's not just wrapping text in brackets to translate to a screen, but they can pull of tricks in CSS like a shark breathes water. Yes, CSS is a mess and I think a lot of that was trial and error and needs to be standardized, but it's an example still of working to make something that is already there do its job better rather than making something new and shiny to replace it so you can add another language to your portfolio.