Hacker News Reader

Comment by pixie_ | Hacker News Reader

Yes. I feel like we're in the dark ages right now.

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.

View on HN

If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages and three frameworks:

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

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

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

...and often...

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

When someone asks me how to learn to build web apps - even someone who can already program a bit - I feel embarrassed explaining to them what a pile of patches the Web is. Even if the languages themselves were saner, this is a monstrous amount of complexity for something that takes one language and a drag'n'drop GUI builder on any other platform.

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.

You can literally use Javascript for all of this.

I think you may be misunderstanding my point. If you have to invoke a brand new JS framework with limited uptake and many competitors, and "one of a million" CSS frameworks, in order to declare this problem solved, you are perpetuating the problem.

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.

My thinking on this is that everytime someone has tried to unify these tools it hasn't gone well. Think about Google Web Toolkit, or Microsoft's XAML.

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.

Did GWT or XAML really try to unify things?

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.

The point I'm making is that when people have tried to develop a UI framework in a single language from scratch and offer the same functionality as the web, they fail. Performance sucks, or its not flexible enough to deliver certain functionality.

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.

That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.

Exactly. Intuitively, I don't think the problem can be solved with the same "let's glue together a bunch of stuff and call it a stack" approach that got us here.

I'm hoping it is. We have ended up with really good tools compared to what we had before. Think about using commonjs requires, compared to the craziness of the Rails asset pipeline and sprockets, or manually specifying js files.

We just need to standardize the glue...

Better bad is not the same as good.

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.

The best part will be when we're all standardized on ES2015 modules instead of commonJS modules. I agree with you that CommonJS requires are nice to use, but since they're not statically analyzable the way ES2015 imports are, optimizing compilers like the Closure Compiler can't really analyze your entire application, including its dependencies.

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.

Yeh I initially hated that commonjs was not used for es2015 imports. Slowed down application startup and lack of node.js compatibility.

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

We just need some way to lazy load modules.

it's not, because Mongo has huge issues [0] and angular is generally a giant mess and a pain in the ass [1]

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

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

I work on a large (500000+ lines) of Angular daily. Maybe this represents some sort of Stockholm syndrome, but it's really not that bad?

Over half a million lines of Angular? May I ask what the application is and how that's broken down language-wise?

Angular front-end, C# "middleware" to Java services layer. I was actually guessing when I tossed off 500k. I went and looked and it's actually closer to 250. Still pretty big though.

Similar situation here, but it depends on your level of experience as well. Can you structure an AngularJS app so that it's (relatively) sane? Absolutely. It's also very easy to make a mess of things so that it's hard to reason about control flow; frameworks that are doing a better job of embracing unidirectional dataflow definitely help with this, but I don't blame Angular as it predates the wide adoption of that as a practice.

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.

Oh totally agree. There are some really nasty bugs we've had to deal with because of the lack of strictly controlled data flow. Still not all that bad.

Have you ever worked with a JS framework that wasn't angular? Ember, React, Vue, etc?

I've used react personally and like it rather well. I think it's much better than Angular, but I still don't think that Angular represents the 9th circle of hell, as seems to be implied above.

I think most libraries should be compared based on their worst-case implementations. As in, the "worst" react code is still much better than the "worst" angular code.

I've used Angular a good bit, seems fine to me. Last place I worked probably had around 20-30k lines of Angular code. It wasn't perfect, but it was way better organized and easier to understand than a much smaller project (~1k lines) done with JQuery and handmade paging system.

I have yet to work on any ng (1 or 2) project that I'd take over a well-structured React + Redux project.

I think your use of "minimum" is wrong here. If you're using React running on Node and Webpack as your task-runner you just need Javascript and that's it.

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.

I still count three frameworks :)

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

Ah I wouldn't count Node as a framework as I'd equate it to the JVM in Java world. But you are right, I'd probably lump webpack in there as it does have a fair bit of depth to it if you want to get the most out of it.

You still need to use Express or something similar on the server side for Javascript, I mean, if we are talking about standard procedures here. Plus with React, you are still doing that Javascript/CSS thingy and HTML of course at some point, so there is no avoiding that, and clearfixes, polyfills, etc, etc.

But all of these things you're bitching about combined are far smaller than even ASP.Net without including anything client-side.

And how many frameworks can you count in a win forms or wpf application?

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.

Honestly from the programmer's perspective, it's really just one framework: .NET. I know that .NET abstracts away other frameworks such as the Win32 API, but generally you don't need to know any Win32 API etc. to make a Winforms / WPF / etc. application. With modern "web application" style development, it seems these days you need to know multiple frameworks by default, for better or for worse.

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.

You are confusing .Net, C# and WP* frameworks. .Net is closer to the JVM, C# is the language and WP* are libraries that interact with w32 apis

Not trying to be pedantic, just posting to set the record straight:

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

As rpeden pointed out, it's you that are confusing the things. CLR is what JVM is for C#, while all the stuff I mentioned are inside the .net framework

I'm not sure what sre you talking about, if you program with c# and wpf, you need to know xaml and their weird syntax, you need to know prism which is a framework to properly organize your UI, you need to know a server language like asp. Net if you want to deal with backend code.

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

I would have to disagree on the last sentence -- there is nothing in any definition of a software framework I know about that suggests that a software framework cannot encompass more than one function. .NET indeed does have a much larger solution stack then most web frameworks, for better or worse (there are advantages and disadvantages to this approach). But that does not disqualify it from being a framework in my opinion.

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.

True it's a single framework, my point was only the size... I mean, the amount of knowledge you need is probably the same you need to work with web stack.

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)

