JavaScript - Dynamically typed, does not scale what so ever. Code written in it becomes 'read only' very quickly. Impossible to refactor.

CSS - Also becomes impossible to manage. Who knows if the class you wrote is or isn't being used in HTML or JavaScript somewhere. Same problem, read-only, it only gets bigger and more unmanageable.

HTML - At the heart of it, the foundation is the layout engine and positioning, and it sucks. Flexbox was supposed to bring sanity, but I feel like we're still waiting on it.

Put these three stooges together and you get where we are today. Rewriting the same damn app every year in another framework in what can only be described as some sort of high paying purgatory.

    * HTML
    * CSS
    * JS
    * A server-side language (eg Python)
    * SQL

    * A framework to make JS bearable (eg Angular)
    * A framework to make server-side bearable (eg Django)
    * A framework to make CSS bearable (eg Bootstrap)

    * A framework to make SQL bearable (eg SQLAlchemy...)

Trying to fix this, at least for simple apps, is why we built Anvil - https://anvil.works - where everything is in Python, and the GUI is drag'n'drop.

And the result, of course, is an unmaintainable stack of dependencies and inefficiencies. Any time anything changes, anywhere, the whole thing falls apart again.

Security folks talk about "threat surface" - I wonder if it would help to have an idea of "development surface" to signify the risks of bloat and dependency chaining?