Node is a runtime, not a framework/language, and if you use a JS friendly DB (there are many with transparent APIs available (rethinkdb, mongo, etc) then it's all just JS.

> ... to abstract away SQL

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

Well, everything is an abstraction, down to zeroes and ones.

Oh, it goes so much further down than that.

Turtles all the way down.

Until you're working on a project where the turtles eat the errors...

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

I was describing the problem as "turtles all the way down, except the turtles are eating all the errors, and the rabbits can't find them"

It's all just fluctuating fields in the vacuum?

> Why not abstract JS away instead?

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

> Node allows you to run isomorphic JavaScript that runs on both your server side and client side

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.

You could of course write something that compiles to JavaScript. There's a ton of options, some are even pretty nice (I like ClojureScript; want to try out Elm).

Elm is client side only.

Elm can be installed run from the command line.

Do you mean there's a way to run non-html-anchored Elm? Links would be wonderful!

Then use PureScript.

This is where Typescript comes in. It's beautiful.

JavaScript sucked indeed. ES6 though, has brought many improvements, and the language now is quite decent. With the advent of async/await in ES7 (which is available now if you transpile with Babel), the callback hell is completely gone, and the language is actually beautiful, powerful, and concise.

I think we are exaggerating here. Javascript was terrible but with es6 it's just getting better, I know various languages and only Javascript manages to make me scream with its quirks, the others at most I feel disappointed. So "good" is an exaggeration, reasonable seems fine, but currently is either an OOP language where 'this' changes every time, or a functional language without native support for immutability, curried functions by default and a whole bunch of utilities that you expect from a language claiming to be functional. If it's a language with both mixed, must be compared to ruby which has consistent oop and functional programming with support for laziness and a super powerful ability to create dsl.

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

JavaScript is a fantastic language. I don't get this animosity towards it. A decade ago it was made fun of by people who "use real programming languages" but JavaScript has grown up. It's actually very good and very fast. ES6 brought improvements but honestly ES5 is still a great language.

Totally agree. The lack of understanding of JavaScript's paradigm from some people make them blind about the language power, it has the enough amount of every needed paradigm there, including OOP, functional and evented. I see in the comments here people complaining about things like dynamic `this` when they just don't understand it's one of the biggest powers of JS.

JS is not object oriented. A prototype is not the same thing as an object. There are no classes in JS.

What you mean to say: JavaScript is not class-oriented.

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.

Ok, tell me where on "object-oriented programming" is the word "class". Objects are not necessarily related to classes. And yes, a prorotype is a object that you can extend from, as well as from any other object, like prototype-based OOP works.

JavaScript is not a fantastic language. It does a lot of things that make no sense. It converts between types in nonsensical ways. Eg in Ruby, you can't accidentally do `5 + "hi"` and get "5hi". If you really want to treat the number as a string, you can do `5.to_s + "hi"` and it works, but you don't do such crap accidentally.

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.

> It does a lot of things that make no sense. It converts between types in nonsensical ways. Eg in Ruby, you can't accidentally do `5 + "hi"` and get "5hi". If you really want to treat the number as a string, you can do `5.to_s + "hi"` and it works, but you don't do such crap accidentally.

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.

NaN is not equal to NaN by the IEEE 754 standard. JavaScript, and many other modern languages, implement floating point numbers by this standard. E.g. in C#:

> 0.0/0.0 == Double.NaN

false

Damn, I see so much frustration from you for not being able to understand JavaScript here... once you understand it's a different language instead of trying to write your favorite language with JavaScript syntax it'll get better, buddy, relax :)

I would argue that React is different enough so as to almost be called its own language. After all, it does use "JSX", whatever the hell that means ;-)

> You can pick a nice ORM (like sequelize)

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.

honestly, in JS/Node, I find it easiest to use a SQL adapter that can handle template strings as parameterized queries...

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

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

Which works unbelievably well... There's not nearly as much need for boilerplate/translation layers in what is already a dynamic environment. I wrote a wrapper for ms-sql when migrating data, it took 2-3 days to get it done, but writing queries as above was so easy to work with it was incredibly nice. I'd rather work with a db that has a friendlier API to work with or abstract around... but writing a little template driven sql is often better than layers of boilerplate like an ORM.. and I still don't really get mongoose.

Maybe I'm missing something, but that looks like SQL Injection ready to happen.

sql.query is a function that will receive two arrays, one is the strings part, the other is the injected values... the template processor takes those arrays and turns it into a parameterized query to the database.

Very cool! In that example though... where's the array? And don't backticks do string interpolation?

Backticks by themselves will do string interpolation. But backticks with a function name in front will do something a bit different. In this case 'sql.query' is a function and the JS will pass it an array which represents the contents of the backtick string. There the function can do what it likes and return a result. 'sql.query' builds a proper (and safe!) SQL query and executes it.

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

This feature is apparently called "tagged template strings"; more on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Neat! Thanks for the awesome explanation!

That looks fantastic, I'll take that any day over an ORM in JS.

Here's the one I wrote for mssql[1], though it should really be updated, and probably use tedious directly, instead of mssql.

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

"thats it"

250mb worth of dependecies later...

HTML, CSS and SQL aren't programming languages, if Turing completeness is a requirement to be a programming language.

This is a language lawyer nit-pick comment that doesn't add anything to the discussion.

> if Turing completeness is a requirement to be a programming language

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.

This seems like a great place to observe that Magic The Gathering is Turing-complete. If your requirements suggest that MTG is a programming language, but HTML isn't, they're probably bad requirements.

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

HTML + CSS seems to be Turing complete : http://lemire.me/blog/2011/03/08/breaking-news-htmlcss-is-tu...

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

You forgot something for the mobile strategy, something for web stats, something for monitoring, something for source control, something for issue management, something which shall remain nameless for team communication that breaks store and forward and interrupts you constantly, something for 'social', etc. Oh wait, and your infrastructure automation solution. And your third party DDoS protection/web cache integration... and all of this is TRULY NORMAL. We are underpaid.

You forgot containers, and a platform for orchestrating(?) or swarming or cat-herding or whatever it is one does with a gaggle of microservices.

You forgot integrating all of that, keeping it integrated (aka working) as versions of pieces change, and debugging it all.

"A framework to make Foo bearable" seems like a huge portion of the issue here. We have a bunch of tools so hideously unfriendly to everyday development that we have to pile framework on framework in an attempt to actually get something built in a timely manner.

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?

Good post which jogged a memory for me, HN discussed this very thing 7.5 years ago:

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

That doc is broken.

I would exclude the 3rd framework. You do not need or want to use a CSS framework if you actually understand and have experience writing CSS.

Whenever I hear this argument, I think of those guys out there on the freeway laying asphalt in the middle of the night. Or those people who are dead - inside the dam's cement. They probably wish they didn't have to use tools or try new techniques or combine skills and continue to learn new ways of building complex structures. They probably wish things didn't go wrong. They probably wish there was a task manager that just put all the dirt into the wheelbarrow and rolled it where it needed to go. As we move to a computer-based way of building things, it seems that we have already become spoiled and self-deserving. It seems like most 'developers' took a "rails for zombies" tutorial and are angry that things aren't as easy as that. That's why front-end developers get paid 4 times a much as most people / to make crappy software for other developers to track their time or catalog their toys or rants with their friends about how much they hate programming. I think everyone who doesn't like writing code, should get a job on a contractor's team for a summer - if they'll have you. Then while you are thinking about how much that job sucks, dream up a new box-model CSS type thing and be the hero.

... and usually ...

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.

I remember being warned about engineers that get used to using frameworks too often. Their ability to work outside of it eventually suffers.

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

LOL, all of the frameworks mentioned, even express are pretty light abstractions... that said, I feel angular, as an example goes TOO far.. way too far. These days, I hesitate to even use lodash, let alone jquery or larger bits. Though I'll still bring in moment if I have to deal with a lot of date/time logic and formatting (hate the size of it though).

Yeah, I'm all up for writing everything in machine language using punch cards. Anything else is clearly too much abstraction and obviously a sign of bad engineers.

Cards? No, you need to feel the bits, inputting them with manual switches.

OR...

    * JavaScript (client and server)
    * Redux (state management)
    * React (UI Control framework)
    * MaterialUI Controls (toolkit, one of many)
    * JS Friendly DB

With a database that has a native adapter such as RethinkDB (or Mongo if you really want it), it's really transparent.

> If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages

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.

> If you're going to call HTML a programming language [...] CSS is simply properties [...]

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

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

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.

What you basically do, is hiding and abstracting facts.

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

I assume you're talking about https://anvil.works here. That tension ("hiding facts") is there in every abstraction, but there are some luxuries to the way we do it. By putting a whole, consistent layer over the top of the web platform (in our case, Python and a traditional UI toolkit with a GUI designer), rather than patching little holes in usability here and there, we can prevent you from stubbing your toe on (eg) Javascript-isms every five minutes.

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.

+ A framework to make the web app framework more suitable for API development (eg Django Rest Framework)

this is a bit disingenuous. the back-end technologies are quite stable and based on not-perfect-but-reasonable semantics. Django/SQLALchemy don't change that much.

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

I think backend frameworks do change. I think the difference lies in the velocity of change.

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.

The problem is that I think a lot of back-end frameworks change (and/or are created in the first place) as just a means to pad the developer(s) that coined it. All the new implementations of JS that are increasingly more backend just seem like a lazy way of not having to learn a "real" OOP language and just pressing boundaries. Which is great in some respects, but I feel like we could be making better headway as a collective resource by working on improving what's already there (without breaking it in the process) instead of making new things so the new kids to the game don't have to try so hard.

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.

>> A modal web application today takes an absolute minimum of five programming languages and three frameworks:

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.

React is, in my opinion, a big step forward in reclaiming the front end as a mature UI environment.

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.

I agree—I loathe frontend development, but React made it tolerable to do for limited periods—but it's still a hack on a teetering Jenga tower of hacks.

The really funny thing is that the OS runs a simple event + render loop, then the browser implements a wildly complex stateful/declarative structure on top of that (the DOM), then React apps create a simple event + render loop again, this time with special diffing logic to update the underlying DOM as little as possible

And no doubt this layering will continue... "Look how I easily render this document decription into react primitives".

https://news.ycombinator.com/item?id=12473549

I made this comment in another thread, but it fits right into this one too.

Yes, we write web browsers in JS, simply because our browsers let us write nested browsers in JS. I'm only waiting for an OS written in JS so we can use its editor to write an OS in JS.

Gary Bernhardt mentions an OS written in JS in his video: https://www.destroyallsoftware.com/talks/the-birth-and-death...

http://bellard.org/jslinux/

also

http://www.windows93.net

Brilliant observation. That actually never occured to me.

This is a great insight. I'd never noticed this about browser stuff, but it's definitely a major issue in video game development.

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.

loathe? I loathe public speaking and flossing, but these things are good for me, and I'm sure you wouldn't be doing frontend dev if there wasn't a big upside that it made possible.

> teetering Jenga tower of hacks?

How is any programming language not capable of being brittle?

This isn't about a language. It's about the whole stack.

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.

Fine. Name a better stack then and suggest ways this one can improve.

I echo -- this is good advice. Pick the minimal set of tools you need to use react and css modules (this probably means banging your head against something like webpack for more time than you can possibly enjoy) - but with those pieces alone as starting point, you don't really need a lot of additional library support to build applications that run in browsers ... and your code should start to seem understandable/predictable -- in a manner reminiscent of using better native frameworks of the past.

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

IMO react is a big step backwards. Adding an abstraction layer almost never produces a better result, it just makes things more complicated.

abstraction isn't inherently a bad thing, it's what gives us the tools to reason at a higher level. It's leaky abstractions that are the problem.

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/

I think where a key abstraction was lost was when JavaScript became the language you had to compile to if you wanted to do web development. Biggest hope I see on the horizon is WebAssembly, which has support of many big players but I've heard very little on it recently.

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

But then you still have the following hack offenders:

* 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

I'm glad you added the qualifier "almost" because, even in low-level C, you're typically sitting on about 4 layers of abstraction:

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

That's what I'd call a good abstraction. You can write in c, debug in c and very rarely (if ever) be forced to know what the lower layers are doing.

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.

Abstractions make things more complicated? I think you're missing the basic definition and purpose of abstractions. So how do you define "almost"?