Node allows you to run isomorphic JavaScript that runs on both your server side and client side (to ensure you don't end up with the Angular-style skeleton pages coming from the server), You can pick a nice ORM (like sequelize) to abstract away SQL, and Webpack allows modules to specify their styles in JavaScript to allow compossible CSS for each given page.

Yes this is still using a couple of frameworks, but I personally prefer the approach of a lightweight standard library to the everything-and-the-kitchen-sink approach that other languages have.

But then you're writing JavaScript on the server side, and I think I'd rather shove live weasels down my trousers than write one line more of JavaScript than I absolutely must.

In JavaScript, `4 / "cake"` returns `NaN`, which is sensible, but if I wanted to check whether I just accidentally did a bad division, `(4 / "cake") === NaN` will lie to me.

There are LOTS of quirks like this. JS is like a floor with boards missing all over the place. Yes, if you've walked on it every day for years, you've already stepped in every hole and know where they are. But that doesn't make it a good floor.

A good language is consistent. JS is not.

The fact that it now has fast implementations has nothing to do with it. This car goes 300mph, but don't use the left turn signal on Tuesdays because that sucker will blow you up.

Uh, so two things here. First, even though it's a dynamic language you should know what your code is doing. Your code should never be be "accidentally" doing this. That would be very poor design outside of an accidental bug.

Second, some other dynamic languages do this or other weird type coercion (I mean type coercion exists for a reason; sounds like you're against it in general which is separate from JavaScript). PHP simply extracts numbers from strings and uses them in this case. Many languages use + as a concatenation operator JavaScript just doesn't have a good way to override it so it could work properly in all cases.

> In JavaScript, `4 / "cake"` returns `NaN`, which is sensible, but if I wanted to check whether I just accidentally did a bad division, `(4 / "cake") === NaN` will lie to me.

It's not lying to you; you're using a feature of the language wrong. That's like calling the wrong validation function and getting upset because it's not working like you wanted it to (because there is a validation function for NaN). At the same time a good design won't run into this issue anyway. Now I'll admit NaN is a bit of an oddball so yes it's not the most intuitive but at the same time don't say the language is lying to you.

> There are LOTS of quirks like this. JS is like a floor with boards missing all over the place. Yes, if you've walked on it every day for years, you've already stepped in every hole and know where they are. But that doesn't make it a good floor.

> A good language is consistent. JS is not.

Not really. This is the common statement repeated by those who don't use JavaScript and consider it an awful language. If you're following best practices I'd love to know where all these language quirks or inconsistencies are because I'm for sure not running into them.

> 0.0/0.0 == Double.NaN

false

Sure, there are features that JavaScript lacks compared to other object-oriented languages, but saying that it's not object-oriented is like saying that it's statically typed. It's just wrong, the language is full of objects.

And in Javascript, it's still a nightmare importing a file. You either have a or you are on nodejs.

I'm gonna stop you right there. Node is a helpful tool and I enjoy using it, but Sequelize was nothing but pure pain when I used it. You're much better off running raw SQL, or using a query builder like KnexJS.

I would never use Sequelize for more than a 1-table read or update.

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

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

The backtick feature in ES2015 is really cool and allows for some great DSL type features.

[1] https://www.npmjs.com/package/mssql-ng

(React, Node, sequelize, I'm not counting webpack but I probably would if it's anything like as much of a pain as Grunt or Gulp or... And as you say, this is the lightweight version.)

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.

More to the point, .NET was designed from the get go as an enterprise programming language. The web was not designed from the beginning to be a universal application platform, it was designed to display formatted hyperlinked text. Much of the hack-y feel of today's web development -- as well as other aspects such as the rather poor security -- springs from this. If the web were designed from the get-go to be a universal sandboxed application platform, I feel that many things (ranging from the scripting language choice to the DOM model) would have looked a lot different today. Standard, non interactive HTML + CSS (what the web was designed for) certainly doesn't feel too hacky after all.

Prefer winform? That's much like react without using jsx, and if yoy want fancy graphics is much more complicated than html. Now sure you can stick to system style, but you can also buy css themes, use bootstrap, material ui frameworks to have your already prepared ui in html too.

Same issues with qt libraries... The thing is simple: inevitably you need more layer of complexity if you need to be able to maintain the code while being open to changes.

For simple apps, sure winform is faster, for complex apps, no way, it's the same.

And you can't really say that.net is a single framework when it includes so much stuff that is bigger than react, node, webpack, css and html put together

Web programming is more fragmented in nature, for better or worse. I think that was more my point with the first paragraph (and also a response that most .NET programmers don't need to care too much about any backbone frameworks .NET was built on). .NET provides you with a full front-to-back ecosystem. With web applications, you usually chose, at minimum, some form of Javascript framework, some back end framework, and some form of style framework. (Full stack frameworks for some reason have not taken off in the web ecosystem.) Even that description simplifies some of the fragmentation, due to the bewildering amount of choice. If you want to implement a Flux pattern in React for instance, there are over a dozen versions out there to chose from.

I don't think this necessarily says anything about app complexity or speed of development at all, agreed. Complex apps are going to be the same. I do think that the current fragmented, churn-y nature of the Javascript ecosystem can be a barrier to entry for simple apps at the moment; for that reason, I'll welcome the day when the Javascript ecosystem reaches peak "Javascript fatigue", becomes a bit more stabilized.

Also, if you need a backend even if it's written in same language, is still a different thing, much like node and web javascript. Choosing a different backend languages usually is made because of the advantages it brings (Rails for prototyping, Erlang or Elixir for stability, Java for performance and so on)

- WPF, WinForms, ASP.NET, ADO.NET etc. etc. are all officially part of the .NET Framework.

- WPF doesn't do much (or any) direct interaction with Win32. It uses Direct#D for rendering.

- The CLR is the .NET equivalent of the JVM.

It's useful to look at the .NET Framework the same way as the standard library that ships with the JVM. They're both large standard libraries that include GUI Library (AWT, Swing, JavaFX, Winforms, WPF), database access (JDBC, ADO.NET).

In both cases, the extensive standard library can easily be used by multiple languages (i.e. VB, C#, F# in .NET, Java, Scala, Clojure and many others on the JVM).

SQL already is an abstraction, why would I want to abstract it away? Why not abstract JS away instead?

Funny story, that's how I've been describing the issue with how errors have been handled on the project I'm working on, where there are SO many areas where errors are just ignored... so they don't propagate up the chain/stack... doubly annoying in a node environment where it's all supposed to be error first (as in the first thing you think about and check for).

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

250mb worth of dependecies later...

That comes at a cost, namely when someone has a special requirement, then that person has to dig very deep into your framework.

It's almost the same like Java GWT or Vaddin. If you stick to the recommended way, everything is just fine, but don't ever try to solve some exceptional problem because then you are in a world of pain where it's just smarter to embrace JS and CSS.

The problem is, abstracting things away doesn't make them disappear, because WEB DEVELOPMENT IS BROKEN BY DESIGN.

I never used your app nor do I know how it behaves, this is just general speaking about the scenario when people try to 'abstract' things away, I hope you understand that I'm not speaking about your app but the idea of hiding things.

The sames goes for all those frameworks who tried to hide HTTP ( I'm looking at you asp.net and some older Java frameworks ), this lead to a pile of shit, newer frameworks accept the fact that we use HTTP and we got less problems by doing that.

Since you mentioned ORM's, it's called the Vietnam of computer science[0], everyone tries to hide SQL, if you are doing some basic CRUD applications everything is fine but if you need more sophisticated queries you are already fighting the ORM which is supposed to help you and not making you developer life miserable, we don't need another DSL for databases, SQL is already the best language to make queries.

I guess, what I'm trying to point out here is that I use those simple tools because I know my way around, I know how to debug it which wouldn't be possible with some abstraction.

[0] https://blog.codinghorror.com/object-relational-mapping-is-t...

The tradeoff is that if you want to use an obscure feature of the underlying platform (and boy does the web have those), you need to explicitly abandon our abstraction. There's always an escape hatch for this - you can drop down and write HTML/JS/CSS if you need to. (And something similar on the server side too.)

All abstractions leak. Anvil leaks deliberately and rarely, whereas abstractions built in the classic HTML/JS/CSS world leak constantly and unpredictably. We think that's worth the trade-off.

I haven't done it myself, but you could try to replace most of your stack from the database up, with a single language:

http://www.swi-prolog.org/FAQ/PrologLAMP.txt

You'll still need the three stooges but at least you'll have a single language behind them.

If you're going to call HTML a programming language than when you talk about server-side work you must include XML as a programming language (I see markup far different, more simplistic than a programming language). CSS is simply properties applied to the same markup but I digress; I could see the argument argued either way.

Regardless, you can minimize what you're saying down to just HTML, CSS and a server-side language. You can make good applications without a single line of JavaScript and depending on your purpose you may not need persistent storage in the backend. In fact you can write an entire web application with just HTML, CSS and JS if you want and have no backend (beyond a CDN unless you want to be super pedantic and call that a "backend" but I think that would exceptionally overstate what it does).

> And then come the (leaky) abstractions on top of them:

God, you don't need any of these. JS isn't that bad anymore. It's actually kinda nice in some ways. Same with CSS it's rather easy and there are far lighter projects than bootstrap if you want to do minimal stuff, quickly (but there isn't any reason you can't look at tutorials if you're new and get a CSS layout working pretty quickly sans framework).

For server side this depends on your language. Node has a great built in http capability that many seem to ignore (it's quite easy to write your own web server using it; in fact it doesn't take much more code than plugging into express or hapi). Alternatively other languages have even better, built-in ways of handling server-side logic.

> ...and often...

Ugh, SQL is so easy I don't understand why people even bother with these. Every single time I've been involved in a team that used these abstractions it worked great initially and then steered us off a cliff in the end.

Just don't. RDMS is easy.

Whatever they are, they're complicated. They've each got syntax, enormous sets of tags/keywords to learn, and quirks coming out of their ears. There are even people down-thread pointing out that HTML+CSS is Turing complete.

> God, you don't need any of these [abstractions]

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

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.

five languages in 7 lines of code -- how now to do web development : https://news.ycombinator.com/item?id=492321

We might need less abstraction, and let the engineers work that out.

Front-end on the other end is a mess. JS/HTML/CSS as tools are clearly unfit for the current needs.

Front-end frameworks tend to move laterally; e.g. implementing a new design pattern or changing the workflow with an existing API.

Back-End frameworks tend to move vertically; e.g. adding new features or abstractions and developing generic bootstrapping procedures.

I'm glad you brought up Django here. I work with Django as my primary back-end. I think it does a great job abstracting the stuff you don't normally need to worry about while persisting the ability to modify it if need be. It seems like every update to Django is designed to make the developer's life easier. It doesn't require complicated build tools. It has a built in dev server. It includes a fantastic and secure ORM. It has it's own easy to use templating language. You can build an entire web application with Django and no 3rd-party packages if you wanted to. Contrast that with something like Node/Express/whatever and you can see the two different camps of developers a bit more clearly.

Sure, maybe my Python runtime is slightly slower than a Node runtime. Maybe the lack of async request handling(not really a problem with channels or celery) means I can't handle as many concurrent requests. Here's the thing. Hardware is cheaper than developer time. If I have an overloaded server, I can just spin up another with the push of a button and pay 10 bucks to run it for a whole month. 10 bucks is like 20 minutes of developer pay.

That's not to knock on Node, it has it's use cases, but the ecosystem it exists in is one of infinite dependencies and breaking changes.

In conclusion, I think back-end frameworks do change. I believe that changes to back-end frameworks have a different velocity to those on the front-end. I also believe that the changes made are a direct result of a framework's ecosystem. I hope that made sense.

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.

I don't want to knock these tools too hard, because I can readily believe that (eg) Flow, or Typescript, or whatever we'll all be using next week, is much better than using vanilla JS/CSS. But the fact that we need to know all of Flow, and all of JS, and all of bootstrap, and all of CSS, and we're still not even off the client yet, is exactly why the web is a mess.

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.

Back in 2009, I worked on a complex SPA using GWT. With GWT, you could pretend to know nothing about HTML/CSS by just using the ugly build in components, but none of the GWT users I met did that. Our app used a Model-View-Presenter structure, dependency injection, and event bus for asynchronous communication to let components know when their data had updated, plus UIBinder templates for defining the look of components (which are mostly just HTML and CSS). So although it was nicely structured, it was very much a web app, and the development experience felt pretty comparable to what I experience in React today.

XAML is mostly just a way to declaratively specify the layout and structure of UI components. Actually, I think it's just a declarative syntax for creating a hierarchy of object instances. If I remember correctly, the XAML and its corresponding C# file are both partial implementations of the same class, since .NET allows partial classes.

Now, I'm not saying that I think the current state of JavaScript tooling is the worst thing ever. But I do think that that some of the 2009-2010 era JavaScript frameworks provided a more sane and cohesive development experience. React and Angular are nice, but I also remember that in 2010 it felt pretty neat to create an interface in OSX's Interface Builder, and have it show up in my browser exactly the way I'd drawn it.

By XAML I guess I mean WPF or whatever it is called. The bet was that Silverlight would be installed in every browser and you could build more powerful apps. I remember reading a post about how Evernote rewrote their WPF app because performance was never good enough.

GWT tried to make a nicer API for building UIs. The API was nice, but I guess the whole transpilation caused issues with debugging etc.

---

HTML, JS, CSS is evolving in such unpredictable ways, each time getting better and better. It just has such a large community using it and experimenting with it all the time - I don't think anyone can compete with the hive mind of web devs.

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

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

It's also more difficult to follow practices like quickly rendering above the fold content; when you use the normal practice of writing re-usable directives, you end up needing to wait until at least Angular and any dependencies are loaded prior to being able to render any content at all. Server side rendering of initial content helps to alleviate that quite a bit since even though the content may not be interactive until your app bootstraps, the perceived load time is much better as the user has something to look at.

We just need to standardize the glue...

Once we've completely made the ES2015 transition (at least for front end modules), we might be in a position to see some really great front end tooling.

But after reading the justification it will be better in the long run.

We just need some way to lazy load modules.

The approach itself yielded the issues such as that you reference, which have only been partially resolved by subsequent iterations of the same approach. I don't believe we should give credit for an approach that yields what is still a net-negative.

It's a new thinking that we need, not reluctant acceptance of the best sub optimal execution the old thinking can deliver.

Five or six competing frameworks that do the same thing in different, incompatible ways, because either the guy who understood EXT-JS left the company or one group like jQuery better than DOJO and they both went off to do their own things only to be brought back together later.

Many languages (in the formal sense) aren't Turing complete, so this certainly isn't a requirement to be a formal language. It would be odd to come up with a definition of language that excludes regular languages, for example.

TBF you did say "programming language", not just "language". But once we move from the mathematical setting of formal languages into the informal engineering setting of programming languages, I don't see why a formal concept such as Turing completeness should be the deciding criterion for what constitutes a programming language.

I think a more reasonable criterion is that a programming language needs to have at least 1) a syntax; 2) a semantics or an implementation that could, with enough effort, be given a semantics; and 3) whose primary use is giving instructions to some computational machine (Turing or otherwise).

According to this criterion, SQL is certainly a language.

If you think about it for a moment, HTML and CSS are perfectly reasonable languages as well. Their semantics, however hairy, would be given for instance terms of manipulating objects in R^2.

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

As does SQL : http://stackoverflow.com/questions/900055/is-sql-or-even-tsq...

I have also found that CSS becomes a lot more tolerable with CSS Modules, in combination with React, which allows you to write CSS that targets one component and only that component. By eschewing cascading, you can finally write modular, reusable CSS that avoids side effects and still allows fine-tuning (overriding) by the component user.

There should be something in the license of JavaScript frameworks & libraries to prevent them from being used in blogs, newspapers, trade publications etc :-/

For now all innovations in JS just seems to provide us with even heavier web sites for no real benefits. I feel I'm starting to dislike JS the way I disliked Flash which would be quite a feat.

Of course, nobody does this in practice.

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

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 made this comment in another thread, but it fits right into this one too.

also

http://www.windows93.net

> teetering Jenga tower of hacks?

How is any programming language not capable of being brittle?

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.

Unlike many other web programming approaches -- this stack should help avoid the need to invent new hacks for every new feature or slightly different situation ...

A big design mistake was the global cascading/inheritance system. It's a huge pain to write CSS that doesn't leak into nooks and crannies where it shouldn't. CSS is supposed to be modular, but you can't just import someone's stylesheet (e.g. for embedding something in your page, like a video player) and trust that it won't override everything around you, intentionally or accidentally.

More than that, CSS was designed for "styling documents" — the idea being that you could display the same document with different stylesheets, sort of like themes, and so the stylesheet obviously had to be separate from the document. But almost nobody who uses CSS these days do it to "style" anything, let alone "documents". One particularly egregious issue coming from this design is the attempt to separate layout from content, when in truth layout is content, and for pretty much any application today, the style is also content. We're well beyond the point where an HTML document can be "semantic".

Shadow DOM may be the way forward in the future, but CSS Modules is a nice stopgap solution, at least, and you can use them with React + PostCSS (+ SASS) + Webpack in a nicely seamless way, without requiring any browser support.

Proper abstractions are supposed to compress large bundles of information into a smaller set of [broad] concepts, which then imply all the large sets of details they're abstracting away. High level languages are pretty good abstractions on top of raw assembly code for example, because you don't have to think about what the assembly for your java code is going to look like, it's already implied that it's going to work.

As for react, I'm also not a huge fan, but that's because it's still a relatively leaky abstraction that comes with a lot of the same baggage as plain js+html+css. Especially when compared to a fuller abstraction like Elm[0]. But even that's still lacking a complete abstraction of html/css stuff. And that's not even taking the leaky abstractions on the backend side of the equation into account:

http://haskell-web.blogspot.com/2014/04/towards-deeper-integ...

[0] http://elm-lang.org/

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

* DOM,

* HTML Layout,

* CSS,

* A small variety of crappy events ( onDomLoaded ),

* a fairly rubbish heavyweight communication layer ( AJAX )

* Keyboard bindings that never work cross app, never cross platform

* Accessibility ??

* No idea of the energy impact of your code

* No ability to do queries on important device metrics ( energy consumption, clipboard, user presence, login / logoff, single sign on )

* History management and back button mess

Tis a trick question. The actual complexity experienced by humans depends on the job they are trying to do with the object. If you are a botanist/arborist driving to work, then clearly it is the apple. If you are a mechanic on your lunch break, then clearly it is the engine.

It's true that abstractions can lead to a lot of trouble when they are failing to work correctly. But when they are good they add a lot of good value. When did you last have to debug a system call, because you couldn't open a file? There are really good, old abstractions that no one thinks about anymore, since they're just really good.

A framework in web development is of course another matter, where complexity can sometimes be staggering. I believe that the lifecycle of React components is really nice. Instead of initialising X things you can think about how a single component will change over time.

There are endless examples of good and bad abstractions, I guess. But at the end of the day, we have to choose abstractions when we need them to reason about what we're doing, despite adding more points of failures.

After all, if an abstraction just enables us to think faster and more clearly about a problem, AND allows us to write less code, that means that less bugs will be in the final product, assuming that the density of bugs is constant. ;)

C -> ASM / byte code -> machine code -> primitive CPU operations

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.

The problem that haunts me -and a lot of other hackers I presume- is that we have this urge to understand every little detail of the systems we design. Nothing is good enough.

The other problem is that by using arcane and primitive tools we limit ourselves in the ability of producing real work. As with everything in life, we need to make the distinction between tinkering and doing real work.

If all we do is tinker, very little gets done :).

PS: I just read the satire Real Programmers Don't Use Pascal [1], my comment could be highly biased from that.

[1]: http://www.pbm.com/~lindahl/real.programmers.html Bonus: Here is a little bookmarklet I wrote for styling unstyled html pages for easier reading.

  javascript:(function() { document.body.style.maxWidth='700px'; document.body.style.margin='0 auto'; document.body.style.lineHeight='1.5'; document.body.style.fontSize='20px';} )();

But hey man, that's just like your opinion.

Programming is supposed to be about creating platforms for each other so we can continue solving higher (and higher) level problems. This web crap has us stuck fighting in the mud going nowhere.

HTML and CSS aren't as complex as those. Not even close

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.

I will have to vehemently disagree. I have no experience with Win32 GUIs, but I still have nightmares about wrangling nested LayoutManagers: comparing that to the current state of the web (especially after Flexbox) is downright absurd.

I am very happy with: Typescript + (Sass|LESS) + framework (Angular|Bootstrap|ReactJS). I think the 'hardcore' devs who would rather avoid using abstractions (frameworks/JS transpilers) will have a torrid time with the front-end.

My two main issues with doing UIs on the web are:

- web stack is terribly unpredicatable; you're trying to force an inherently document-layout-oriented model into a free-form 2D canvas, which leads to layouts exploding whenever user switches browser/OS/device/timezone/whatever.

- the code makes no sense; no matter how crappy the Java APIs were (due to deficiencies of the language mostly), the code you wrote at least did what it said, because it expressed the UI concepts explicitly. HTML/CSS is a huge mess of insanity when it comes to doing UI work. I mean, in what reasonable world should the idea "center this" be expressed as "set the left and right margin to 'auto'"? CSS is full of stuff like that.

(And then there are some silly philosophies like "separation of form and content" which everyone touts, but rarely anyone actually follows; see e.g. grid layouts.)

Not ignoring Flexbox, this is the crux of my problem with web development. There are 8,476 different frameworks, transpilers, toolkits, and what have you that all kinda-sorta do the same things. When first approaching this world you get confronted with alphabet soups of packages all combined to "make front end development sane". Everybody seems to have their own soup, though, and many claim that theirs is the way to do development. The flexibility that so many Node-style devs love leads directly to this impenetrability and fragility.

If they do the same thing, pick one and dig in. I really don't get this argument - walking down the cereal aisle will not generate this amount of antipathy despite the amount of choice available; why on earth should development different?

The optimal taste, texture and crunchiness is different for everyone, you can even default to the traditional oats or corn flakes if the newfangled cereals are too brightly-colored or too confusing for you[1].

I love the JS ecosystem and its Cambrian explosion - lots of ideas (good and bad) being tried out by other people[2] and the good ideas tend to be adopted by the more mainstream projects.

1. This is obviously a thinly veiled allusion

2. This is important - don't be the guinea pig and don't jump onto the latest and greatest.

If I don't like the cereal I've wasted a couple of bucks. Picking the wrong framework can be much more costly in terms of time/money. And with the amount of framework churn you can't even make a good decision because in two years time everyone's moved on to the next big thing.

How to pick the right one: age ("old" but not too old) x community x documentation

For the simplest developments I used jQuery (which is a thin layer over pure JS). If you need more complexity you could go for a higher level framework (but there were not so great things like JavascriptMVC)

PHP gets a lot of bad rap but Fb is built on it

There is no perfect solution. When I see people "praising" Win32 I can just laugh (no, really, anything is better than this: https://msdn.microsoft.com/en-us/library/bb384843.aspx) but I think the advantage of that is that there was only few alternatives so once the learning curve was gone that was it)

I know this was just a throwaway comment, but seriously, I love this site:

http://howtocenterincss.com/

For the decades leading up to this stage cross system GUIs with a few simple library dependencies have been an unachieved "easy" task. Web remains as frustrating as ever because now we need it to work on all non portable browsers even on platforms that supports better ones. Then we want new features at an alarming pace that GTK could never normalize across *nixes.

Using the only non-browser that I think sort of got cross system portability working as an example.. I don't think things functioned reliably against the weird m$, Ibm and gcj Java implementations. But since they aren't really GUIs themselves with bookmarks, and familiar menus, no one gets upset when you tell them to replace an odd Java implementation before running a Java program.

Applications with native UIs also tend to give a a better impression of responsiveness, and they reduce mental load for your users since they're don't have to relearn much (if anything). They can rest assured that every button and popup menu and text field (for example) functions identically to every other such control they've encountered on the system and in other native apps. This is worth way more than most people think.

One easy example of this is text fields in OS X. Native text fields there all have a form of emacs key bindings built into them to make powerful text navigation and manipulation a systemwide thing. Every application built with Cocoa gets this for free, but more often than not applications using non-native UIs don't implement this functionality at all. This is highly frustrating when you've worked said bindings into your workflow.

Not just an impression. They often are actually more responsive. Except when they hang, which does happen sometimes, but then so do web apps.

1. Cross-platform across mac-win-linux-android-ios 2. Built for a compiled language such as pascal or C++ 3. Built to use native controls 4. Integrated to registered libraries through an interface like activex 5. Accompanied by a UI builder with design-time and runtime states and component builders. 6. Easily integrated to embedded and server-side SQL.

Sometimes we impose too many constraints on ourselves and never actually start anything. Fear of success?

- you could push one or the other

- you could try to support users on both side based on the editor variable

- you could go the new route where only users who care enough to invest do

- you could go the Jed simplicity route.

In the end, IDEs like jetbrains have the new route with plugins for the factions. Most lower investment cases do the Jed route which is more like web neutral. No one who pushed the unwanted editor on its opposing group seems to be still standing.

ttk does

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.

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.

Flip side: You can distribute/deploy the host HTML application with reach that will be impossible achieve with a WIN32 or MFC application.

With canvas, every browser has hardware accelerated immediate mode rendering that could be used to create UI toolkits. Looking around the web, there are some attempts to make this happen, but none of them seem to be hugely popular.

Last time I looked into this (years ago), a big blocker was that nothing inside a canvas element is visible to accessibility APIs, so UI rendered in a canvas would be invisible to people using assistive technologies like screen readers.

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

If I had to write a Web application I would probably start by writing a UI toolkit from scratch based on HTML5 Canvas and just bypass the whole HTML/CSS nastiness. I've written UI toolkits from scratch before (all the way down to the text rendering engine) and even that was probably less work than trying to work around HTML's mess.

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.

It's very difficult, as I get older, not to survey the computing landscape and be profoundly bitter about our absolute and utter refusal to use better tools in order to achieve greatness. It's like people choosing to eat McDonald's when they could have an affordable home-cooked meal prepared for them, for essentially the same cost.

Because these systems moved beyond what plain POSIX means.

Even on Apple and Google's OSes, their UNIX underpinnings are not that relevant, because most of the user space libraries and APIs don't have anything to do with UNIX.

All the mobile OS relevant APIs don't have anything to do with UNIX.

All the Objective-C, Swift, Java, JavaScript, C++ APIs available on those OSes don't depend on being implemented on top of an UNIX kernel.

Which ones do you mean? F#, ..., ???

>All the Objective-C, Swift, Java, JavaScript, C++ APIs available on those OSes don't depend on being implemented on top of an UNIX kernel.

Interesting point.

Also I didn't mention just C#.

Even the big companies can't do pretty basic things on the web, like justify text beautifully. It's not hard to imagine another world with much better typography on the internet. Ditto for better languages and a better layout system.

Most importantly, just because something has broad support and took a lot of effort does not put it beyond sharp criticism. That's no way to make progress and a perfect way to make entrenched worse-is-better technologies that managed to get popular even more entrenched.

And they throw huge amounts of resources at the web stack to do it. It might work for them, but I'm not sure that makes it powerful, performant, and manageable for those of us who aren't huge companies.

To me js and css are kind of manageable, a bit the same way as python: use strongly enforced linters forbidding anything ambiguous, do not jump every other day in a new sexy bandwagon, and do not let one line of code commited in without an automated test running it on a ci machine.

What I found harder to manage is the young FE devs themselves: for them it seems every new project, or every new view in the same project, is the opportunity to use a completely different, new toolset. Oh, and some new syntaxic sugar candies supposed to "save" a couple of keystrokes (which is the worst reason you can find to use a new syntax requiring its own tools). I find this very dangerous, especially when the github repos holding these tools are 3 months old.

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.

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

I disagree. Compared with other languages and technologies used for similar purposes, none of JS, CSS or HTML is particularly powerful or efficient, nor do any of them provide particularly good tools for helping new developers get up to speed or co-ordinating large teams working on the same project. I initially wrote a huge set of specific examples to support these claims, but on reflection I'm not sure criticising JS/CSS/HTML in excruciating detail would really advance the discussion here. Suffice it to say that best-in-class programming languages, document preparation software like TeX or high-end DTP applications, and representations like PostScript and PDF, have all been doing everything JS/CSS/HTML can do and much more for a long time.

Facebook, Google and Microsoft all use the web stack to run huge companies.

That's not the whole story, though, is it? For example, both Facebook and Google became successful primarily for the hard problems they've solved on the back end, particularly in terms of scalability. Facebook's main web site is nothing special in general UI terms, and their web-based tools for advertisers are awful. The search engine that took Google into the big leagues was famously extremely simple on the front-end, and while today they also have applications like Google Mail and Docs/Apps/whatever it is called this week in their portfolio, again the front-ends for those are still relatively simple in general UI terms and would probably be unremarkable in any other context.

To broadly paint this web stack that so many people poured countless hours into making, as 'impossible' to use is doing it a great disservice.

I don't see anyone saying it's impossible to use. However, it's probably fair to say that the state of the art in front-end web development is between one and two decades behind the general programming community, and that many relatively inexperienced people working in the web field are slowly but surely learning the same lessons (and repeating the same mistakes, and repeating them again) as the rest of the programming world did before. One of the biggest problems, IMHO, is that quite a few of those people now work for influential businesses like Google and Facebook, which means quite a few even less experienced developers assume they know what they're doing. And that's how you get framework fatigue, left-pad, "living standards", sites and apps written more than a year or two ago no longer working in modern browsers, and other such madness.

The corollary to that is that the system uses components that target the lowest common denominator. I'm not sure "anyone can contribute" is a good foundation for any complex technical endeavour - if we are speaking specifically of implementation.

1. http://www.gwtproject.org/

It's Java. Last time I checked, still a painfully verbose language and build environment, with the wizardry of JVM tuning on top.

Perhaps, some day, this will turn into something more pleasant: https://sites.google.com/site/gowebuitoolkit/

It does require huge companies like these to work with the web stack painlessly and they're behind initiatives to make it even more cumbersome. You could say that they have an incentive to hamper competition by screwing up the web and they're doing it well.

This always gets trotted out as the issue. "It's not JavaScript that's bad for building large applications, it's just everyone is using it wrong."

Prototype inheritance is even more brittle and hard to follow than class-based inheritance which is why developers, for their own sanity, try and shoe-horn it in.