I think the correct term is complex. Abstractions make things more complex, as there are more moving parts. This normally leads to complications when trying to debug some obscure error that you will get when the project gets bigger. At that point you feel for calling on some ancient deity to spite the developer who decided to use this framework 6 months, until you remember that you proposed it as replacement for the last pile of abstractions to hide the failings of the platform. (Yes there is plenty of sarcasm in here :P )

Which is more complex - an apple or an internal combustion engine?

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.

Inherent complexity is often ignorable, but bugs can and will sit anywhere. So, yea the fact an apple is vastly more complex than an engine is not always relevant, but when it is relevant you have real issues.

Bugs are much more likely to be in the apple.

A good abstraction hides complexity without adding major tradeoffs. Presumably an abstraction makes it easier for a developer to reason about what is going on.

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

Abstraction is the foundation of modern modern computer science. I mean would you prefer writing in assembler rather the a higher level programming language ?

Maybe?

The dillema is that you need to understand the low-level aspects in order to understand the abstractions.

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';} )();

So I assume you write all your programs without the benefit of an operating system then.

Didn't HN have a thread where someone wrote a CMS site in assembly? It sounds crazy, but if it can be done, someone will do it.

Yes, you can do it, but the drawbacks are huge and obvious.

Maybe for web applications.

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.

I think it's completely fine to write a website/blog/newspaper in React, provided you make it isomorphic and keep it as light as possible. Then you get all of the advantages of using React with almost none of the disadvantages.

Of course, nobody does this in practice.

If your blog/newspaper/text+images website requires JS or it is not readable, you failed.

The two of you are agreeing: "isomorphic" in this context means "the server can render it to html and serve it like a normal webpage".

For those who like videos(unlike me) and Java (like me), this was a topic for one of the talks at JavaZone in Oslo last week and I watched that one on my way home today: https://vimeo.com/181925279

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

From a javascript point of view, React is great, but I wholeheartedly disagree on the CSS modules. What React did here breaks the whole purpose of CSS, even if it is messy, not to mention that now designers need to have help from programmers to do their job. IMHO, it is much better to user Sass to make CSS sane, and just do whatever makes life easier on the frontend. I feel something light like Backbone.Native with a Shadow/Virtual DOM system is a superior system in this sense.

I'm not very impressed with "the whole purpose of CSS". CSS made a ton of design mistakes which we're still living with today.

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.

What about full on web components? Then the designers can just target components, and leave the programming to the component makers.

I don't know enough about them to say for sure, but they do sound like a good solution. Haven't they been just over the horizon for a number of years now?

Flying cars, cold fusion, and web components?

This post makes me sad. Javascript, CSS and HTML can all be used powerfully, performantly and in a managed way where anyone can come on board and contribute. Facebook, Google and Microsoft all use the web stack to run huge companies. 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.

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

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

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.

And even their code is still often bloated, maddening hacks on hacks.

You probably do not have the complexity level of these companies either.

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.

Your last paragraph describes my experience with web development exactly. Ironically I'm 22, but I've worked with people or talked to people online who want to use the "latest and greatest" for what could've been a simple CRUD app.

> You probably do not have the complexity level of these companies either.

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

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

Or move to the back-end, where things move at a more survivable pace. Here's the dirty secret, too: for the most part, the work you do there is actually easier than front-end work, since you have better tooling and frameworks that don't shift under you like quicksand. And building a CRUD backend to a REST API might be a tad tedious, but it's a whole lot less fiddly than mucking about with CSS and trying to make web UIs pixel perfect in every mongrel browser under the sun.

Honestly I would if not for the fact that backend interviews always test Crack the Coding Interview style data structures & algorithms knowledge, which I have no interest in spending my limited spare time preparing for (I didn't major in CS).

As an employer I would be negatively surprised if a candidate for FE never heard of react, angular, etc. But I also see a red flag of the candidate were to assure me to be knowing all of them bottom up. That would mean a lot of toy projects and unstable personality, if not plain lies. I'd be looking for someone able to work for some years on a code base, grasp its stack, improve the overall structure, quickly find and fix bugs in a sustainable way, etc.

What's sad is the zillions of hours wasted by engineers on an inherently flawed stack. What's sad is how ridiculously complicated it is to create and manage relatively simple UIs. What's sad is an entire generations of programmers growing up and thinking this is normal.

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.

Yes. Exactly what you said. It bothers me when people think solving broken Javascript problems is a valuable way to spend our civilizations scarce skilled manpower.

Angry Birds and Candy Crush are clearly superior uses of time.

Well, they at least provide value to people without too much externalities which makes them much better than both fighting in the mud and all the adtech work that drives this mess.

The web lets you reach a large audience in a way nothing else can. You have to get over yourself about the tools not being elegant, and make sure the thing you're using the flawed tools for is worth the aggravation.

That's why it's so successful. There has to be a reason something so terrible could possibly be this successful and you hit the nail on the head.

https://www.jwz.org/doc/worse-is-better.html

That doesn't mean it isn't terrible to work with and couldn't be much better. Unless you think the tool flaws are inescapable aspects of reaching a large audience?

> You have to get over yourself about the tools not being elegant

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

The fact that you can reach a massive audience doesn't make any less true that the tooling sucks. If that first fact wasn't true, we would not be commenting on this issue...

Complicated to create UIs? Win32 was complicated. MFC was complicated. GTK is hard

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

You can create controls in WIN32 or MFC that would simply be impossible in HTML for a reasonable level of performance

Yes, but this doesn't matter for the majority of applications today

Replace "WIN32 or MFC" with "iOS or Android" and the point still stands, especially on mobile devices where processing power is limited and battery life more important.

Performance yes, you can't compete with that one because browsers don't let you control the low-level stuff. But the speed of development and the ease of doing complex layouts with css is hard to match (when you master css enough, of course), specially if you're trying to do UI from the code directly, without IDE helpers and visual builders.

The speed of development is very fast for the first 75%, and comes to a screeching halt for the last 25%. The web stack has no good way to answer basic questions like "does the user have arrow keys" or "what is the current mouse position." That's the point that you start to layer on the "hacks on hacks" that OP references.

Can any system tell you that the user has arrow keys?

> You can create controls in WIN32 or MFC that would simply be impossible in HTML for a reasonable level of performance

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

True, but it should be possible to create high performance UI controls inside an HTML5 canvas element.

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.

Delphi, VB6, WinForms made development a lot easier, there was a reason they were called RAD tools.

Because it was the 90s?

Not fair, if just make some simple UI stuff, html and css can be the same easy as WinForms.

I was building GUIs in pure Win32, with my own C++ wrapper classes for Win32 and later with OWL and MFC.

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'd say building Win32 GUIs in C++ was easier than current Web stack. >Same with Java AWT and Swing libraries.

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.

And I have to disagree with you. Doing UIs in native frameworks like JavaFX or even in a pure C++/WinAPI, is much more saner than doing any kind of UI in HTML/CSS. Ignoring flexbox for a second, which is kind of bleeding edge new thing, remind me - how exactly do you vertically center stuff with CSS? :P.

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

I have returned back to native UIs development (WPF/Forms/XAML/Android), after 4 years of web development, couldn't be happier in what concerns my productivity.

> Ignoring flexbox for a second

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.

> 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

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

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.

And as he said (and it bears repeating): "This is important - don't be the guinea pig and don't jump onto the latest and greatest."

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)

> how exactly do you vertically center stuff with CSS? :P

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

http://howtocenterincss.com/

The difference between what you are doing and what desktop UI has always enjoyed is a component system that works flawlessly. The Web Components specification is a good step forward in this regard, but as many people have pointer out, try to do something trivial like a modal wizard in Java/.NET and try the same thing on the web side.

I think we could divide in two types of interfaces: for data entry and for graphics/complex. For data entry, html/css is extremely easy, but for complex specialized interfaces it could be more dificult.

But none of your examples are as cross system portable and "native/normal feel" as writing an app that only works in chrome/chromium.

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.

Why is native/normal feel the end-all-be-all of UI systems? I've never quite understood why this is so desirable. Or why the answer seems to be using a shoddy UI system stuffed in a browser frame.

I know a great coder who refuses to start personal projects because he can't find UI libraries which are:

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?

Good point. And actually, Delphi matches many of those bullet points. Expensive, though. (The promo of the free Delphi 10.1 Berlin Starter version just got over on Aug 9. First time in a a while, maybe, since Turbo Delphi Explorer.)

I think writing an IDE or anything else with editor integration during the editor wars would be a similar analogy:

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

It is a good idea because you reduce the learning curve for end-users of application by the use of common controls. Think about the MS-DOS era, and then Windows came along, with the ubiquitous F1 key everywhere, Ctrl-P and Ctrl-S, not to mention the toolbars, etc.

Because chances are that whatever custom UI/UX design you come up with isn't going to be better (or even as good as) OS UI toolkits that've been designed by experts, battle tested for decades, and used for every type of application known to man.

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.

>Applications with native UIs also tend to give a better impression of responsiveness

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

They could be made portable if an equivalent amount of effort was spent devoted to that goal.

I'm coming up blank trying to think of web sites and chrome based apps that provide a look and feel consistent with - and as performant as - what is offered by the native platform.

Visual Studio Code

Qt is easy with Qt Designer and looks professional.

I wouldn't call Qt Designer "easy" in any sense of the word, but possibly that is because I have found how good that sort of tool can be, and it is called Interface Builder (Xcode), which isn't perfect, but should be what Designer strives for.

It was easy for me to arrange widgets in a layout and connect signals and slots.

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

ttk does

Yes, from a purely presentational aspect, HTML/CSS is way better than Win32, etc. Things like a virtual DPI, easy-to-use transparency and alpha blending, no paint cycles, and much more.

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.

But you should really compare these with modern desktop UI development. Anchors are awesome in .NET and don't get me started with Java layouts. UI design truly is better on the desktop side. Maybe it will be more difficult for a designer to develop a nice interface for a desktop program but that's about it.

I totally disagree with this. It is far easier to build an application in shitty old MFC than a thousand attempts and 10,000 random attempts to fix things in no content way.

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.

I've built native ui applications under win32 (API itself, MFC, ATL), os/2, x11, qt, gtk and more. Developing UI for each of these was a thing I found much more straightforward than web applications over the last decade.

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 should add what I see as the one up side - the ability to test UIs written on modern platforms in an automated way is vastly improved.

Interesting, what native UI system is in your opinion easier to work with than web? 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?

Delphi 4's VCL and IDE was the high point. It's been downhill ever since.

Delphi 7 designer was a great improvement over delphi4 (we still use it at work) and yet delphi 2007 fixed some soap bugs and xe7+ is pretty decent as a cross platform ui development IDE.

You should try a newer version of the IDE/compiler. Delphi 10 Seattle and 10.1 Berlin are pretty damn good. Fast load times, editor is solid. The only real downside to the whole product is that the VCL (still) needs better layout management and easier ways to cope with scaling on high-DPI displays.

I think they use it because they know that. Not because it is better. It is faster and easier for them, but the end product is a pile of ..... .

> Interesting, what native UI system is in your opinion easier to work with than web?

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.

Which specific ones, for example? "Every one" could cover a lot of ground and doesn't have much information content. It's doubtful you have experience in every one, and it would be useful to know which specific ones have been tried and seem better.

AWT, Swing, Cocoa/CocoaTouch, Android, GTK+, QT, VCL, SWT, XAML, XUL, J2ME Polish are the one's I've used.

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.

Answer to first question: Every single one.

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.

Because they don't know better.

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.

You could say the same thing about Unix but nobody seems to be calling for that to die.

> nobody seems to be calling for that to die.

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.

Yeah, there is, but it's ancient and that sort of carping seems to be a distant memory.

That's kinda the problem, though: Unix really is worse than VMS or Lisp Machines, when measured on certain axes (and I love Unix!); rather than fix it, or replace it with something even better (e.g. Plan 9), the computing industry has instead decided that POSIX is the end-all, be-all of OS evolution, and collectively ignored all the ways that life could be better.

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.

This is what makes me focus more on Windows, macOS and the mobile OSes.

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.

Windows has its own legacy baggage and I wonder about the proposition that the mobile OSes' Unix underpinnings aren't relevant. Depends on what you're doing, I'd think.

Windows might have its own baggage, but with Windows 8 they have brought the original design of .NET from the ashes and assuming the current path is to maintain, those of us that like Windows will have a nice OO ABI alongside safe languages compiling to native code.

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.

>alongside safe languages compiling to native code.

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.

I mean .NET Native and the lessons of Midori finding their way into C# 7+ and C++/CX, alongside with emphasis on the C++ Core Guidelines, which started at Microsoft before Bjarne got involved.

I mean, I like C#, but that stuff seems to me to be sitting several levels above the OS anyway.

Because most likely you never spent time using or learning the technical details of the OS developed at Burroughs, Xerox, ETHZ, DEC, MSR,....

Also I didn't mention just C#.

I just mentioned it because I'm familiar with it and I am excited about the .NET Core stuff letting you use it in more places.

Ah, then you should check Joe Duffy posts about Midori and his talk at InfoQ.

What's the alternative? The division of platforms is a fact and how can you deal with it by only programming native apps? This is the best solution people have come up with. You talk as if it's all a hugr waste of time. I don't think so.

People used COBOL to run large companies too. (Hell, they still do.) Doesn't mean it was particularly good for any definition of good.

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.

anyone can come on board and contribute.

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.

That is not a corollary. While I disagree with the person you are quoting as far as web frameworks are concerned, this is about organization and documentation, not "components that target the lowest common denominator".

Javascript, CSS and HTML can all be used powerfully, performantly and in a managed way where anyone can come on board and contribute.

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.

Great summary of many valid issues.

The first two paint points are perfectly solved by GWT[1]. But for some reason it isn't picked up by web community, even though you can still make really cool web apps with it.

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

> But for some reason it isn't picked up by web community

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/

Having used it for one or two projects I can say it solves some problems, but creates others, when trying to do more complex stuff it can be a pain (can't remember any specifics it was a few years ago).

If GWT doesn't count as hacks built upon hacks, then I don't know what does...

GWT has been continually approved upon. Compilation is super fast now, and developing is a breeze with super dev mode. You can even debug your Java (precompiled) code within chrome. as a GWT user, I don't have to worry about all those things that trouble Javascript developers. Refactoring is easy as it is just Java.

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

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.

I agree with you here. The front-end (JS, CSS, HTML) are there to stay and can be organized into clean and maintainable modules. Its not technically difficult but it is humanly hard: you need to put in place best practices, peer training and have lots of discipline. Lots of people are turning to React - probably because it gives you structure.

Often a developer is thrown into a stack that was built crooked and gets discouraged. Instead, its your job to get in there and clean it up. It may take months but you'll you yourself and your team a big service!

Languages don't scale. Systems scale. Without said, Javascript has never really been the language for programming in the large. But make no mistake about it, it's slowly getting there as is evident by huge applications, not just web but even desktop that are being built with it. It's not impossible to refactor. The issue from what I've seen is that people think it as if it's a class based language instead of the prototypical language that is.

> The issue from what I've seen is that people think it as if it's a class based language instead of the prototypical language that is.

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.

We put people on the moon without benefit of "scalable" languages, we built entire operating systems in C which is notorious for quickly becoming unreadable, and we've somehow built an entire world of content using HTML and CSS.

JavaScript is just a language, and while improvements to it are being made constantly, the biggest obstacle is not the language, nor the way browser makers support it, but the absurdly slow pace of some organizations to update their browsers to something sane.

Pick a language, any language, and then restrict yourself to features only ten years old. That's what JavaScript is like in some cases, but the good news is ten years ago some pretty good things were happening.

> We put people on the moon without benefit of "scalable" languages

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

Not to mention C# 1.0 already being statically and strongly typed, had properties and events, reference and value types, interfaces, namespaces, and a reasonably complete standard library. And that's just one language.

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.

> 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

Erm ... we actually don't have self-driving cars

Google and Tesla beg to differ.

For a very restricted definition of "self-driving" ... but fair enough, in the context of the parent post, the self-driving cars we do have are impressive pieces of software

Google's cars are operating on city streets you know. They're up to over 1.5 million miles.

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

I think that not only we would have self-driving cars, they'd be working much more reliably than proposed solutions of today, and would utilize some pretty clever analog-driven methods.

The problem isn't with JavaScript, the problem is with the culture which glorifies mindlesss throwing of shit at a wall to see what sticks, instead of actually thinking of what one's doing and checking if a given topic wasn't already explored by smart people a few decades ago.

> I think that not only we would have self-driving cars, they'd be working much more reliably than proposed solutions of today, and would utilize some pretty clever analog-driven methods.

More info please?

Consider this - the 50-80s era was known not only for putting men on the Moon, military and space agencies were doing a lot of crazy shit like space shuttle that could start and land autonomously (Buran), or capturing small items dropped from orbit mid-flight over the ocean (Corona program, see [0]), precisely targeting cruise missiles [1], etc. - all without the benefits of microcomputers we know today, without high-level languages, cheap computing devices, etc.

It seems that back then people were more focused on making things actually work instead of making them look sexy and easy to sell.

[0] - https://en.wikipedia.org/wiki/Corona_(satellite)#Recovery

[1] - https://en.wikipedia.org/wiki/Inertial_navigation_system#His...

It required unbelievable amount of man power and money to do those things. The real benefit to all our modern technology is to do more with less. It's not that people were more focused; it's just that there were many more of them and there was way more money involved.

JavaScript, unlike C#, is intended to be easily implementable. The team that built Mono had a mountain of work to do before that was a useful product.

Meanwhile a college-level student can probably write a JavaScript interpreter that passes all the specification tests in six months. It won't be fast, but it will work.

Yes, there are better languages, but stop freaking out. If you're such a fan of C# then work on getting C# to transpile down to JavaScript, asm.js, or WebAssembly and ignore the ugly parts of the JavaScript language entirely.

JavaScript is both amazing and ridiculous all at once. Deal with it.

What huge application are built with javascript? Visual Studio Code is probably the biggest I can think of and I don't know what would be second.

VS Code is built with TypeScript.

Brave, Slack, Atom, Popcorn Time, I'm sure there are many others. Electron (http://electron.atom.io/) is becoming a popular framework to use.

I think the OP meant huge in terms of complexity rather than memory usage..

Brave is a web browser, so I'd give electron most of the credit for making that work. Popcorn time I don't know anything about.

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

Yes, admittedly, none of these are that complex. I thought Visual Studio Code was built ontop of Atom, but I might be wrong. Both built on Electron anyway - which was originally part of Atom.

> Languages don't scale.

Why not?

Minor comment regarding CSS: Flexbox alone was never supposed to fix layout; the real magic is supposed to be Flexbox + CSS Grid. As I understand it, Flexbox is truly designed for use in one dimension to govern local dynamic behavior within a larger CSS Grid layout that structures the whole page. At the moment the problem is the lack of CSS Grid adoption by browsers (see http://caniuse.com/#feat=css-grid). I'm still hopeful that the state of CSS layouts will drastically improve once Grid and Flexbox are both sufficiently supported.

CSS is not impossible to manage if you keep things modular and avoid specificity issue (basically, use something like BEM and pretend the "C" in "CSS" doesn't exist).

re: HTML: layout and positioning is the domain of CSS, not HTML. HTML's purpose is to provide semantic structure to the content and non-semantic styling hooks (divs and classes) for CSS.

It's true that layout has sucked for a long time (more accurately, it hasn't really existed in CSS), but with the coming grid spec, it will finally get a lot better. Flexbox is great for solving certain problems, but wasn't intended to deal with overall page layout. (Basically, flexbox is for laying out one dimension -- a single row or column -- whereas the grid layout spec will handle two-dimensions.)

We use BEM and Sass at work and our CSS is still an unwieldy mess.

Ever thought you're just not that great at writing it?

I tend to use a combination of BEM component based rules and AtomicCSS inspired class-style, and my Sass tends to be pretty damn clean.

I think a lot of the problems with "web dev sucks!!12" mentality is that people come to it thinking that it should be easy, but it really isn't, and it's not going to be anytime soon.

Trying to build applications for multiple browsers to be used on multiple devices on multiple OSs that look good and work well isn't an easy job.

No, it's not perfect, but if you pay enough attention and do things right then it's quite a nice experience.

If your CSS sucks, maybe don't blame your tools before you blame yourself.

The thing that makes me dubious of this claim is the number of years for which we've been reading variants of, "the upcoming (grid/flex/canvas/css3/html5/ecma spec/etc) will make things much better".

I was talking specifically about layout (because the comment I was replying to mentioned layout specifically). I don't think any of the things you listed promised to improve layout, except flexbox and grid. And flexbox does improve one-dimensional layouts -- vastly so. I suppose the jury is still out on the grid spec, but it is in the process of being implemented by all the browsers and you can actually play around with it (behind feature flags).

Literally all of the things you listed have made web programming much better.

We use TypeScript and at first it seems like a burden, but pays off after a while. We used to have a problem with CSS - every time we had to implement some new UI, we just ended writing stronger selectors to override the parts that felt would break if we refactored them. CSS modules solves that problem for us. It's nice that we are allowed to use flexbox. The biggest problems for us are that <video> events are not being dispatched properly or scaling problems when keyboard appears.

> HTML - At the heart of it, the foundation is the layout engine and positioning

I'd oppose: HTML is particularly a Markup Language for (more or less) semantically structured static documents tied together with Hyper Text links (see the abbreviation?). It has with very limited (if any) amount of layout, positioning and visual hints incorporated; these things are supposed to be left for the CSS.

These complaints are all valid and serious. I believe the solutions involve writing more readable code in languages that compile down to Javascript, CSS, and HTML.

There are thousands of languages that compile down to JS. https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

There are several languages that compile to CSS, like COMPASS and SASS.

There are various document formats that freely convert to and from HTML, like Markdown and DocBook. However, HTML is probably the most readable of JS/CSS/HTML.

While you can write native JS/CSS/HTML, you're inviting unintended complexity to your project whether or not you remember sending the invitation. There's nothing wrong with that, but you should be aware which choices are best for your team and for the scope and requirements of your project.

Those are incredibly leaky abstractions. You have to know the language, you have to know javascript (for debugging) and in many cases you have to know exactly how the language is transpiled into javascript.

> JavaScript - Dynamically typed, does not scale

What does this even mean? I see the phrase "does not scale" bandied about all the time. In what way is a language supposed to scale? It seems like its just the latest semi-technical hand-wavy way to disparage something.

I think he means very large projects. > 10k loc. See http://www.pgbovine.net/migrating-legacy-codebase-to-typescr... for example

Blaming JavaScript's failure to be maintainable on being dynamically typed is a bit of a red herring in my opinion. Lots of dynamically typed (or, more accurately, duck-typed) languages have plenty of facility to make good, maintainable code, and JavaScript does too. The problem is that JavaScript has more warts than good parts, and the warts prove to be too easy a temptation for many average programmers.

While I agree with most of what you wrote, I also understand where it all came from. We have a handful of browsers which all implement w3c guidelines in their own way and there's no single de-facto standard of how one should write for web. Yet we write milions of different websites and they have to be properly displayed on at least a couple of popular browsers, no matter how bad they interpret the guidelines.

Yes JS is a major pain in the a and there are loads of various packages achieving the same things floating around, there's no agreement regarding which package manager to use and everybody uses different implementation or wrapper (es6, es7, typescript, flowscript, coffee), but if you look around you can find solutions that are actually really helpful to manage the mess. It helped me a lot when I started to write JS in a OOP fashion utilizing dependency injection and MVVM. The real trick is to realize which technology is really helpful and which is just bloat. I don't think this is much different from the backend programming.

In terms of CSS it's a whole world on its own and I keep repeating that managing it properly is well underestimated. It requires making lots of predictions about how you might extend your site in the future. Luckily, there is also plenty of great reusable boilerplates made by very smart people like bootstrap or materializecss. Bootstrap did change a lot how we write and think about our styles. Btw, leave classes for styling and use ids for js instead.

Finally, I don't agree with your opinion on HTML at all. It's super simple and you can build anything with it. I have learned the basics and built my "home page" when I was 12. These days kids are probably building sites before they even go to school. Also, as mentioned above you have to fit dozens of different browsers and hundreds of thousands of various devices. I find building UIs on iOS and Android not much easier, even though you build for a single system. Nonetheless I'm waiting to see how people could improve building UIs in the future, without falling into "everything looks and feels like wordpress" kinda world.

I think it's important to acknowledge that today we're using CSS in ways that were hard if not impossible to imagine for the creators of the standard years ago.

The much higher complexity requires new ways of thinking and methodologies.

BEM for example is one such approach which helps with scaling.

It sounds like you are unfamiliar with what modern JS looks like.

> JavaScript - Dynamically typed, does not scale what so ever.

Flow has resolved this. It has good investment from Facebook, plenty of adoption, a flexible type system, and you can sprinkle it into existing code as you like.

Also try wallaby.js for instant test running.

> CSS - Also becomes impossible to manage.

See webpack's local css scope. https://github.com/webpack/css-loader.

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

Bootstrap or any million css libraries. Just have to wait for Flexbox and we are good.

Indeed. You only left out the proliferation of frameworks du jour, which promised to deliver us from this pain, yet somehow seemed to only amplify it with additional layers of pain.

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

Consider the _brighter_ side of it:

- the one who authored the code is irreplaceable

- employment generation: many more are needed to maintain (and possibly enhance) what one person might have written

So instead, just use:

* TypeScript * Sass * A data-binding framework like Angular

Problems solved :)

Only, in my case, I don't think of it as high paying.

When I see something like visual studio code to cite the first that comes to mind I think that these claims are overstated.

> Same problem, read-only, it only gets bigger

I think that's write-only

look at elmlang maybe ? it solves a few of these problems, but this is quite different from what we are used to.

The web was conceived for hypertext and doesn't do a bad job of it.

The actual problem is that people took something that was always intended for displaying (illustrated but mainly text) documents that happened to have clickable words that would display other documents, and tried to make it do desktop-style applications too. We've been hammering square pegs into round holes ever since.

And the infuriating thing is we had a great system for doing what HTML+JS+AJAX etc etc does now - it was called NEWS. But those who forget history are doomed to repeat it, first as tragedy and then as farce. Not sure which stage we're on now, maybe both.

>clickable words that would display other documents

https://en.wikipedia.org/wiki/NeWS ;)

That's exactly what I was going to say. It was never meant for all of this in the first place. We've spent millions of man-hours trying to turn a squirrel into a dinosaur.

Worse yet, it's becoming more and more difficult to simply read the freaking web as a series of documents, which was the entire purpose in the first place. There's TOS, pages that don't work without JS, and so on. I fully expect publishers to try to force legislation to require people to download all this crap simply to read an essay, whether they want to or not.

We had a nice hammer, and we're doing a pretty good job of pounding everything else in the universe into various versions of a nail. But it's ugly.

>We've spent millions of man-hours trying to turn a squirrel into a dinosaur.

And worst of all - we succeeded.

Is it really square pegs for round holes?

I don't think that the web as a mechanism for distributing applications would look much different even if it hadn't gone through the HTML stage. If not JS, it would have been Java applets. If not HTML, then some weird XML layout schema.

There might have been a time where the web as a platform for applications was beyond silly, but this is not htat time. The platform is decidedly for shipping applications as well as pages.

It's, but not by design.

...and? There are plenty of things that were "designed" for one thing and used for something totally different.

So using the right tool for the job is a poor metaphor in programming? Or is it advice that gets continually ignored?

Well, when HTML/CSS/JS are the only tool for the job, they're the right tool for the job, that's for sure.

Maybe HTML5 isn't the best option for mobile apps, but they can be used, and it even has advantages in some areas (ease of cross-platform development, for instance)

but it could be a lot better, and thats the whole point of the thread.

> It's, but not by design.

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?

Oberon also used the model. There was even an Oberon-based, Javascript replacement for mobile code, too.

https://en.wikipedia.org/wiki/Oberon_(operating_system)

NeWS was a lovely thing (and the HyperNeWS environment that was built on it is still one of all time favourite frameworks) but I'm not sure it was directly comparable with HTML+JS+AJAX - it was more like an attempt to do a better X11.

Specifically I don't remember (even, ironically given its name, in HyperNews) there being much support for working with documents or hyperlinks. Mind you - it did do the client side scripting in a wonderful way (at least if PostScript is your thing).

I also seem to remember that it didn't have a particularly strong security model?

They are all variants on the cross-platform thin-client theme. The HTML+JS+AJAX conglomeration has certainly more in common with NeWS than it does with the web I remember in 1994, which was a solution to the problem of sharing and cross referencing scientific papers and similar documents.

Yeah - I suppose that is fair. Certainly with HyperNeWS the fun[1] was creating a user interface interactively and then connecting it to your back end application via message passing.

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

Indeed, NeWS was at the level of X11, but tuned to the hardware and networking set up we ended up having instead of the DEC 11/750<-very fast fiberoptic link->[display head with a 68000, 1MiB of memory, ~1 megapixels, i.e. pretty dumb, all this to get around government procurement law], but with Sun insisting on 6 figures to license it, it didn't have a chance.

Supposedly the major reason James Gosling insisted Sun not charge for Java runtimes and the SDK, he didn't want another major effort of his to fail for the same reason.

I think you mean write-only.

It doesn't help that the inclination to minify and bundle CSS and JS makes them somewhat impervious to organization. Sourcemaps are supposed to help with that, or so I've heard... they are another of those things that I've not seen work reliably.

When you build a better language, server platform, viewer application, development tools and ecosystem that can create, render, transmit and load dynamic user interfaces over the wire - even rapidly on limited bandwidth connections - please let me know ;)

I'm not saying it's the best thing ever, but we're not doing too badly all things considered.

The web is still young. Let's work together to make it what we want it to be - what it should be - instead of moaning about what it isn't.

Reply on news.ycombinator.com