Ask HN: Is web programming a series of hacks on hacks?
685 comments
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.
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.
If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages and three frameworks:
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.
* HTML
* CSS
* JS
* A server-side language (eg Python)
* SQL
* A framework to make JS bearable (eg Angular)
* A framework to make server-side bearable (eg Django)
* A framework to make CSS bearable (eg Bootstrap)
* A framework to make SQL bearable (eg SQLAlchemy...)
Trying to fix this, at least for simple apps, is why we built Anvil - https://anvil.works - where everything is in Python, and the GUI is drag'n'drop.
"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?
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?
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.
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.
> 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.
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.
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.
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.
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.
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
> 0.0/0.0 == Double.NaN
false
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.
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 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.
And in Javascript, it's still a nightmare importing a file. You either have a or you are on nodejs.
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 :)
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).
This is where Typescript comes in. It's beautiful.
> 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.
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);
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.
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
[1] https://www.npmjs.com/package/mssql-ng
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.)
(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.)
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.
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.
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.
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
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.
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)
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)
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).
- 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
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.
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.
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 ;-)
> ... to abstract away SQL
SQL already is an abstraction, why would I want to abstract it away? Why not abstract JS away instead?
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.
It's all just fluctuating fields in the vacuum?
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).
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"
> Why not abstract JS away instead?
Lots of projects are already doing this: Elm, ClojureScript, PureScript, etc.
Lots of projects are already doing this: Elm, ClojureScript, PureScript, etc.
"thats it"
250mb worth of dependecies later...
250mb worth of dependecies later...
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.
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...
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.
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 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.
I haven't done it myself, but you could try to replace most of your stack from the database up, with a single language:
http://www.swi-prolog.org/FAQ/PrologLAMP.txt
You'll still need the three stooges but at least you'll have a single language behind them.
> If 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 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.
> 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.
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.
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
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 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.
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).
+ 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.
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.
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.
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.
OR...
* JavaScript (client and server)
* Redux (state management)
* React (UI Control framework)
* MaterialUI Controls (toolkit, one of many)
* JS Friendly DB
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.
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.
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.
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.
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.
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
[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?
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.
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.
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.
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.
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...
We just need to standardize the glue...
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.
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.
But after reading the justification it will be better in the long run.
We just need some way to lazy load modules.
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 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.
[deleted]
... 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.
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 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.
HTML, CSS and SQL aren't programming languages, if Turing completeness is a requirement to be a programming language.
> 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.
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".
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...
As does SQL : http://stackoverflow.com/questions/900055/is-sql-or-even-tsq...
This is a language lawyer nit-pick comment that doesn't add anything to the discussion.
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 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.
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.
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.
Of course, nobody does this in practice.
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.)
(Oh, BTW, JavaZone 2016 was Oracle-free and all talks seems to have been uploaded to vimeo with no restrictions on downloading.)
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
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.
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.
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.
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...
Brilliant observation. That actually never occured to me.
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?
> teetering Jenga tower of hacks?
How is any programming language not capable of being brittle?
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 ...
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 ...
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.
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?
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/
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-...
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
* 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
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.
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.
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. ;)
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. ;)
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
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.
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.
[deleted]
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.
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.
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.
But hey man, that's just like your opinion.
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.
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.
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
HTML and CSS aren't as complex as those. Not even close
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.
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.
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.)
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.)
> 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. 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?
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.
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 to pick the right one: age ("old" but not too old) x community x documentation
For the simplest developments I used jQuery (which is a thin layer over pure JS). If you need more complexity you could go for a higher level framework (but there were not so great things like JavascriptMVC)
PHP gets a lot of bad rap but Fb is built on it
There is no perfect solution. When I see people "praising" Win32 I can just laugh (no, really, anything is better than this: https://msdn.microsoft.com/en-us/library/bb384843.aspx) but I think the advantage of that is that there was only few alternatives so once the learning curve was gone that was it)
I 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.
> 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/
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.
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.
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.
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 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.
Not just an impression. They often are actually more responsive. Except when they hang, which does happen sometimes, but then so do web apps.
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?
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.
- 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.
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
They could be made portable if an equivalent amount of effort was spent devoted to that goal.
> But Tcl/Tk is the most easiest GUI toolkit ever, too bad the resulting UI does not look professional.
ttk does
ttk does
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.
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.
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.
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.
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.
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.
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.
[deleted]
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.
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.
You can create controls in WIN32 or MFC that would simply be impossible in HTML for a reasonable level of performance
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.
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.
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.
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.
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.
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...
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...
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...
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.
[deleted]
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?
> 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.
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.
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.
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.
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.
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.
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.
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 ..... .
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.
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.
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.
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.
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.
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.
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#.
Also I didn't mention just C#.
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.
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.
> 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 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.
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.
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.
> 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.
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.
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.
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).
> 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.
Have you looked at the microservices craze lately? You need a new one of these each time you scratch your head.
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.
And even their code is still often bloated, maddening hacks on hacks.
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.
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.
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.
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".
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/
1. http://www.gwtproject.org/
If GWT doesn't count as hacks built upon hacks, then I don't know what does...
> 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/
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/
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.
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).
> 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.
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!
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.
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.
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:
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.
The computer for the Apollo missions had approximately 64Kbyte of memory and operated at 0.043MHz. My wrist-watch is many orders of magnitude more powerful than that. But the programming effort that went into it was huge (literally: https://cdn-images-1.medium.com/max/800/1*qJnPOGdtk1q7dq17tx... ). If we were stilling coding things that way, we might be able to go to the moon but we wouldn't have self-driving cars.
> Pick a language, any language, and then restrict yourself to features only ten years old.
C# 2.0 in 2006 added:
Generics
Partial types
Anonymous methods
Iterators
Nullable types
Getter/setter separate accessibility
Method group conversions (delegates)
Co- and Contra-variance for delegates
Static classes
Delegate inference
JavaScript is so far away from this it's not even funny. It doesn't even have proper numeric types. It's casting rules compare favorably with PHP!
So I don't buy the argument that JavaScript isn't suitable for large projects because browser makers aren't keeping up with the latest standards. JavaScript is a scripting language that's been pushed into tasks it's not suitable for because it is everywhere.
> 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.
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?
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 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.
> 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
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.
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.
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.
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?
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.)
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.)
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".
Literally all of the things you listed have made web programming 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).
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
- 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
[deleted]
So instead, just use:
* TypeScript * Sass * A data-binding framework like Angular
Problems solved :)
* 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
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.
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 ;)
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.
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.
And worst of all - we succeeded.
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?
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?
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.
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.
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...
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...
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.
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.
> 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?
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?
...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)
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.
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)
https://en.wikipedia.org/wiki/Oberon_(operating_system)
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.
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.
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.
I think it's worth noting that back-end web development is an usually pleasant place. In most other types of programming, many technical decisions are made by the platform and working with tons of legacy cruft is the norm, not the exception. For example, where else can you so freely choose the programming language?
Linux Driver? Use C. Mobile App? Java or Swift/Objective-C for Android or iPhone, respectively. GUI App? Again depending on your platform that will be either C++, Swift/Objective-C, or some .NET thing. Making a neural net? You could do everything from scratch, but it probably makes more sense to just use a platform like Tensor Flow and python.
Backend web development on the other hand: use anything! Wanna use lisp? Go ahead. Wanna store your data in an unproven experimental database? No problem. Wanna use micro-services? Monoliths? Anything goes.
Browsers are extremely complex application platforms. But despite how you may feel, they didn't succeed because of their weaknesses. The browser as an application platform succeeded because of its strengths. Web browser are the least bad option (and beat out many other worse options).
For better or worse, browsers are what we have. Make the most of their strengths, and deal as best you can with the weaknesses.
Linux Driver? Use C. Mobile App? Java or Swift/Objective-C for Android or iPhone, respectively. GUI App? Again depending on your platform that will be either C++, Swift/Objective-C, or some .NET thing. Making a neural net? You could do everything from scratch, but it probably makes more sense to just use a platform like Tensor Flow and python.
Backend web development on the other hand: use anything! Wanna use lisp? Go ahead. Wanna store your data in an unproven experimental database? No problem. Wanna use micro-services? Monoliths? Anything goes.
Browsers are extremely complex application platforms. But despite how you may feel, they didn't succeed because of their weaknesses. The browser as an application platform succeeded because of its strengths. Web browser are the least bad option (and beat out many other worse options).
For better or worse, browsers are what we have. Make the most of their strengths, and deal as best you can with the weaknesses.
This is exactly why I've always been puzzled by the urge to move more and more logic to the frontend. In backend development you have a choice of many mature languages, tools and frameworks which are fairly sane. I'll take that environment as the foundation of a web application any day and apply the mania of client-side javascript to it selectively in cases where we need to minimize server roundtrips.
> why I've always been puzzled by the urge to move more and more logic to the frontend.
This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application.
* Scale: if the client makes fewer request of the server(s) then you have reduced server and network requirements. As server resources get cheaper (and the cheap options more reliable) that side of things is becoming less important, but the network requirements extend far beyond you and almost all the way to the user (see the following two points) who might have a very slow connection at times.
* Responsiveness: the more that you can do client side the quicker your application will feel to the user, even if there is a delay in updates actually hitting the global view you can make it look/feel instantaneous (though you do start to have more problems wrt conflict management when people are collaborating). Have a look at the different methods online games (where real responsiveness and the appearance of instant iteration are vital) manage this.
* Partition resilience: if the client can keep working for a while without needing to talk to other hosts, perhaps queuing updates for reply when communication is restored, your application can keep functioning if there is an issue at your end (glitch at your server provider perhaps) or the user's (on mobile and temporarily in a radio blackspot?) or in between (i.e. a routing issue between ISPs). Even partial resilience is better than none: even if I can't see other people's updates until I'm back in a good signal area, if the app calmly tells me so but allows me to continue to add my work and review already locally cached information I can continue to work (or play!) in a way that wouldn't be possible if more of the logic were server-side.
This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application.
* Scale: if the client makes fewer request of the server(s) then you have reduced server and network requirements. As server resources get cheaper (and the cheap options more reliable) that side of things is becoming less important, but the network requirements extend far beyond you and almost all the way to the user (see the following two points) who might have a very slow connection at times.
* Responsiveness: the more that you can do client side the quicker your application will feel to the user, even if there is a delay in updates actually hitting the global view you can make it look/feel instantaneous (though you do start to have more problems wrt conflict management when people are collaborating). Have a look at the different methods online games (where real responsiveness and the appearance of instant iteration are vital) manage this.
* Partition resilience: if the client can keep working for a while without needing to talk to other hosts, perhaps queuing updates for reply when communication is restored, your application can keep functioning if there is an issue at your end (glitch at your server provider perhaps) or the user's (on mobile and temporarily in a radio blackspot?) or in between (i.e. a routing issue between ISPs). Even partial resilience is better than none: even if I can't see other people's updates until I'm back in a good signal area, if the app calmly tells me so but allows me to continue to add my work and review already locally cached information I can continue to work (or play!) in a way that wouldn't be possible if more of the logic were server-side.
I recently moved more logic out to the frontend for the one and only reason of Responsiveness. The experience was a lot better, with the sole exception of older android phones on wifi (all these new improvements to cellular data means we have a lot more bandwidth than we used to, but latency is often no better now than it was a decade ago).
>This is usually about a mix of scalability, responsiveness, and partition resilience; with the level of importance of those being dependent on the application.
I have never seen anyone make those arguments. I've seen people vaguely reference them in a hand wavey "I don't understand this but google facebook I am right" way. But that's as close as it gets. It is usually about following trends.
I have never seen anyone make those arguments. I've seen people vaguely reference them in a hand wavey "I don't understand this but google facebook I am right" way. But that's as close as it gets. It is usually about following trends.
In some cases it may be about following trends.
But this particular trend started from an effort to push things client-side for good reasons that are vital, or at least useful, to many projects. It being trendy doesn't necessarily mean it is wrong! Don't be so fast to dismiss something because to don't immediately see/understand the benefit.
There is often some confusion between "mobile first" and "offline first" - the two overlap considerably but being a good mobile app doesn't absolutely necessitate being able to operate offline and offline capability does not require or imply an app will be usable on mobile (it may be to large and/or fiddly in terms of UI on a small screen, not practical to use in a touch manner, or too demanding of CPU and memory resources). Some of the hand-wavey-ness is people who know they are driving for "mobile first" and think that means they have to drive for "offline first" without really understanding the benefits & implications of that.
But this particular trend started from an effort to push things client-side for good reasons that are vital, or at least useful, to many projects. It being trendy doesn't necessarily mean it is wrong! Don't be so fast to dismiss something because to don't immediately see/understand the benefit.
There is often some confusion between "mobile first" and "offline first" - the two overlap considerably but being a good mobile app doesn't absolutely necessitate being able to operate offline and offline capability does not require or imply an app will be usable on mobile (it may be to large and/or fiddly in terms of UI on a small screen, not practical to use in a touch manner, or too demanding of CPU and memory resources). Some of the hand-wavey-ness is people who know they are driving for "mobile first" and think that means they have to drive for "offline first" without really understanding the benefits & implications of that.
You are responding to a strawman. I said nothing about the trend, much less dismissed it. I addressed the reasoning I've seen people use exclusively to push for it.
I think it mainly comes from the fact that web applications are becoming more interactive. If you are going to implement photoshop in the browser, there's going to be a lot of client side logic.
Before, web development was more like, "fill in this form and when you're ready hit submit and we'll check it." Now people are implementing word processors and music libraries.
Before, web development was more like, "fill in this form and when you're ready hit submit and we'll check it." Now people are implementing word processors and music libraries.
That's very true, there are web apps where "cases where we need to minimize server roundtrips" are the default case. For these situations it makes sense to run a lot of the logic on the client.
However it seems like this has been taken way too far -- I run into a fair share of developers out there who look at basically any proposed web app and say, "Oh yeah, this needs to be a SPA built with React." Why? "Because it's better" and then a rattling off of generic reasons that SPA and doing everything client-side are superior. This is basically the modern version of the Lisp fanboy, they find a good hammer they want to work with more and now everything they see is a nail.
These are often the younger guys who have not yet seen this pattern carry itself out over a generation or two of developers -- if there's any reason why tech ageism is amazingly dumb it's this one imo (have the guy on your team who's graduated past the fanboy stage make your tool, platform and framework choices, you will save far more than the premium that you have to pay him).
However it seems like this has been taken way too far -- I run into a fair share of developers out there who look at basically any proposed web app and say, "Oh yeah, this needs to be a SPA built with React." Why? "Because it's better" and then a rattling off of generic reasons that SPA and doing everything client-side are superior. This is basically the modern version of the Lisp fanboy, they find a good hammer they want to work with more and now everything they see is a nail.
These are often the younger guys who have not yet seen this pattern carry itself out over a generation or two of developers -- if there's any reason why tech ageism is amazingly dumb it's this one imo (have the guy on your team who's graduated past the fanboy stage make your tool, platform and framework choices, you will save far more than the premium that you have to pay him).
> [...] I've always been puzzled by the urge to move more and more logic to the frontend.
Moreover, we've already had applications written in client-database architecture, and it was nowhere near pretty. Fortunately they died long ago, but unfortunately they're resurrected now again.
Moreover, we've already had applications written in client-database architecture, and it was nowhere near pretty. Fortunately they died long ago, but unfortunately they're resurrected now again.
Network performance increases and reliability have taken a step back due to the shfit to wireless, and client devices have become more powerful relative to servers.
If the 1995-2005 trends had continued, by now internet services would be served by 15 GHz servers and low-latency 1-10 gigabit networks.
If the 1995-2005 trends had continued, by now internet services would be served by 15 GHz servers and low-latency 1-10 gigabit networks.
The reason for doing that is that you can deliver experiences that are impossible if you do everything in the backend.
What are the current best systems that generate rich data models and runnable processing rules from the backend?
Remember MS-DOS also succeeded because of its "strengths" in some very special, narrow sense. In the more ordinary sense, it succeeded in spite of its weakness, but Windows has slowly recovered from that and is now a good system.
The modern web is somewhat the the reverse: it is worse than its progenitor. HTML, HTTP and what would eventually be called ReST were all good ideas and succeeded because (a) they were a good way to put hyperlinked multimedia on the internet and (b) hyperlinked multimedia turned out to be the thing that masses of users wanted.
The subsequent effort to retrofit that and turn it into a zero-install software delivery platform is where all the insane hackery comes from; and the hacks that succeeded didn't have to be good. They are just what worked at the time with some combination of IE, Netscape and Flash.
The modern web is somewhat the the reverse: it is worse than its progenitor. HTML, HTTP and what would eventually be called ReST were all good ideas and succeeded because (a) they were a good way to put hyperlinked multimedia on the internet and (b) hyperlinked multimedia turned out to be the thing that masses of users wanted.
The subsequent effort to retrofit that and turn it into a zero-install software delivery platform is where all the insane hackery comes from; and the hacks that succeeded didn't have to be good. They are just what worked at the time with some combination of IE, Netscape and Flash.
It's not good, just better than anything else.
If things like running apps over an x-display server didn't totally suck, then the clients would have been adopted and eventually it would be zero install. God didn't command that browsers be installed everywhere. Companies and users did so of their own free will.
Maybe I haven't dug deep enough, but what are these alternative, non-hacky delivery platforms that the world passed up in favor of the web? The ones I've heard about have tons of problems, just like browsers.
If things like running apps over an x-display server didn't totally suck, then the clients would have been adopted and eventually it would be zero install. God didn't command that browsers be installed everywhere. Companies and users did so of their own free will.
Maybe I haven't dug deep enough, but what are these alternative, non-hacky delivery platforms that the world passed up in favor of the web? The ones I've heard about have tons of problems, just like browsers.
That was the promise of Java - write once run anywhere. JavaScript managed to achieve it instead.
You mean the browser achieved it instead of the JVM. It could have been something other than JavaScript as the scripting language. What mattered was the platform everyone ended up using.
For practical purposes it's the same either way.
But it's not the same, because not all platforms use a markup language with a separate style language in addition to the actual programming language.
A JVM or .NET based web would have been a very different kind of platform.
A JVM or .NET based web would have been a very different kind of platform.
What I mean is that the VM and the language are a package, in this case.
IMO the browser's strength is really 'zero-install distribution of applications', I don't think HTML/CSS/JS have anything to do with it.
Having said that, I think your argument its a straw-man, back-end web development is just a part (sometimes even unnecessary) of browser programming.
Having said that, I think your argument its a straw-man, back-end web development is just a part (sometimes even unnecessary) of browser programming.
This is why I don't understand the purpose of electron apps. Why not remove the electron part and just install and run a local http server written in any language and access it from your browser? No need to download the same 50MB+ for electron every time. The overhead from running multiple browser engines is gone. Basically everything is as it should be.
The Kimchi KMV UI is a pretty good example how to do it. https://news.ycombinator.com/item?id=12477030
The Kimchi KMV UI is a pretty good example how to do it. https://news.ycombinator.com/item?id=12477030
Marketing. People pay more for an application than a web page. Why did YNAB change from being a spreadsheet to an app?
Well I think it has something to do with the web's success.
For one thing, the HTML/CSS/JS separation of concerns made it so that someone could make a non-interactive, static web page with very little knowledge. The basics of HTML and CSS can be taught in a week. This is important! I think we would have far less success training people to create static documents with many of the various programming language UI Kits. Though becoming less important, there was definitely a time when this helped to increase the adoption of browsers (and I would argue still makes it easier to teach).
Another thing, is the HTML/CSS/JS were all open standards that have accepted contributions from a wide range of parties. Look at scheme: beautiful, consistent, and completely unused. HTML/CSS/JS would without question be much more pleasant if they had been designed by a benevolent dictator. But open nature of the RFC process I think both greatly helped adoption as well as contributed to the inconsistent nature of the APIs.
You only have zero-install (i.e. ships with the OS) because the web got wide spread adoption, and I think HTML/CSS/JS contributed to that.
For one thing, the HTML/CSS/JS separation of concerns made it so that someone could make a non-interactive, static web page with very little knowledge. The basics of HTML and CSS can be taught in a week. This is important! I think we would have far less success training people to create static documents with many of the various programming language UI Kits. Though becoming less important, there was definitely a time when this helped to increase the adoption of browsers (and I would argue still makes it easier to teach).
Another thing, is the HTML/CSS/JS were all open standards that have accepted contributions from a wide range of parties. Look at scheme: beautiful, consistent, and completely unused. HTML/CSS/JS would without question be much more pleasant if they had been designed by a benevolent dictator. But open nature of the RFC process I think both greatly helped adoption as well as contributed to the inconsistent nature of the APIs.
You only have zero-install (i.e. ships with the OS) because the web got wide spread adoption, and I think HTML/CSS/JS contributed to that.
> Making a neural net?
That's not as constrained as you might think[1] but yes, I get your main point and, as a back-end web developer, I agree.
[1] https://en.wikipedia.org/wiki/Comparison_of_deep_learning_so...
That's not as constrained as you might think[1] but yes, I get your main point and, as a back-end web developer, I agree.
[1] https://en.wikipedia.org/wiki/Comparison_of_deep_learning_so...
JVM can be targeted from Scala or Frege too.
You argument boils down to transpiler availability.
You argument boils down to transpiler availability.
It is scary how most commenters here are missing the point. No, not all programming sucks. Yes, web programming sucks more than other things. No, it doesn't have to be like this. Yes, even web programming was better 10 years ago. No, I don't know how to fix it. Neither do I know exactly where we took the wrong turn.
One of my theories is this: had Sun not sued Microsoft over their extensions in JVM, MS would have kept working on their awesomely fast JVM implementation for Windows. That would make Java fast and not sucky in browsers. It would have kept Java Applets as a viable rich web app development option. Flash would have never risen. Java, being a significantly superior language to ActionScript, would have allowed us to build nice RIAs in an efficient, secure and portable way. Gmail and Google Maps would have been implemented in Java. Isometric Java. Get it? Get it? Back end and front end are written in the same language with strong typing and all that. JavaScript would have been dead by now. World would have been a better place.
I'm sorry but I beg to differ, web programming 10 years ago was a nightmare. It's much better today. It's not web programming that sucks, it's programming with others. I bet most people won't complain much if they got choose what tools they wanted and worked alone. When working with others, different ideas and opinion clash heavily. Programmers are not best known for their awesome communication and the lack of it leads to more mental strain than necessary.
The reality is that one can drive the frontend with 100% javascript no frameworks, html, css, keep things simple avoid the framework nightmare. Use typescript if the project is large enough. How come people are not doing this? Because they are not putting in the time to learn the language, it's all about learning framework. I see the same in backends, people who know rails but not ruby, laravel but not not enough php, android framework but not enough java. This is the problem.
The reality is that one can drive the frontend with 100% javascript no frameworks, html, css, keep things simple avoid the framework nightmare. Use typescript if the project is large enough. How come people are not doing this? Because they are not putting in the time to learn the language, it's all about learning framework. I see the same in backends, people who know rails but not ruby, laravel but not not enough php, android framework but not enough java. This is the problem.
I maintain a web-application by myself: I choose the platform and exactly which bits I wrote myself, and whre I pulled things in from other sources.
It still sucks. The target environment is undefined. In most programming problems we start with with a well defined target environment (or at least the language semantics are well defined and we quickly learn where the platform-specific hacks are).
In web programming each of the browsers is slightly different in about a hundred different ways. The main goal of using the web (presenting a platform independent UI without needing to download native code) is not entirely achievable. Instead, each year we apply slightly different hacks to go around in circles.
It still sucks. The target environment is undefined. In most programming problems we start with with a well defined target environment (or at least the language semantics are well defined and we quickly learn where the platform-specific hacks are).
In web programming each of the browsers is slightly different in about a hundred different ways. The main goal of using the web (presenting a platform independent UI without needing to download native code) is not entirely achievable. Instead, each year we apply slightly different hacks to go around in circles.
> In web programming each of the browsers is slightly different in about a hundred different way
Is this actually true? There are stable, well-tested shims for just about everything out there. CSS strikes me as the only tricky bit, but generally if IE8 users don't get to see an animation I don't really care.
Is this actually true? There are stable, well-tested shims for just about everything out there. CSS strikes me as the only tricky bit, but generally if IE8 users don't get to see an animation I don't really care.
> The target environment is undefined.
Nope, that target environment is a responsive, standards compliant software. Code for the standards and the displaying devices will catch up.
Nope, that target environment is a responsive, standards compliant software. Code for the standards and the displaying devices will catch up.
Something largely only possible in hobby projects unfortunately.
On hobby projects I support only standards. Your browser not to spec? Not my problem. Well, it would be my problem, due to less traffic from people with broken browsers, but I don't monetize or track my traffic.
Professionally, I'm over here supporting IE8 and Safari 5 (the last version available to Windows) still. Next year we'll finally be dropping IE (all versions) so only a few more months to go.
Unfortunately if something is broken in Chrome or Firefox - I get to fix it. Then when the browser finally fixes it - I get to go fix it by removing the old fix which now breaks things. Really unproductive but I can't argue against it.
On hobby projects I support only standards. Your browser not to spec? Not my problem. Well, it would be my problem, due to less traffic from people with broken browsers, but I don't monetize or track my traffic.
Professionally, I'm over here supporting IE8 and Safari 5 (the last version available to Windows) still. Next year we'll finally be dropping IE (all versions) so only a few more months to go.
Unfortunately if something is broken in Chrome or Firefox - I get to fix it. Then when the browser finally fixes it - I get to go fix it by removing the old fix which now breaks things. Really unproductive but I can't argue against it.
All true, but imagine you didn't have these browsers sitting between your code and the native OS. Would that be any cleaner?
At least browser vendors do try to conform to some common specs and any deviation from the spec can be bridged using JavaScript libraries.
Without browsers as a target you might find yourself supporting ancient Android versions and Windows XP.
At least browser vendors do try to conform to some common specs and any deviation from the spec can be bridged using JavaScript libraries.
Without browsers as a target you might find yourself supporting ancient Android versions and Windows XP.
"it's not web programming that sucks, it's programming with others."
Most non-trivial systems require several contributors. 'Professional' means among other things being able to work with others.
"When working with others, different ideas and opinion clash heavily."
Sounds like herding cats. Any complex system should have a technical lead/architect who actually has the authority to say which technologies will be used. It does not mean he shouldn't discuss this with others - but the fact that there is one authority in the end simplifies things.
Most non-trivial systems require several contributors. 'Professional' means among other things being able to work with others.
"When working with others, different ideas and opinion clash heavily."
Sounds like herding cats. Any complex system should have a technical lead/architect who actually has the authority to say which technologies will be used. It does not mean he shouldn't discuss this with others - but the fact that there is one authority in the end simplifies things.
... and this is the problem. when you are using a library from github, you are programming with others. when they break those libraries, they are breaking your application, any bug in it creeps into your application, if the interface is poorly designed, your code will be hackish to get around it, if it's a pain to setup and configure, you have to deal with it. most programmers today are programming with others, and there's no technical lead. you grab 5 different packages, they all have different styles. In the javascript world people sometimes end up with libraries clashing over each other. This is what I mean by programming with others. :) There is no one authority in the internet. We got that with Linux, OpenBSD, Python, and Ruby and people cry so much about those "dictators"
How can programming with others be the reason, if the OP is saying they find programming for the web with others is much harder than applications development with others?
You cannot assume that the others with web programming is the same others with application programming. The result of one doesn't have to match the other.
Okay, but then how can an observer uninformed on the composition and dynamics of either group conclude that's the real reason it sucks? Unless they're slandering web developers but didn't make that clear?
My feelings are that they were speaking badly of web devs.
Web programming nowadays is so good that it reminds me of the development speed of good old Foxpro.
The difference between then and now is that the end result now is 'distributed'.
The difference between then and now is that the end result now is 'distributed'.
Sorry, one cannot drive the frontend with 100% javascript without html. If you want it to be pretty then you'll need css.
I suppose you can dump everything to a text file.
I suppose you can dump everything to a text file.
it was a nightmare (because of the browser support), but it was a nightmare with a hope that it will get fixed (browsers will get better, there will be simple thin abstraction libraries added, etc).
> laravel but not not enough php
I haven't used those much, just glanced over a system written in them. But that sounds bizarre: I thought the whole point of PHP was to be bland and mainstream. If you know how to program at all, then what is there to learn about it?
I haven't used those much, just glanced over a system written in them. But that sounds bizarre: I thought the whole point of PHP was to be bland and mainstream. If you know how to program at all, then what is there to learn about it?
You'd be amazed what people that barely know any programming can do with laravel. It's scary actually.
I didn't mean that as a criticism. These are all good choices for the role that PHP was intended to play, being the language that everyone writes 10 lines of for their personal website.
Java had another big problem. It couldn't interact with DOM properly.
I mean, it could. But it was terribly hackish and anyways involved Javascript.
So you had one of two options:
1. Write an HTML webpage or
2. Write an empty webpage with a large Java applet in the center, which would be function as a "virtual terminal".
Both are ugly. That's why Sun created Java Web Start (IIRC), for complicated Java applications which could be loaded from the Internet.
Perhaps Google Docs could have done something like that, but I like the current UI more than the "potential Java Google Docs". The only thing Google Docs now can't do is Cntrl-S or something like that.
Also, don't forget the real reason (existing) Java Applets died - security.
I mean, it could. But it was terribly hackish and anyways involved Javascript.
So you had one of two options:
1. Write an HTML webpage or
2. Write an empty webpage with a large Java applet in the center, which would be function as a "virtual terminal".
Both are ugly. That's why Sun created Java Web Start (IIRC), for complicated Java applications which could be loaded from the Internet.
Perhaps Google Docs could have done something like that, but I like the current UI more than the "potential Java Google Docs". The only thing Google Docs now can't do is Cntrl-S or something like that.
Also, don't forget the real reason (existing) Java Applets died - security.
Web start has to be one of the best web technologies that almost no one ever heard of. It had most of the benefits of the web for LOB apps, and most consumer apps are probably better off not being web based in the first place.
Right, that too. For example, the amount of work that every serious web app puts into implementing some kind of hierarchical system for storing, naming and accessing objects and then allowing users to share them with each other is astonishing. If only there was a way to have the operating system provide some kind of similar abstraction to the users!
Sure, as said in other threads here -- large companies full of brilliant people can build good RIAs. Small companies full of OK people are suffering.
Java Applets security could have been solved. I'm not even sure what problem you are referring to exactly. With todays web we get insanity of XSSs, CSRF and who knows what else. The only reason these are not killing modern web development is because this hydra has too many heads.
>XSSs, CSRF
Java had drive-by malware downloads galore. Unfortunately, Javascript isn't immune from this, probably for the same reason: to increase performance requirements, they both JIT code, which allows potential buffer overflows, etc.
Java had drive-by malware downloads galore. Unfortunately, Javascript isn't immune from this, probably for the same reason: to increase performance requirements, they both JIT code, which allows potential buffer overflows, etc.
This doesn't sound like the full explanation about the security problems of Java applets. It sounds more like a JIT bug. One can fix the JIT to check for out of bounds errors.
What's the real reason Java applets were insecure?
What's the real reason Java applets were insecure?
No, the security came much later, by then the ship was already abandoned. Also, in many ways, the security of Java Applets was actually better than ActionScript. For example, it could actually contain security contexts within one Applet. In ActionScript, every line of code had access to everything, which is a huge engineering flaw. Exception to this are web workers, but their usability is very low.
Java could have been made to have good DOM bindings, I don't remember anyone asking for them.
Sun wanted Netscape to put Java in the browser, but Netscape was already planning on making their own scripting language. Had Sun convinced Netscape otherwise, Java would have had good DOM bindings.
Or it would have turned into ActiveX. Great on Windows, not so great (if extant) on anything else.
If anything, Flash was multi-platform. You got the same flash on Linux, Mac and Windows.
"Microsoft Java" would be anything but.
If anything, Flash was multi-platform. You got the same flash on Linux, Mac and Windows.
"Microsoft Java" would be anything but.
Sure, that's possible, but not necessary. Devs might have been smart enough to stay away from extensions. Microsoft might have been smart enough to not push it too hard. Your example of ActiveX actual supports that -- ActiveX never became super widespread, remaining a niche thing. Also keep in mind that this was only few years before OS X was released bringing the 2nd consumer desktop OS back onto the market.
Microsoft then had a near complete monopoly on anything computers.
If you remember how Mozilla had to include all the IE6 mistakes all web programmers assumed were standard?
And yes, back then definitely Microsoft was in EEE mode. They would do anything they possibly could do to keep the internet Windows only
If you remember how Mozilla had to include all the IE6 mistakes all web programmers assumed were standard?
And yes, back then definitely Microsoft was in EEE mode. They would do anything they possibly could do to keep the internet Windows only
They settled in 2001. OS X was released same year, signaling the beginning of the end of that monopoly.
OSX had little market share.
I mean, it still has a relatively small market.
If you can save a week's work and make your site work on 97% of computers, or spend another week to get it to 99%, what would you do?
And in truth, Mozilla/Opera/other HTML browsers had around 10 percent of marketshare even during the heydays of IE6's reign, and yet plenty of websites only worked on IE6.
Would programmers care about those five percent of Mac users?
I mean, it still has a relatively small market.
If you can save a week's work and make your site work on 97% of computers, or spend another week to get it to 99%, what would you do?
And in truth, Mozilla/Opera/other HTML browsers had around 10 percent of marketshare even during the heydays of IE6's reign, and yet plenty of websites only worked on IE6.
Would programmers care about those five percent of Mac users?
[deleted]
> Yes, even web programming was better 10 years ago.
I've been doing this for over 10 years and no, it was way, way worse.
I've been doing this for over 10 years and no, it was way, way worse.
> Back end and front end are written in the same language with strong typing and all that.
Exactly why I love GWT, even though it seems that it's not popular anymore.
It gets the job done, refactoring is not an error-prone and painful experience and it's fast because it's transpiled to javascript.
Exactly why I love GWT, even though it seems that it's not popular anymore.
It gets the job done, refactoring is not an error-prone and painful experience and it's fast because it's transpiled to javascript.
GWT + GXT, vaadin, or smart client are examples of this.
> Java, being a significantly superior language to ActionScript
ActionScript 3 was all right. A bit too listener-heavy but a mature, reliable, comprehensible language, and arguably lighter and more approachable than Java. Had Microsoft (among others) not nobbled it back in 2008, we might be using it as the next generation of JavaScript (ES4) by now.
ActionScript 3 was all right. A bit too listener-heavy but a mature, reliable, comprehensible language, and arguably lighter and more approachable than Java. Had Microsoft (among others) not nobbled it back in 2008, we might be using it as the next generation of JavaScript (ES4) by now.
ActionScript was all right, I don't disagree. Especially compared to JavaScript. But i think it would have been nice to have the same language on FE and BE.
> Yes, even web programming was better 10 years ago
You are not serious :) Don't you remember IE5/6? Loads if inconsistent implementations and flash that supposed to fix all pain?
You are not serious :) Don't you remember IE5/6? Loads if inconsistent implementations and flash that supposed to fix all pain?
I'm saying there was hope. I remember 2005. IE was getting better. Chrome/Firefox/Opera were close enough, once I got one of them working i barely had to do anything. So it was essentially targeting 2 platforms (IE and non-IE) and hoping IE would get fixed. Today that problem is largely solved, but we have created an unmanageable lasagna of complexity in the process.
Supporting IE browsers were a nightmare....
Web programming has never been wholly controlled by a platform owner. I think that's the main difference from any traditional environment that might come to mind; Unix has its traditions, so do Windows and Mac. This is even the case for mobile. In the years when IE was the only browser anyone used, one could also hope to come to grips with its buggy CSS implementation, but that is past too, and in the meantime the backend was still churning from Java and the classic LAMP stack towards Rails and Python.
This is the end result of uncoordinated, path dependent "bazaar" dynamics where the core technologies are open, yet keep accumulating cruft, and are subject to regular proxy wars between large entities. The solutions today are better in that they are easier along certain axes - you can make a cookie-cutter landing page out of the box with Bootstrap, or add some interactive data viz by employing D3. For any random one-off there is an npm package that depends on 50 other packages. They mostly aren't there to help you architect your own thing in a self-consistent way, though - that's too much of a "vitamin" and not enough of a "bandaid" to be marketable.
This is the end result of uncoordinated, path dependent "bazaar" dynamics where the core technologies are open, yet keep accumulating cruft, and are subject to regular proxy wars between large entities. The solutions today are better in that they are easier along certain axes - you can make a cookie-cutter landing page out of the box with Bootstrap, or add some interactive data viz by employing D3. For any random one-off there is an npm package that depends on 50 other packages. They mostly aren't there to help you architect your own thing in a self-consistent way, though - that's too much of a "vitamin" and not enough of a "bandaid" to be marketable.
I'm not sure if the bazaar really applies. In the bazaar you have a range of options and can pick and choose what suits you, but on the web we are seemingly stuck on a few base tools (html js, css) that have so much momentum that the will never go away. You don't get a restriction like that on the server or desktop side.
That's just the platform. If you look around the operating-system bazaar, you still have some basic notions that are shared among all of them (e.g. all their VFS look basically the same). That's the role fulfilled by HTML/JS/CSS: a hardware abstraction layer, if you will.
My theory is that everything is a mess, once you get close enough to notice. Every profession that appears as if its practitioners know what they're doing really is a shocking hodge-podge of temporary solutions, strung together by proverbial duct tape. From doctors to flight engineers to anything else that you thought was running like a smooth machine. Programming is no different.
This was my experience in corporate law. Long (and critically important) documents were cobbled together by small teams of brutally sleep deprived kids. The end result was a tangled webs of documents, defined terms, and clauses that all theoretically referenced one another properly without violating any laws or producing unintended results.
It was like trying to write code without being able to compile or run it. The only way it "worked" was a massive framework of tricks and hacks and legal duct tape, and even then errors were common.
It was like trying to write code without being able to compile or run it. The only way it "worked" was a massive framework of tricks and hacks and legal duct tape, and even then errors were common.
Agreed. I was a civil engineer (specializing in water resources) before I became a full-time software developer. The science of hydrology/hydraulics is largely a messy pile of educated guesses, statistical relationships based on embarrassingly small datasets, and highly generalized models.
The more of engineering I see in general, the more surprised and impressed I am that anything works at all.
One of my friends, who is a new developer, and I took out a new Tesla for a spin and the whole time he was saying his time as a programmer makes him trust Tesla's self-driving software. My reaction was closer to "I've worked for some of the Big 4 software companies and my time there makes me not trust any software."
Yeah, inferior standards that are ineradicable due to early adoption are hardly unique to the Web or even computers.
As an aeronautical engineer (structural dynamics, aeroelasticity, stress analysis, etc.), I can definitely validate this claim--at least partially.
At the lowest level, things are definitely a horrific mosaic of "temporary solutions, strung together by proverbial duct tape". The good news is that there's a good bit of oversight. Even if my analysis on a flight-critical component is a complete and total abuse of physics (either due to my own incompetence, rushed schedule, or limited budget), it still has to go through my manager, an internal review (with many other experience engineers), validation testing (limit load testing, vibration characterization, etc.), and a third party review by a regulatory agency ALL before first flight. Does it take a while? Absolutely, because the consequences of an incorrect air-frame structural analysis can be dire. Is it perfect? Not even close, but it's pretty good. When field issues DO arise, we have a failure investigation team that works around the clock to address the issue. And this is for unmanned aircraft--in commercial it's even more rigorous. Spacecraft? An even higher level or rigor.
When aeronautical / aerospace engineers DO screw up, you definitely hear about it--usually because lives are lost. A single failure can lead to a company going under and being purchased by a competitor as seen in the consolidation of aerospace companies[0]. In most web programming applications, mistakes are much more forgiving. At worst, a bad commit makes it to production code which usually only manifests as lost revenue (either through security breach, downtime, loss of consumer confidence, etc.). I have to imagine that production code on a medical device (say a pacemaker) is more heavily scrutinized than JavaScript includes in a header file, but I could be wrong. Web is a VERY fast industry because it can afford to be--the reward for using new, bleeding edge technology, is often worth the risk because at the end of the day it's all financial.
I do think "everything is [sort of] a mess, once you get close enough to notice". Some other articles on the phenomenon: 1. Everything is Broken [1]: Since programming technology moves so fast, everything is literally strung together because "if it works, it's good enough".
2. Programming Sucks [2]: Everyone has an opinion and since programming is literally working with pure thought, it's objectively difficult to get people to agree.
3. The Expert [3]: Communication between managers and engineers is (and always has been) terrible--having people who can bridge this gap can really make or break an organization.
4. Apathy [4]: At the end of the day, most people are just collecting their pay check and don't care that much. 5. Bullshit Jobs [5]: Most jobs are not really mission critical.
[0] https://theblogbyjavier.files.wordpress.com/2012/09/3874434....
[1] https://medium.com/message/everything-is-broken-81e5f33a24e1...
[2] https://www.stilldrinking.org/programming-sucks
[3] https://www.youtube.com/watch?v=BKorP55Aqvg
[4] http://www.hanselman.com/blog/EverythingsBrokenAndNobodysUps...
[5] http://strikemag.org/bullshit-jobs/
At the lowest level, things are definitely a horrific mosaic of "temporary solutions, strung together by proverbial duct tape". The good news is that there's a good bit of oversight. Even if my analysis on a flight-critical component is a complete and total abuse of physics (either due to my own incompetence, rushed schedule, or limited budget), it still has to go through my manager, an internal review (with many other experience engineers), validation testing (limit load testing, vibration characterization, etc.), and a third party review by a regulatory agency ALL before first flight. Does it take a while? Absolutely, because the consequences of an incorrect air-frame structural analysis can be dire. Is it perfect? Not even close, but it's pretty good. When field issues DO arise, we have a failure investigation team that works around the clock to address the issue. And this is for unmanned aircraft--in commercial it's even more rigorous. Spacecraft? An even higher level or rigor.
When aeronautical / aerospace engineers DO screw up, you definitely hear about it--usually because lives are lost. A single failure can lead to a company going under and being purchased by a competitor as seen in the consolidation of aerospace companies[0]. In most web programming applications, mistakes are much more forgiving. At worst, a bad commit makes it to production code which usually only manifests as lost revenue (either through security breach, downtime, loss of consumer confidence, etc.). I have to imagine that production code on a medical device (say a pacemaker) is more heavily scrutinized than JavaScript includes in a header file, but I could be wrong. Web is a VERY fast industry because it can afford to be--the reward for using new, bleeding edge technology, is often worth the risk because at the end of the day it's all financial.
I do think "everything is [sort of] a mess, once you get close enough to notice". Some other articles on the phenomenon: 1. Everything is Broken [1]: Since programming technology moves so fast, everything is literally strung together because "if it works, it's good enough".
2. Programming Sucks [2]: Everyone has an opinion and since programming is literally working with pure thought, it's objectively difficult to get people to agree.
3. The Expert [3]: Communication between managers and engineers is (and always has been) terrible--having people who can bridge this gap can really make or break an organization.
4. Apathy [4]: At the end of the day, most people are just collecting their pay check and don't care that much. 5. Bullshit Jobs [5]: Most jobs are not really mission critical.
[0] https://theblogbyjavier.files.wordpress.com/2012/09/3874434....
[1] https://medium.com/message/everything-is-broken-81e5f33a24e1...
[2] https://www.stilldrinking.org/programming-sucks
[3] https://www.youtube.com/watch?v=BKorP55Aqvg
[4] http://www.hanselman.com/blog/EverythingsBrokenAndNobodysUps...
[5] http://strikemag.org/bullshit-jobs/
Honestly, pretty much everything is hacks on hacks. As a kernel hacker, hardware is hacks, firmware is hacks, kernel is hacks, it's turtles all the way down. The fact that anything works at all is a miracle. Some systems are better than others, but everything has some duct tape somewhere.
Designs and algorithms are abstract, the implementation is never as nice. We as engineers have to make the best of what we have, and to prevent making the situation worse to the best of our ability.
Designs and algorithms are abstract, the implementation is never as nice. We as engineers have to make the best of what we have, and to prevent making the situation worse to the best of our ability.
Could you go more into why hardware is hacks?
I've definitely encountered hardware peripherals that are totally broken and had to be fixed in firmware.
I loled
Technical:
* Multiple browsers that respond to the same code slightly differently.
* Multiple platforms that all need to be supported.
* Countless different screen sizes to consider.
* Standards that aren't supported across browsers and platforms (and different versions of each in use)
* Hundreds of undifferentiated web frameworks that all claim to do the same basic task better than each other.
* Thousands of ways to host, distribute, and scale your application.
* Millions of ways to monitor service availability.
* Billions of ways to create APIs for your service.
Professional:
* Too many technologies and skills needed to do the job.
* Design skills required if you want to create anything significant by yourself.
* The average web developer is practically an encyclopedia of technology yet full stack developers are still undervalued, low-paid, and mostly replaceable.
tl; dr: It takes a very special kind of person who doesn't immediately develop serious neurosis working as a web developer today.
* Multiple browsers that respond to the same code slightly differently.
* Multiple platforms that all need to be supported.
* Countless different screen sizes to consider.
* Standards that aren't supported across browsers and platforms (and different versions of each in use)
* Hundreds of undifferentiated web frameworks that all claim to do the same basic task better than each other.
* Thousands of ways to host, distribute, and scale your application.
* Millions of ways to monitor service availability.
* Billions of ways to create APIs for your service.
Professional:
* Too many technologies and skills needed to do the job.
* Design skills required if you want to create anything significant by yourself.
* The average web developer is practically an encyclopedia of technology yet full stack developers are still undervalued, low-paid, and mostly replaceable.
tl; dr: It takes a very special kind of person who doesn't immediately develop serious neurosis working as a web developer today.
"Multiple browsers that respond to the same code slightly differently."
Web standards are at a peak level. It's never been better.
I blame the overuse of SPAs. They are far too prevalent to the point that they are becoming the default over static web-pages.
Web standards are at a peak level. It's never been better.
I blame the overuse of SPAs. They are far too prevalent to the point that they are becoming the default over static web-pages.
What is your source for full stack devs being under paid? Or maybe a better question is what do you consider a low wage for a full stack dev?
I'd say a starting guess for determining low wage for full-stack devs is anything < (backend dev salary + frontend dev salary), using market averages by location. If you're going to have a single person doing the work of two, pay them accordingly. Otherwise, hire two people and lighten the load.
No, it just takes experience and a healthy amount of curiosity. I can handle these types of challenges.
I would say a healthy amount of skepticism about using the latest new shiny tech. Maybe that comes with experience.
Without specific examples on what your frustrations are, my best guess is that you are just overwhelmed.
It was not long ago that I was in a similar situation like you, all these overlapping technologies looked unnecessary and redundant. Just the node ecosystem by itself, felt like a pile of crap that depended on a bigger pile of crap. For a simple application like "hello world" in React, I have to choose between a large number of possible combinations of packages and install and configure god knows how many of them.
But once you take sometime to adjust and familiarize yourself, you discover that each one of them is a little jewel and are the quite opposite of crap or hack you initially thought. At least that's the conclusion I arrived to.
So, my advice is to just take your time to familiarize yourself with as many technologies as you can in every aspect of web development. After the initial shock, you will start appreciating things and you will realize that they are made by excellent engineers and each has its own merits.
It was not long ago that I was in a similar situation like you, all these overlapping technologies looked unnecessary and redundant. Just the node ecosystem by itself, felt like a pile of crap that depended on a bigger pile of crap. For a simple application like "hello world" in React, I have to choose between a large number of possible combinations of packages and install and configure god knows how many of them.
But once you take sometime to adjust and familiarize yourself, you discover that each one of them is a little jewel and are the quite opposite of crap or hack you initially thought. At least that's the conclusion I arrived to.
So, my advice is to just take your time to familiarize yourself with as many technologies as you can in every aspect of web development. After the initial shock, you will start appreciating things and you will realize that they are made by excellent engineers and each has its own merits.
That may be, and some of my frustration may come from being thrown in the deep end in a very large project that uses a lot of different technologies -- it seems that every other page is using a different framework -- it's a lot to learn all at once.
I think the "design notes" section of the HTML5 spec puts it best [1]:
It must be admitted that many aspects of HTML appear at first glance to be nonsensical and inconsistent.
HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been developed over a period of several decades by a wide array of people with different priorities who, in many cases, did not know of each other's existence.
Features have thus arisen from many sources, and have not always been designed in especially consistent ways. Furthermore, because of the unique characteristics of the Web, implementation bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally written in ways that rely on them before they can be fixed.
Long story short, HTML and its satellites have quite a long history behind them, involving trade wars, religious battes and one or two revolutions (or coups, depending on your point of view)
I think the unique thing about the web "stack" is that for a long time it was the only platform usable and accessible by everyone and controlled by no single entity. This means there was a tremendous amount of people, companies and other entities that tried to influence it's design. Because background compatibility is an absolute must, this lead to hacks accymulating and the whole language getting incredibly messy.
From what I know, there has been at least one approach to start with a "clean slate" and design a better framework - XHTML 2 - but it failed due to missing backwards compatibility and a lack of political support.
The organisation currently in charge publishes the "HTML living standard" (formerly known as HTML5) and has given up on most notions of cleanliness (short of declaring it an explicit non-goal) in favor of backwards compatibility and the ability to move fast.
[1] https://html.spec.whatwg.org/multipage/introduction.html#des...
It must be admitted that many aspects of HTML appear at first glance to be nonsensical and inconsistent.
HTML, its supporting DOM APIs, as well as many of its supporting technologies, have been developed over a period of several decades by a wide array of people with different priorities who, in many cases, did not know of each other's existence.
Features have thus arisen from many sources, and have not always been designed in especially consistent ways. Furthermore, because of the unique characteristics of the Web, implementation bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally written in ways that rely on them before they can be fixed.
Long story short, HTML and its satellites have quite a long history behind them, involving trade wars, religious battes and one or two revolutions (or coups, depending on your point of view)
I think the unique thing about the web "stack" is that for a long time it was the only platform usable and accessible by everyone and controlled by no single entity. This means there was a tremendous amount of people, companies and other entities that tried to influence it's design. Because background compatibility is an absolute must, this lead to hacks accymulating and the whole language getting incredibly messy.
From what I know, there has been at least one approach to start with a "clean slate" and design a better framework - XHTML 2 - but it failed due to missing backwards compatibility and a lack of political support.
The organisation currently in charge publishes the "HTML living standard" (formerly known as HTML5) and has given up on most notions of cleanliness (short of declaring it an explicit non-goal) in favor of backwards compatibility and the ability to move fast.
[1] https://html.spec.whatwg.org/multipage/introduction.html#des...
You can't really compare "web development" to "application development". I think it's more fair to compare a single web framework with a single native framework. The web ecosystem of frameworks is much larger, meaning there are far more options, much more to adapt to if changing projects. Switching from a well-written iOS codebase to a well-written Android codebase would be no different then switching to a well-written React codebase.
> I've been doing some web development on a fairly long-lived and large code-base
Perhaps it's just not a well written codebase. It's extremely easy to write bad code for web, where perhaps it's slightly harder to do for native development (although still very easily possible of course). It's also very possible to write good maintainable code for both as well.
> I'm not even talking about the fact that everything has to be stateless
It doesn't have to be stateless. Take a look at React.
> just the fact that it really feels like there's no consistent way to do anything
That's pretty much the same with application development. Perhaps not as much for Android/iOS themselves since there is basically only one option for each of those. Even within those there are many many ways of doing everything. It's up to everyone working on the codebase to keep things sane. That's no different with web development.
> I've been doing some web development on a fairly long-lived and large code-base
Perhaps it's just not a well written codebase. It's extremely easy to write bad code for web, where perhaps it's slightly harder to do for native development (although still very easily possible of course). It's also very possible to write good maintainable code for both as well.
> I'm not even talking about the fact that everything has to be stateless
It doesn't have to be stateless. Take a look at React.
> just the fact that it really feels like there's no consistent way to do anything
That's pretty much the same with application development. Perhaps not as much for Android/iOS themselves since there is basically only one option for each of those. Even within those there are many many ways of doing everything. It's up to everyone working on the codebase to keep things sane. That's no different with web development.
I think it got particularly crazy around the creation of npm/node: https://www.commitstrip.com/en/2016/05/10/a-moment-of-nostal... . This was an enabler for complexity to spiral out of control.
I give it to you: npm is a Gran Bazaar mostly selling crap....but Node is brilliant.
I have been waiting for the dust to settle on the "Node is the worst idea of mankind" vs "Node is brilliant" before taking a look into it.
The amount of breakages I get using my static site/blog generator has my leaning toward worst ever. If that's any indication then anything actually complicated would be breaking all the time.
This doesn't sound like a NodeJS problem.
I'm not sure if it's nodejs or the various npm packages are to blame, but a problem with the ecosystem node lives in is a node problem.
While you're waiting, there's always Golang...
With respect, at least part of your frustration comes from the "curse of the installed base."
Long-lived software with real users in any language running on any platform becomes complex, and picks up strange-looking appendages. Sometimes those appendages are nasty hacks, and sometimes they are well-built. But they are, in most cases, necessary to the proper functioning of the software, and responsible for its success with its users.
That's true of long-lived human work product in any discipline. Look at a municipal utility map sometime, and then consider that it is probably at least three decades out of date. That's why utilities send out "dig safe" guys to construction sites. That's why things go wrong in utility work after longtime engineers retire or die.
That being said, the capabilities in web browsers are definitely the utility company equivalent of of a pickup truck full of random bolts, pipes, wires, a shovel, a ladder, and a jackhammer. You can do many things badly with a web browser, and our ways of doing them badly have evolved over the past couple of decades.
I believe your frustration with aging web software is, in fact, a sign that web software has become generally useful to the population.
Long-lived software with real users in any language running on any platform becomes complex, and picks up strange-looking appendages. Sometimes those appendages are nasty hacks, and sometimes they are well-built. But they are, in most cases, necessary to the proper functioning of the software, and responsible for its success with its users.
That's true of long-lived human work product in any discipline. Look at a municipal utility map sometime, and then consider that it is probably at least three decades out of date. That's why utilities send out "dig safe" guys to construction sites. That's why things go wrong in utility work after longtime engineers retire or die.
That being said, the capabilities in web browsers are definitely the utility company equivalent of of a pickup truck full of random bolts, pipes, wires, a shovel, a ladder, and a jackhammer. You can do many things badly with a web browser, and our ways of doing them badly have evolved over the past couple of decades.
I believe your frustration with aging web software is, in fact, a sign that web software has become generally useful to the population.
It comes back to that wonderful quote by Bjarne Stroustrup:
"There are only two kinds of languages: the ones people complain about and the ones nobody uses"
"There are only two kinds of languages: the ones people complain about and the ones nobody uses"
It's apropos that the creator of C++ would say something like that. I wonder of Alan Kay, John McCarthy or Guido van Rossum would agree.
Joel Spolsky (FogBugz, Stack Overflow, Trello) wrote this article half a generation ago. It's about not giving in to the temptation to start from scratch when your software is ugly. http://www.joelonsoftware.com/articles/fog0000000069.html
Ironically Firefox was produced as a result of the code created from the Netscape rewrite he criticised.
Why is that "ironic?" I don't see how it disproves his point.
Firefox was a significant improvement over the status quo in browsers when it was released.
Who's to say that Netscape wouldn't have been just as good, or even better, if they'd devoted all that time to working on it instead?
Your comment ignores my introductory paragraph. I have many years of experience working on many different mature code-bases, including (and especially) C++. I know the pain of legacy code quite well, but web seems to be a whole other ball of wax.
"
In Richard Feynman’s popular book “Surely You’re Joking, Mr. Feynman!” he tells how during his college years he “often liked to play tricks on people”. Most of these tricks were designed to show how dumb people are. For example, in a mechanical drawing class at MIT where the students were taught to use a drawing instrument called a French curve (a curly piece of plastic for drawing smooth curves), Feynman informed the other students that “the French curve is made so that at the lowest point on each curve, no matter how you turn it, the tangent is horizontal”. He reports that the other students in the class were excited by this discovery, and began holding up their French curves and turning them in various ways, trying to verify that the curve was always horizontal at the lowest point. Feynman found this funny, because they had already taken calculus and supposedly learned that the derivative of the minimum of any curve is zero. (Of course, it’s also intuitively obvious: If a curve at a given point is not flat, the point is obviously not the minimum.) Feynman says “I don’t know what’s the matter with people: they don’t learn by understanding; they learn by some other way – by rote or something. Their knowledge is so fragile!”
www.mathpages.com/home/kmath687/kmath687.htm
"Easy to begin, hard to master" languages/frameworks let you go very far in spite of your knowledge fragility. Some interesting topics to reduce this fragility are data structures, design patterns, software and hardware architecture and, distributed computing.
If I had a penny for every JR. Dev that thinks they can get around the CAP theorem...
"Easy to begin, hard to master" languages/frameworks let you go very far in spite of your knowledge fragility. Some interesting topics to reduce this fragility are data structures, design patterns, software and hardware architecture and, distributed computing.
If I had a penny for every JR. Dev that thinks they can get around the CAP theorem...
Somehow I feel like this comment is meant to be directed toward me (OP), but am struggling to see how it applies to what I was asking. In fact, I specifically asked for resources to assist me in orienting my mind to the web development way of doing things.
Perhaps I've misunderstood and you're actually directing the comment at the hodge-podge of web frameworks that don't seem to follow the principles of design that other languages do?
Perhaps I've misunderstood and you're actually directing the comment at the hodge-podge of web frameworks that don't seem to follow the principles of design that other languages do?
The main point I was trying to get across is that most software is indeed Hacky, not because Computer Science is terrible, but because the people who made it don't have a solid understanding of many fundamentals. They've taught themselves to "program in 21 days" and later have a hard time understanding why things break.
Peter Norvig said it better than I can, becoming a great programmer takes 10+ years. http://norvig.com/21-days.html
Data structures, design patterns, software & hardware architecture and, distributed computing are subjects that all engineers should be familiar with.
For example, the question whether to use NoSQL or SQL is another way of asking if you need to use a Hash or a Binary Tree.
Bad engineers pick one or the other based on Marketing or White Papers, Great Engineers pick the right one based on understanding how their algorithms will use that data and why there are no silver bullets.
Peter Norvig said it better than I can, becoming a great programmer takes 10+ years. http://norvig.com/21-days.html
Data structures, design patterns, software & hardware architecture and, distributed computing are subjects that all engineers should be familiar with.
For example, the question whether to use NoSQL or SQL is another way of asking if you need to use a Hash or a Binary Tree.
Bad engineers pick one or the other based on Marketing or White Papers, Great Engineers pick the right one based on understanding how their algorithms will use that data and why there are no silver bullets.
“I don’t know what’s the matter with people: they don’t learn by understanding; they learn by some other way – by rote or something. Their knowledge is so fragile!”
This is how we were able to build bridges that didn't fall over before Newton, or even Galileo.
This is how we were able to build bridges that didn't fall over before Newton, or even Galileo.
> I've always found it quite easy to move up and down the stack
This is the most important point that most people overlook: the Web doesn't have a single stack, even though we talk about "full stack developers" and similar. Web is your ultimate distributed system (which is why you have no other option but to make it static); you never develop a single application, but a multitude of applications often (usually, in fact) executing on systems you have next to no control over.
Just think of your quintessential "Web page": a server prepares an HTML page which is then rendered in a browser. First, you have a server, which you rarely control (unless it physically sits on your desk/rack, and even then you're at mercy of your ISP). Second, even assuming the page was served correctly, it then arrives to another system which has OS/browser/display/etc which you have absolutely no control over except for hoping that it adheres to all the standards you have adhered to when developing. Even if there is no client-side code (i.e. Javascript) to be executed, even the simplest HTML (as well as CSS) are instructions that need to be interpreted.
What you call "hacks" are essentially numerous solutions -- some good and others less so -- to inherent problems of distributed computing, working around the peculiarities of the underlying platforms (namely HTTP and TCP/IP) to ensure reliability. Many things that are taken for granted in platform-specific development simply don't exist here; as a reminder, take a look at https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
This is the most important point that most people overlook: the Web doesn't have a single stack, even though we talk about "full stack developers" and similar. Web is your ultimate distributed system (which is why you have no other option but to make it static); you never develop a single application, but a multitude of applications often (usually, in fact) executing on systems you have next to no control over.
Just think of your quintessential "Web page": a server prepares an HTML page which is then rendered in a browser. First, you have a server, which you rarely control (unless it physically sits on your desk/rack, and even then you're at mercy of your ISP). Second, even assuming the page was served correctly, it then arrives to another system which has OS/browser/display/etc which you have absolutely no control over except for hoping that it adheres to all the standards you have adhered to when developing. Even if there is no client-side code (i.e. Javascript) to be executed, even the simplest HTML (as well as CSS) are instructions that need to be interpreted.
What you call "hacks" are essentially numerous solutions -- some good and others less so -- to inherent problems of distributed computing, working around the peculiarities of the underlying platforms (namely HTTP and TCP/IP) to ensure reliability. Many things that are taken for granted in platform-specific development simply don't exist here; as a reminder, take a look at https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
I don't know what are you referring to as hack on top of hacks? There are tons of big open source and closed source web based project that are easy to follow what's going on and everything is well structured. Look at VSCode code base [1] or if you're a Googler look at Google Photos source code.
People look at React and Webpack and all these small little modules that people put together to make something work and think that's all the web is.
Although, I think React, webpack, Redux and all these little hacks are amazing for exploring what's possible in web.
[1] https://github.com/Microsoft/vscode/
People look at React and Webpack and all these small little modules that people put together to make something work and think that's all the web is.
Although, I think React, webpack, Redux and all these little hacks are amazing for exploring what's possible in web.
[1] https://github.com/Microsoft/vscode/
I think the question then becomes: How do I make my code more like VSCode and less like, well, everything else?
I'm not sure the answer is as simple as "use typescript".
I'm not sure the answer is as simple as "use typescript".
Using a meta-language like Typescript (if it's appropriate), and writing a sensible number of tests, employing a consistent code style, documenting what you write, and spending time to actually design your software properly is the answer.
You can write good software in any language and on any platform. Good code is more about your processes than your choice of tools.
You can write good software in any language and on any platform. Good code is more about your processes than your choice of tools.
Thank you! So many people here blaming the tools for bad software when people have been using horrible tools to write good software for decades. I think one major part of why React + Redux are successful is because they sort of force you into a way of thinking that results in a better creative process and ends with better code.
>they sort of force you into a way of thinking that results in a better creative process and ends with better code.
That's the first time I've heard that about React, can you elaborate?
That's the first time I've heard that about React, can you elaborate?
Maybe it's just me, but when I'm working in React it really forces me into a more "modular" way of writing things. Sure, I'll write something as a huge file that's a couple of hundred lines but React makes it _incredibly_ easy to step back and refactor to start pulling things out into modules.
I guess it doesn't quite _force_ you into thinking a certain way, it just encourages writing code in a more modular and reusable way. Refactoring is easy enough to say "yes, I should pull that out into its own component" vs "it would take me a day to pull this out into its own component".
I guess it doesn't quite _force_ you into thinking a certain way, it just encourages writing code in a more modular and reusable way. Refactoring is easy enough to say "yes, I should pull that out into its own component" vs "it would take me a day to pull this out into its own component".
Totally agree with you here. React made me think of the web in a very modular way... I found it very enjoyable to learn!
Have a competent team and team lead, both of which are rare in web programming.
While I hate css, sort of like js and hate html layout, a lot of the problems come from accessibility. In that, it's so accessible anyone can do "web". This means you get non-engineers with no engineering background put into situations where thinking about things from an engineering perspective would really help and might produce actual workable solutions.
Like wtf is this:
https://www.npmjs.com/package/string.prototype.endswith https://www.npmjs.com/package/ensure-string-endswith
str.slice, str.indexOf are standard lib. Adding another layer of complexity for basic string functions that could easily be done natively is very poor form. This kind of stuff happens all the time in the web world. There's a layer of "lack of competency" bootstrapped on top of what I would consider a non-intuitive base.
Like wtf is this:
https://www.npmjs.com/package/string.prototype.endswith https://www.npmjs.com/package/ensure-string-endswith
str.slice, str.indexOf are standard lib. Adding another layer of complexity for basic string functions that could easily be done natively is very poor form. This kind of stuff happens all the time in the web world. There's a layer of "lack of competency" bootstrapped on top of what I would consider a non-intuitive base.
Errm...
- "test".indexOf("st") == "test".length - "st".length
- "test".enddWith("st")
Am I the only one who thinks the second one is WAAAY more readable? And that's a COMMON function. Using the former is bringing complexity UP.
Not to mention, endsWith is part of es2016 I believe. So this package is just a simple polyfill.
- "test".indexOf("st") == "test".length - "st".length
- "test".enddWith("st")
Am I the only one who thinks the second one is WAAAY more readable? And that's a COMMON function. Using the former is bringing complexity UP.
Not to mention, endsWith is part of es2016 I believe. So this package is just a simple polyfill.
> "test".indexOf("st") == "test".length - "st".length
I don't think this is a correct implementation of "endsWith".
"testtest".indexOf("st") =/= "testtest".length - "st".length
I don't think this is a correct implementation of "endsWith".
"testtest".indexOf("st") =/= "testtest".length - "st".length
Good point. Should have been
"test".substr("test".length - "st".length) === "st"
Or is it substring? Might there be an off by one in there? Anyway, this kind of reflexion only proves my point. There's no reason to question what endsWith does, because it's obvious. It's the correct abstraction in many cases.
"test".substr("test".length - "st".length) === "st"
Or is it substring? Might there be an off by one in there? Anyway, this kind of reflexion only proves my point. There's no reason to question what endsWith does, because it's obvious. It's the correct abstraction in many cases.
Negative substr() already does the trick, I don't see the need for endsWith() at all.
'test'.substr(-'st'.length) === 'st'The thing is :
1. You need to know and understand obscure behavior of substr
2. This hides the programmer's true intent. What you want is to know if the string ends with 'st', not that "the 'st'.length last characters of the string is 'st'". Why make it harder on your fellow coworkers to understand what you mean ?
If you only do this once, sure, maybe importing a whole module is overkill. But as you write it over and over again, in separate projects, having the code safely tucked away in a reusable module brings complexity down.
1. You need to know and understand obscure behavior of substr
2. This hides the programmer's true intent. What you want is to know if the string ends with 'st', not that "the 'st'.length last characters of the string is 'st'". Why make it harder on your fellow coworkers to understand what you mean ?
If you only do this once, sure, maybe importing a whole module is overkill. But as you write it over and over again, in separate projects, having the code safely tucked away in a reusable module brings complexity down.
You can even do
'test'.match(/st$/)
- "test".match(/st$/)
I don't understand the problem with those modules. Just because you can do something one way, doesn't mean you shouldn't add an easier and better to understand way. The intention of `string.endsWith('Blah')` is easier to understand then `string.indexOf('Blah') === string.length - 4`. Java String has both `indexOf` and `startsWith`, do you think that is also problematic?
It's added complexity because it's not std lib. Importing an entire module just to accomplish something you could easily do with 1 line of code. I'm not arguing that javascript shouldn't have `startsWith`, just saying there's a large overhead associated for a relatively minor performance increase. Thus going back to the debate about proper engineering. Just my 2 cents, feel free to ignore :)
But it's not "An entire module", it could be as simple as one line.
I know people like to go on about how every module increases complexity by some massive amount, and how you are relying on X number of other developers and systems that can break now, but the NPM/javascript way is the unix philosophy taken to the extreme. Lots of small modules, extremely easy to use and install, that all do one thing and do it well.
There is no overhead to using a small module. It takes seconds to install, in some cases adds literally bytes to the output, and can take care of a lot of hidden complexity like defaulting to using the stdlib version if it exists, and being fully tested (because let's be honest, you aren't going to write 15 tests for a string-ends-with function).
Also, it's not as simple as 1 line of code. Look at the String.prototype.endsWith library. Look at the edge cases it supports, look at the way it does the search to be efficient. your one-liner might seem to work on the surface, but when you use it in a .apply it might blow up, when you try to get it to run on IE8 for some reason nothing works, when you go to run it on a million strings, the whole system bogs down.
There are benefits to using modules where someone has spent the time and effort finding and fixing those edge cases.
I know people like to go on about how every module increases complexity by some massive amount, and how you are relying on X number of other developers and systems that can break now, but the NPM/javascript way is the unix philosophy taken to the extreme. Lots of small modules, extremely easy to use and install, that all do one thing and do it well.
There is no overhead to using a small module. It takes seconds to install, in some cases adds literally bytes to the output, and can take care of a lot of hidden complexity like defaulting to using the stdlib version if it exists, and being fully tested (because let's be honest, you aren't going to write 15 tests for a string-ends-with function).
Also, it's not as simple as 1 line of code. Look at the String.prototype.endsWith library. Look at the edge cases it supports, look at the way it does the search to be efficient. your one-liner might seem to work on the surface, but when you use it in a .apply it might blow up, when you try to get it to run on IE8 for some reason nothing works, when you go to run it on a million strings, the whole system bogs down.
There are benefits to using modules where someone has spent the time and effort finding and fixing those edge cases.
That's hardly true, because many modules have lots of unseen dependencies. For all I know, your tiny module could have refs to 3+ other modules to do its work.
Thus, getting leftpadded.
I reject the idea that the size of the module means it is not complex.
Thus, getting leftpadded.
I reject the idea that the size of the module means it is not complex.
That's easy to check, it not only shows you any dependencies of dependencies (of dependencies) when you install, but it also exists in a package.json which you can easily browse.
For example, the String.prototype.endsWith package referenced above relies on 0 other packages.
Another micro-module I've used, clean-stack[0] is one line, and has 0 dependencies. (it just removes mostly unhelpful node.js stack trace entries). This is great example for me because it's just a regex. But, it's a regex that was just updated 11 hours ago because a new version of node added a new stack trace line that's not exactly helpful, and by updating this package, it will pull in that update, and I need to do nothing besides do a quick sanity check that nothing massively changed, and check that my tests still pass.
Is-reachable on the other hand (a simple module to check if a hostname is reachable), has 6 direct dependencies, with 2 more dependencies of dependencies. Altogether that module adds up to about 300 lines of code (including it's 8 dependencies).
That's not massive, that's not even much at all for a server-side system. And if that module ever goes under, re-making it would be trivial. So there really isn't much of a downside to using it (especially if I vendor my dependencies, which anyone should be doing for a production application)
For example, the String.prototype.endsWith package referenced above relies on 0 other packages.
Another micro-module I've used, clean-stack[0] is one line, and has 0 dependencies. (it just removes mostly unhelpful node.js stack trace entries). This is great example for me because it's just a regex. But, it's a regex that was just updated 11 hours ago because a new version of node added a new stack trace line that's not exactly helpful, and by updating this package, it will pull in that update, and I need to do nothing besides do a quick sanity check that nothing massively changed, and check that my tests still pass.
Is-reachable on the other hand (a simple module to check if a hostname is reachable), has 6 direct dependencies, with 2 more dependencies of dependencies. Altogether that module adds up to about 300 lines of code (including it's 8 dependencies).
That's not massive, that's not even much at all for a server-side system. And if that module ever goes under, re-making it would be trivial. So there really isn't much of a downside to using it (especially if I vendor my dependencies, which anyone should be doing for a production application)
[deleted]
I prefer writing <heading level 1> instead of <h1> :p
String.prototype.endsWith is native [0], it was added as part of ES2015. If you're supporting older platforms, you need to polyfill it.
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
How well supported is ES6 across browsers? Chrome for sure. Not sure about FF or IE.
The support is quite good today, see https://kangax.github.io/compat-table/es6/.
You can transpile to ES5 if you've got compatibility issues. Not really a problem.
Transpiling usually concerns syntax. Babel won't transpile .endsWith to a polyfill for you, hence the existence of that package
Yes, yes, a thousand times yes. I completely agree with you.
John Carmack also agrees with you, though not about the web per se: https://twitter.com/ID_AA_Carmack/status/771749108780523520
This is how I feel too. If I had to put a finger on the root cause, it is because of the speed demanded. E.g., going back to the left-pad problems that happened in the Node ecosystem, I know lots of folks that know how to do that, but when speed comes up and they can just add a package, that's what myself and others are often going to do.
John Carmack also agrees with you, though not about the web per se: https://twitter.com/ID_AA_Carmack/status/771749108780523520
This is how I feel too. If I had to put a finger on the root cause, it is because of the speed demanded. E.g., going back to the left-pad problems that happened in the Node ecosystem, I know lots of folks that know how to do that, but when speed comes up and they can just add a package, that's what myself and others are often going to do.
> Am I missing something?
Probably. Good folks to learn from.
> Is it me resisting change?
Only you can tell, but client side web development is fine, thanks :)
> Is web programming really that bad?
No, it's doing fine, thanks for asking.
> Is it really just that I need a new mental paradigm?
If you really want to take your time working with client side projects, then you need to relax a bit and just learn a bit more and play a bit more with these techs. Some you'll hate, some you'll love. That's it.
I don't really understand why is this hate against web development goes on HN. I'm building web apps for lots of years now and the major obstacles were never really the technology, but money or people.
Building UI-s in the browser with CSS is not a rocket science; a JS app is easily scalable to 100k lines of code; backend wise you need some good team and a sane PM who don't want to immediately scale your app to Death Star level. Projects does get fucked from time to time, but if you picked your stack well, you'll be fine. I admit it takes experience to identify the crap tools, but what profession doesn't?
Probably. Good folks to learn from.
> Is it me resisting change?
Only you can tell, but client side web development is fine, thanks :)
> Is web programming really that bad?
No, it's doing fine, thanks for asking.
> Is it really just that I need a new mental paradigm?
If you really want to take your time working with client side projects, then you need to relax a bit and just learn a bit more and play a bit more with these techs. Some you'll hate, some you'll love. That's it.
I don't really understand why is this hate against web development goes on HN. I'm building web apps for lots of years now and the major obstacles were never really the technology, but money or people.
Building UI-s in the browser with CSS is not a rocket science; a JS app is easily scalable to 100k lines of code; backend wise you need some good team and a sane PM who don't want to immediately scale your app to Death Star level. Projects does get fucked from time to time, but if you picked your stack well, you'll be fine. I admit it takes experience to identify the crap tools, but what profession doesn't?
I don't get it either. Nothing in history has come close to the current web platform. There has never been a language/runtime/framework/system where you could have this much flexibility, that "installs" in literally seconds (from a cold cache, never having been there in the first place), and works on every platform under the sun (not just linux/windows, but mac, android, ios, windows phone, ubuntu phone, my TV, my car!).
I see people in this thread talking about how it takes them 10X longer to develop for the web than it did for a desktop system, and i'm just sitting here confused as for me it was the exact opposite. I remember having to setup a development environment to get a java swing application ready to start working on. I remember the goddamn readme I needed to write to ensure that the next developer working on my GTK+ project had the right environment, the right libraries, the right platform, and the right compiler. I remember having to find some bullshit bindings to a C library for my python project that really half-assed the implementation, but it's all I had because that C library is the "defacto standard" for what it does, so I need to just deal with it.
For me the web has been such a breath of fresh air. A package system that works so effortlessly that I don't need to spend an hour deciding if that package is worth the pain of setting up another virtualenv, I don't need to worry that this library only supports Java 6 while this other one only supports java 7 and I can't have both (even though I only need the Java 7 one on this project). I don't need to worry that the next version of Windows will break GTK and my project won't support that platform and there is nothing I can do about it.
I run `npm install`, and in a few minutes, every developer with node.js installed can compile, run, modify, and deploy my code. And when deployed, every person with a browser on the planet can run it in seconds. It's amazing.
I see people in this thread talking about how it takes them 10X longer to develop for the web than it did for a desktop system, and i'm just sitting here confused as for me it was the exact opposite. I remember having to setup a development environment to get a java swing application ready to start working on. I remember the goddamn readme I needed to write to ensure that the next developer working on my GTK+ project had the right environment, the right libraries, the right platform, and the right compiler. I remember having to find some bullshit bindings to a C library for my python project that really half-assed the implementation, but it's all I had because that C library is the "defacto standard" for what it does, so I need to just deal with it.
For me the web has been such a breath of fresh air. A package system that works so effortlessly that I don't need to spend an hour deciding if that package is worth the pain of setting up another virtualenv, I don't need to worry that this library only supports Java 6 while this other one only supports java 7 and I can't have both (even though I only need the Java 7 one on this project). I don't need to worry that the next version of Windows will break GTK and my project won't support that platform and there is nothing I can do about it.
I run `npm install`, and in a few minutes, every developer with node.js installed can compile, run, modify, and deploy my code. And when deployed, every person with a browser on the planet can run it in seconds. It's amazing.
I think it's when you get beyond the niceties of the delivery system that is the web to making complex apps compared to other environments is where the complaints stem from. Also, the JVM, Flash and Silverlight would have have all been able to provide a similarly nice delivery system across all platforms if they had been the equivalent of the web. But instead, they were used as plugins.
But i'm talking about complex applications. I'm not talking about your average website, but full blown 100k+ loc applications. It's so much nicer than the alternatives that many developers are making desktop-only applications using those technologies. I don't know if that is because of familiarity, or if it's actually a better platform, but I know that when I did the "move" from GTK and swing applications to HTML/CSS/JS based applications, i instantly became almost a magnitude more productive.
And I don't buy that JVM, Flash, Silverlight, or any of the others could have been able to provide something similar (or better) that the web world. The biggest benefits of the web ecosystem currently are NPM and the "runs literally everywhere". The JVM/Java ecosystem is closest in that area, but that story gets really ugly when it comes to cross-platform UIs and startup time. And while they could have created their own system that installs/runs instantly without needing complex permissions, without needing to "install" at all, automatically cleans itself up, and can be accessed from anywhere in the world by a simple string, they didn't. Flash/Silverlight tried, but in the end they ended up just being worse versions of the js world (remember the damn loading bar that every single flash application needed for some reason?)
Like it or not, the web nailed all the right things, and it became pretty much the most used platform over the course of a few years. Not by accident, but because it did something right.
And I don't buy that JVM, Flash, Silverlight, or any of the others could have been able to provide something similar (or better) that the web world. The biggest benefits of the web ecosystem currently are NPM and the "runs literally everywhere". The JVM/Java ecosystem is closest in that area, but that story gets really ugly when it comes to cross-platform UIs and startup time. And while they could have created their own system that installs/runs instantly without needing complex permissions, without needing to "install" at all, automatically cleans itself up, and can be accessed from anywhere in the world by a simple string, they didn't. Flash/Silverlight tried, but in the end they ended up just being worse versions of the js world (remember the damn loading bar that every single flash application needed for some reason?)
Like it or not, the web nailed all the right things, and it became pretty much the most used platform over the course of a few years. Not by accident, but because it did something right.
This guy gets it. Spot on. I just simply don't understand all those people claiming web is a terrible mistake/fluke or whatsoever. It's nonsense. Big companies with money and might tried all over the decades, and failed. Web is there for a very good reason. It's certainly not perfect but it's not that evil as people make it out to be.
Either you unite all the platforms to make them one, which I'd rather not for diversity's sake, or you accept the fact that there has to be something out there that supports all of them, which isn't going to be an easy feat no matter what, and web is already doing quite fine.
By the way, I surely also hate CSS, and JS to an extent, but my experience programming UI in other platforms haven't been exactly pain-free either. The hate might have been a bit overblown. The nature of computer programming in its current form just simply fits badly with UI design. That's the fact.
Either you unite all the platforms to make them one, which I'd rather not for diversity's sake, or you accept the fact that there has to be something out there that supports all of them, which isn't going to be an easy feat no matter what, and web is already doing quite fine.
By the way, I surely also hate CSS, and JS to an extent, but my experience programming UI in other platforms haven't been exactly pain-free either. The hate might have been a bit overblown. The nature of computer programming in its current form just simply fits badly with UI design. That's the fact.
Keep in mind that JS is leverage the browser, which gets installed everywhere, and because of a persistent push to standardize, delivers mostly the same user experience across platforms these days.
My point was that Java, Flash or Silverlight could have done the same if you replace the browser with a similar platform in those ecosystems. JS is getting to leverage the powerful browser platform with native integration, while the others were mere plugins.
Would be very different if the browser was a JVM based platform.
My point was that Java, Flash or Silverlight could have done the same if you replace the browser with a similar platform in those ecosystems. JS is getting to leverage the powerful browser platform with native integration, while the others were mere plugins.
Would be very different if the browser was a JVM based platform.
But they tried, and for the most part failed.
JRE is difficult to manage and maintain, and security wise is a nightmare compared to javascript (would you run random .jar's from any website?) Adobe had multiple attempts at a "browser-like" runtime for flash, none of which got all that far (although the Adobe Air system has done pretty damn well, and is actually still alive and kicking).
It could be any number of reasons why web won over the alternatives, but I just don't think that it won because of a mistake, or a fluke. The web was doing something better than the others, and while I can't exactly pinpoint it (hell, it probably isn't any one thing), it is winning.
And i'm in no way saying it's perfect. There are a ton of things i'd change about it if given the chance. But you can't just act like it's a horrible platform and that we should start over with something better (like many commenters in this thread and across the internet in general are saying).
JRE is difficult to manage and maintain, and security wise is a nightmare compared to javascript (would you run random .jar's from any website?) Adobe had multiple attempts at a "browser-like" runtime for flash, none of which got all that far (although the Adobe Air system has done pretty damn well, and is actually still alive and kicking).
It could be any number of reasons why web won over the alternatives, but I just don't think that it won because of a mistake, or a fluke. The web was doing something better than the others, and while I can't exactly pinpoint it (hell, it probably isn't any one thing), it is winning.
And i'm in no way saying it's perfect. There are a ton of things i'd change about it if given the chance. But you can't just act like it's a horrible platform and that we should start over with something better (like many commenters in this thread and across the internet in general are saying).
I feel the same thing to be honest. As a mostly Backend Java guy I just have a hard time to get my head wrapped around the whole Frontend/SPA thing and the multitude of frameworks, styles, tools and so on; just don't help at all. It feels like everyone is reinventing the wheel constantly.
Right now I try to write a simple react SPA and I use more libraries as if I would have done it in a tomcat webapp with static html pages.
Documentation is relatively scarce or non-existent at all and in the end you end up looking at code on github. Hunting on Stackoverflow and blogs written by people and realize that there are 100+ ways to do the same thing.
Looking at code would be fine, but looking at Javascript it's hard not to see how easy it is to write in different styles, which makes understanding the things harder. Also being in the middle of transitioning to ES6 makes it more complicated. Of course ES6 will be a big leap, but ES5 won't go anywhere anytime soon because of backward compatibility. So you will end up with overlaps and weird code.
Sass definitely helps with css. React is a great way to develop nice SPA sites webapps.
I don't know if the whole Frontend part is going in the right direction, but it will need some time to settle. For now it's more fragmented then the Android platform. And it really feels like we are trying to put a lot of stuff on top of protocols, tools and standards which were never meant for this in the first place. We might end up having such big scripts loaded for a page, that it could have been just a thick client instead of a web page.
We threw away Java Apps, we threw away flash, we are throwing away jsp/jsf, PHP, etc... And now we are recreating the same behavior with Javascript/CSS/HTML5. Soon it will be only Javascript and you literally won't write not a single line HTML. (Well React already does that to be honest.)
So yeah, interesting times. And it's hard to jump on this train whilst it's moving so fast.
Right now I try to write a simple react SPA and I use more libraries as if I would have done it in a tomcat webapp with static html pages.
Documentation is relatively scarce or non-existent at all and in the end you end up looking at code on github. Hunting on Stackoverflow and blogs written by people and realize that there are 100+ ways to do the same thing.
Looking at code would be fine, but looking at Javascript it's hard not to see how easy it is to write in different styles, which makes understanding the things harder. Also being in the middle of transitioning to ES6 makes it more complicated. Of course ES6 will be a big leap, but ES5 won't go anywhere anytime soon because of backward compatibility. So you will end up with overlaps and weird code.
Sass definitely helps with css. React is a great way to develop nice SPA sites webapps.
I don't know if the whole Frontend part is going in the right direction, but it will need some time to settle. For now it's more fragmented then the Android platform. And it really feels like we are trying to put a lot of stuff on top of protocols, tools and standards which were never meant for this in the first place. We might end up having such big scripts loaded for a page, that it could have been just a thick client instead of a web page.
We threw away Java Apps, we threw away flash, we are throwing away jsp/jsf, PHP, etc... And now we are recreating the same behavior with Javascript/CSS/HTML5. Soon it will be only Javascript and you literally won't write not a single line HTML. (Well React already does that to be honest.)
So yeah, interesting times. And it's hard to jump on this train whilst it's moving so fast.
I'm coming from a similar position as you (trying to merge a hodgepodge of Swing, AWT, JSP, and Rails GUIs into a coherent, modular frontend) and running in to the same problems. I built one application with Angular 1, which had good documentation but seemed to be overcomplicated and had too much "magic" going on under the hood for my liking. I'm now trying React; the main React documentation is great but the documentation for supporting libraries is horrible. I have also encountered the problem of every example doing things differently, highly-opinionated tutorials, and (as I mentioned elsewhere) everything seems to be a slightly different alphabet soup of supporting packages. It has been hell for someone who normally tries to find the "best" way to do things.
I'm not sure what you mean by "a new mental paradigm", the web is a complex system you cannot expect it to be completely reducible to a few simple constructs. You generalize the word backend programming as if it's just one thing. There are hundreds of ways to program a backend system, you can choose from .NET to C/C++ and rarely they are hack-free as you suggest that's not even to mention the platforms they run on like for example BSD, Unix is a series of hacks on top of others, there are often 1000s of different ways to do the same thing.
I simply don't buy your point that "backend" environments are somehow more elegant to work in and easier to reason about than the web.
You still have to decide which backend platform you choose and each has its own series of convoluted hacks associated with it.
I simply don't buy your point that "backend" environments are somehow more elegant to work in and easier to reason about than the web.
You still have to decide which backend platform you choose and each has its own series of convoluted hacks associated with it.
Yes.
I got this realization during a study project where I investigated the use of secure cookies (was 2009, it's public [1]). It's just one example, but you can find similar things everywhere.
Sessions in Web applications are realized using cookies, which is not a very good way, because once someone manages to steal your cookie your session management is broken. And there are plenty of ways to do that, because there is no good separation of the session from the rest of the functionality. Because both cookies and sessions weren't in the design of http/html before, they were a later addon that. So was javascript. So were many other things.
The thing you have to realize though: Things work. It's been the most successful technology of the past decades. There is no point in moaning that things would be much nicer if we'd redesign them from scratch, because it isn't going to happen.
[1] https://blog.hboeck.de/archives/681-Study-research-project-a...
I got this realization during a study project where I investigated the use of secure cookies (was 2009, it's public [1]). It's just one example, but you can find similar things everywhere.
Sessions in Web applications are realized using cookies, which is not a very good way, because once someone manages to steal your cookie your session management is broken. And there are plenty of ways to do that, because there is no good separation of the session from the rest of the functionality. Because both cookies and sessions weren't in the design of http/html before, they were a later addon that. So was javascript. So were many other things.
The thing you have to realize though: Things work. It's been the most successful technology of the past decades. There is no point in moaning that things would be much nicer if we'd redesign them from scratch, because it isn't going to happen.
[1] https://blog.hboeck.de/archives/681-Study-research-project-a...
I think the problem boils down to how the different browser vendors has treated web developers throughout the years, not giving them a consistent environment across the different browsers, not recognizing certain bugs so they've lived on and become un-fixable due to backwards compatibility.
Microsoft with their IE has been the biggest culprit in this, luckily they've taken Edge in the right direction and has really stepped up their game these last two years, but now Safari is at a crossroads and may just end up like the old IE if they take the wrong path. If only the large browser vendors could really, really get together and give us web developers a consistent environment without bullshit. Take Apple Safari for example, keeping Service Worker "under consideration" because the features it brings rivals native mobile apps which they make a lot of money from while all other "large" browser vendors has already started implementing the feature, some even ship it already.
Microsoft with their IE has been the biggest culprit in this, luckily they've taken Edge in the right direction and has really stepped up their game these last two years, but now Safari is at a crossroads and may just end up like the old IE if they take the wrong path. If only the large browser vendors could really, really get together and give us web developers a consistent environment without bullshit. Take Apple Safari for example, keeping Service Worker "under consideration" because the features it brings rivals native mobile apps which they make a lot of money from while all other "large" browser vendors has already started implementing the feature, some even ship it already.
Some people have already mentioned GWT. I think this is the best evidence that yes, web programming is extremely hackish. GWT is an entire framework to write web applications in a strongly typed language - it compiles Java down to JavaScript. GWT was made in an era that we're just now escaping: the era of browser quirks.
IMHO, GWT didn't take off because of one reason: Its target demographic, web developers, do not have the same technical training as traditional computer scientists. What I mean by that is courses at places like General Assembly, CodeAcademy, and even KhanAcademy emphasize JavaScript/CSS/HTML paradigm. This triad makes it easy to create very nice looking website in very little time, but there's little focus on code organization, software design, efficiency, etc. It's much more of, "Now we want this box to fade out when we click on this button, let's see how we can write a function that makes this happen."
IMHO, GWT didn't take off because of one reason: Its target demographic, web developers, do not have the same technical training as traditional computer scientists. What I mean by that is courses at places like General Assembly, CodeAcademy, and even KhanAcademy emphasize JavaScript/CSS/HTML paradigm. This triad makes it easy to create very nice looking website in very little time, but there's little focus on code organization, software design, efficiency, etc. It's much more of, "Now we want this box to fade out when we click on this button, let's see how we can write a function that makes this happen."
> Its target demographic, web developers, do not have the same technical training as traditional computer scientists
I think this is the money quote, and the reason why this thread is full of such ill-informed opinions.
I have a degree in CS. I've done systems programming, devops, and mobile before settling on web. Just recently I joined a company of very strong back-end people with a severe dearth of people who have any knowledge or interest about web. The web doesn't have to be that bad -- just for some reason, it's the orphan child """real programmers""" don't work with.
I think this is the money quote, and the reason why this thread is full of such ill-informed opinions.
I have a degree in CS. I've done systems programming, devops, and mobile before settling on web. Just recently I joined a company of very strong back-end people with a severe dearth of people who have any knowledge or interest about web. The web doesn't have to be that bad -- just for some reason, it's the orphan child """real programmers""" don't work with.
As a Real Programmer who started his career right when the web took off, I can tell you why. At first, web apps were CGI scripts, so back-end only. But most of the jobs were in native applications. At some point you play around with interactive web page, and the DOM is a mess, browsers all behave differently and you give it up in frustration. Swing, Qt, Win32, are all not bad, and act quite predictably. Then you see web apps start coming, but they are slow, and you still have that bad experience from earlier. Then you start reading HN and notice that every six months the new thing changes, and you say, "hm, Swing, Qt, Win32 don't need to change all the time, something about this web app stuff smells like Done Wrong," and you avoid it like the plague. And when you talk to your non-profit friends who are setting up an online store, they are all hiring some guy to do it in WordPress, and it takes 7 seconds to load, 50+ JS files, and 30+ CSS files (I kid you not), and you don't even want to talk shop with that kind of developer.
It's funny you say that, because that's exactly why I avoided it for so long.
That reason doesn't explain why it didn't take off within Google.
This frustrates me every day. The CodeAcadamy approach is a good start—it gets people interested and involved very quickly—but it's not enough on its own. Basics of architecture and design absolutely need to be understood to be a good developer. At the very least they should emphasis the importance of software design and being mentored by more senior devs. As it is now, it seems many people leave those academy's thinking that they know everything they need to or that "coding" is actually what software development is all about. It's not. Coding is a tool of implementation. Design is our real job.
It's not as though every working desktop application developer is really familiar with CS concepts either, although I agree they deserve more attention.
There are billions of dollars made annually that depend on the web being a complicated clusterfuck of spaghetti. It's all about tracking and targeted advertising that wouldn't be possible if a random website couldn't indirectly load a script that indirectly loads a script that loads an image that indirectly drops cookies from a thousand different domains based on a hundred things just sniffed from your browser and the current marketing efforts of thousands of companies bidding for impressions or clicks or whatever.
My pet theory is that commercial politicking is at the heart of everything wrong with the web. Apple, Google, Microsoft, and Mozilla basically sabotaging initiative after initiative for decades trying to fuck each other over in the short term and long term. Like why didn't xhtml catch on, why did IE never support xpath, where did flash go, what happened to silverlight, there are hundreds of "how did we get here?" stories. And I imagine for every minor decision that had far reaching repercussions on web development there was a highly strategic debate at each respective company with high level executives weighing in on technical subjects they had no business weighing in on with shit like "if we support this simple protocol we risk losing our control over this other simple protocol". Basically a bunch of cut throat executives playing statecraft with their browsers.
My pet theory is that commercial politicking is at the heart of everything wrong with the web. Apple, Google, Microsoft, and Mozilla basically sabotaging initiative after initiative for decades trying to fuck each other over in the short term and long term. Like why didn't xhtml catch on, why did IE never support xpath, where did flash go, what happened to silverlight, there are hundreds of "how did we get here?" stories. And I imagine for every minor decision that had far reaching repercussions on web development there was a highly strategic debate at each respective company with high level executives weighing in on technical subjects they had no business weighing in on with shit like "if we support this simple protocol we risk losing our control over this other simple protocol". Basically a bunch of cut throat executives playing statecraft with their browsers.
Huzzah. Puppet would be recognized for the degenerate mess it is if it wasn't marketed so well. I know everyone has the best intentions, but brogrammers, tech savvy sales and marketing rejects, were the death-knell of quality at all costs. It was hard enough before, but money has ripped the guts out of a fine institution.
Sometimes I ask myself the question by doing this thought experiment. If we encountered a more advanced sentient species that writes code, would they say "Yeah, we went through that html/css/js phase of development, and in fact all sentient species do so. We got some good mileage out of it, and it was a total hack for a generation (we refer to that time as the lost generation), but it evolved into our current 'System X' for user-facing app development. Due to the Prime Directive, we can't show you what 'System X' entails. You'll just have to evolve there yourselves."
Or, would they say "You guys are bloody idiots. Come back when you shopped at the galactic clue store."
Or, would they say "You guys are bloody idiots. Come back when you shopped at the galactic clue store."
That's too easy. We all know that in the ideal world, platform-independent code would travel through the pipes instead of HTML/JS. That code "plug" into an existing architecture in the client side to provide some service or functionality transparently to the user.
Why don't we have that? mostly because of security concerns. That's why we can't have nice things.
Why don't we have that? mostly because of security concerns. That's why we can't have nice things.
Platform independent code would be no more insecure than the current scenario. In fact I'll claim that it would be more secure due to reduced attack surface area.
This HTML/JS/CSS scenario evolved. It wasn't designed. If you started with a clean slate and designed the front-end, would you have something completely different.
I'll make another claim that I'd be interested in hearing feedback from others. If IBM had allowed CMU to make the Andrew Window Manager FOSS in '88, we never would have gone down the HTML rabbit hole.
This HTML/JS/CSS scenario evolved. It wasn't designed. If you started with a clean slate and designed the front-end, would you have something completely different.
I'll make another claim that I'd be interested in hearing feedback from others. If IBM had allowed CMU to make the Andrew Window Manager FOSS in '88, we never would have gone down the HTML rabbit hole.
Javascript is platform-independent code. If you mean something closer to assembly/machine code, then that's exactly what asm.js/WebAssembly is.
There are a lot of articles out there arguing that the web wasn't designed with modern web apps in mind, and that that's a source of a lot of strife, so you're not alone in this feeling. But there's also a lot of articles that argue that that even though it wasn't designed with this kind of use in mind, that there are ways it can work well.
Out of curiosity, what's your stack look like? Not all stacks (or components of the stacks) are created equal, by a long shot. Some devs love to try out brand new or new-ish frameworks/dbs/etc that haven't got all the kinks worked out yet, simply because it's the new hotness.
Out of curiosity, what's your stack look like? Not all stacks (or components of the stacks) are created equal, by a long shot. Some devs love to try out brand new or new-ish frameworks/dbs/etc that haven't got all the kinks worked out yet, simply because it's the new hotness.
I think you come to the conclusion because necessity is the mother of invention. Web development is often done in a high-pressure environment with great focus put on churning out features. This leads to the hacks-on-hacks mentality because the needs of the day trump any sort of coherent principle emerging from thoughtful work on the codebase.
I resided over a medium sized custom CMS that was going through changes on all levels. I tried my best to keep it pretty. Fact it was made with Python made it easier for me. Due to that I was quick to find aesthetics to guide my coding. One of the "ugly hacks" actually turned out to save some 50 ms of time on each request. That was significant enough for me to go find a deeper principle for it and implement it in a nice, clean way.
Hacks-on-hacks is SNAFU for web development. Just remember to demand time to refactor and clean up once in a while, otherwise you'll end up shoveling shit from one pile to the next and never managing to vacate it.
I resided over a medium sized custom CMS that was going through changes on all levels. I tried my best to keep it pretty. Fact it was made with Python made it easier for me. Due to that I was quick to find aesthetics to guide my coding. One of the "ugly hacks" actually turned out to save some 50 ms of time on each request. That was significant enough for me to go find a deeper principle for it and implement it in a nice, clean way.
Hacks-on-hacks is SNAFU for web development. Just remember to demand time to refactor and clean up once in a while, otherwise you'll end up shoveling shit from one pile to the next and never managing to vacate it.
Isn't everything? With web programming that's very much a feature, not a bug. You could say that Perl's - the first major web back-end programming language - TIMTOWTDI paradigm is a feature of the web itself.
MFC, Swing, Cocoa, Qt all offer more or less consistent experiences but none of those is as flexible as what you get with the web, which also is a feature, not a bug, because with a certain OS you also want a somewhat consistent, vendor-independent UI / UX across applications.
That said, if you aim for consistency, there are widely used frameworks and tools like Bootstrap, Modernizr, jQuery or Angular that can help you in that regard as well.
MFC, Swing, Cocoa, Qt all offer more or less consistent experiences but none of those is as flexible as what you get with the web, which also is a feature, not a bug, because with a certain OS you also want a somewhat consistent, vendor-independent UI / UX across applications.
That said, if you aim for consistency, there are widely used frameworks and tools like Bootstrap, Modernizr, jQuery or Angular that can help you in that regard as well.
Cars, airplanes, ATMs... IMHO for every well defined standard or torque wrench tolerance there's a rule of thumb and little piece of tape somewhere.
I've done front end work for nearly a decade now. You're right and I think frameworks are a big part of the issue.
Looking at how to do something on the web there is a different way to do it in React, Ember, Angular, jQuery UI, Bootstrap, ExtJS, and about 50 more slightly lesser known frameworks. They don't interoperate well at all. Yes it all boils down to HTML / JavaScript in the end so there is always an integration point but try writing a component that integrates well in even 2-3 of frameworks.
Honestly if more people taught solid coding structures and the DOM API (which, yes it's awkward but with the features HTML 5 brought in plus well structured code it's not that bad) you could have a smaller, handful ways of doing something properly and you could even share components far easier.
Granted frameworks are not the only problem. But, in my opinion, they've severely splintered the way the web is developed.
Looking at how to do something on the web there is a different way to do it in React, Ember, Angular, jQuery UI, Bootstrap, ExtJS, and about 50 more slightly lesser known frameworks. They don't interoperate well at all. Yes it all boils down to HTML / JavaScript in the end so there is always an integration point but try writing a component that integrates well in even 2-3 of frameworks.
Honestly if more people taught solid coding structures and the DOM API (which, yes it's awkward but with the features HTML 5 brought in plus well structured code it's not that bad) you could have a smaller, handful ways of doing something properly and you could even share components far easier.
Granted frameworks are not the only problem. But, in my opinion, they've severely splintered the way the web is developed.
I don't know that they're all "horrible" hacks, but yes. We still generally don't know the best way to build a complicated website. We can't even agree on the simple stuff -- for example Angular2 and React, two of the hottest frameworks, pursue wildly different philosophies.
I think it's exciting. It keeps me motivated to learn new things, and really think about the code I'm writing.
I think it's exciting. It keeps me motivated to learn new things, and really think about the code I'm writing.
> We still generally don't know the best way to build a complicated website
We do. The web was supposed to be a content-delivery mechanism not an application-delivery mechanism. The problem is that it was shoehorned into an application-delivery mechanism, and the lines between content and user interface were blurred so much that it delivers neither particularly well any longer.
This quote from Alan Kay sums up my (and OP's) feelings about the web stack:
> The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.
We do. The web was supposed to be a content-delivery mechanism not an application-delivery mechanism. The problem is that it was shoehorned into an application-delivery mechanism, and the lines between content and user interface were blurred so much that it delivers neither particularly well any longer.
This quote from Alan Kay sums up my (and OP's) feelings about the web stack:
> The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs.
What makes you say the web was supposed to be about content-delivery? Gopher was about content-delivery. I don't see how you can make the same claim for http/html.
I'm not saying the web is great or anything, but it's a little funny to me that people on a site for "hackers" are afraid to get their hands a little dirty. Yes, the web was shorted sight (what technology isn't?) but to me the fact that we're able to use it as an application-delivery system is something to awe at not complain about.
I'm not saying the web is great or anything, but it's a little funny to me that people on a site for "hackers" are afraid to get their hands a little dirty. Yes, the web was shorted sight (what technology isn't?) but to me the fact that we're able to use it as an application-delivery system is something to awe at not complain about.
Web development is like the scene from Indiana Jones and the Last Crusade. You get to pick your poison and there are a lot of people who will choose poorly. Doesn't matter how good you are, chances are, on occasion, you'll choose poorly as well.
There's no point trying to read and understand every library and framework that comes out. HN has half a dozen interesting ones I skim over each week because what you need to know is what's out there, what's been done, so when you come across a problem you don't have the tools for, you can come back and choose the tool that best fulfills the requirements you have at that moment.
And those requirements will change from project to project. There's no cure-it-all. Expect to switch frameworks or libraries very often. You probably wont have time to learn all the intricacies of a framework before something else is more suitable for your needs.
It's not impossible or required to write bad code and have bad design, but it's easy to shoot yourself in the foot when you don't know what you're doing. You will see lot of bad design and poor code though, there are a lot of coders who are starting out with web development because it's an easy place to start with.
Sometimes you need just a spoon and sometimes you need a fleet of excavators and the hard part is knowing when to use what.
There's no point trying to read and understand every library and framework that comes out. HN has half a dozen interesting ones I skim over each week because what you need to know is what's out there, what's been done, so when you come across a problem you don't have the tools for, you can come back and choose the tool that best fulfills the requirements you have at that moment.
And those requirements will change from project to project. There's no cure-it-all. Expect to switch frameworks or libraries very often. You probably wont have time to learn all the intricacies of a framework before something else is more suitable for your needs.
It's not impossible or required to write bad code and have bad design, but it's easy to shoot yourself in the foot when you don't know what you're doing. You will see lot of bad design and poor code though, there are a lot of coders who are starting out with web development because it's an easy place to start with.
Sometimes you need just a spoon and sometimes you need a fleet of excavators and the hard part is knowing when to use what.
[deleted]
Yes (simple answer).
but really, its less "hacks on hacks" and more "unneeded abstractions on unneeded abstractions".
The inefficiency of modern web-stacks continues to absolutely astound me.
When people tout the 'efficiency' of language A against the equivalent C as being "less than 2x"...
jeez... that means you're throwing away double the power that you need to. That means you've got double the number of air-conditioners cooling your server-room. double the power bill, etc...
</rant>
but really, its less "hacks on hacks" and more "unneeded abstractions on unneeded abstractions".
The inefficiency of modern web-stacks continues to absolutely astound me.
When people tout the 'efficiency' of language A against the equivalent C as being "less than 2x"...
jeez... that means you're throwing away double the power that you need to. That means you've got double the number of air-conditioners cooling your server-room. double the power bill, etc...
</rant>
...and half the people.
There is some stuff that actually makes logical sense, like CSS Specificity, but yes a lot of it is hacky. I mean, negative margins? Clear? Thirty different lines of browser-specific rendering tweaks?
WebKit is great, but any attempt to reform the competing browser shitshow reminds me of that xkcd comic about competing standards: https://xkcd.com/927/
(former web developer -- get out while you have your sanity)
WebKit is great, but any attempt to reform the competing browser shitshow reminds me of that xkcd comic about competing standards: https://xkcd.com/927/
(former web developer -- get out while you have your sanity)
Rather surprised you didn't mention vertical alignment. I mean, this year marks the 20 year anniversary of CSS. 20 fucking years of not having vertical align!
(before someone says "flexbox", remember it's still in "working draft" stage)
(before someone says "flexbox", remember it's still in "working draft" stage)
Speaking of CSS Specificity, even here things are getting complicated. CSS standard states that there are six origin specificity levels [0]. Certain browser engine removed two of them just two years ago [1].
[0] https://www.w3.org/TR/CSS22/cascade.html#cascading-order (amusingly, they omitted the last and strongest "user agent !important" from the list). [1] https://bugs.chromium.org/p/chromium/issues/detail?id=347016
[0] https://www.w3.org/TR/CSS22/cascade.html#cascading-order (amusingly, they omitted the last and strongest "user agent !important" from the list). [1] https://bugs.chromium.org/p/chromium/issues/detail?id=347016
> a fairly long-lived and large code-base
1. HTML. Don't view the source of websites and web apps to understand HTML. Read a good book or tutorial. HTML Dog is a good one.
2. CSS. Likewise.
3. JavaScript. Definitely don't try to learn JavaScript by viewing source either. Instead, maybe HTML Dog. There's also Douglas Crockford's _JavaScript: The Good Parts_ and David Flanagan's masterpiece, _JavaScript: The Definitive Guide_. I don't know how I would have ever understood JavaScript if I had not taken the months to read Flanagan's book cover to cover.
That takes care of the client side. For the server side, it should come much more easily. Basically you have a database, like I'm sure you're used to. Then you need a web server, like Apache or Nginx, and some kind of glue language like Python or PHP. Many people put a lot of code here. But I like to keep it pretty thin: like the database and the browser just talking to each other. Even so, just running this side of the affair can be a full-time job in itself.
I recommend at some point familiarizing yourself with the HTTP protocol in general: all the headers, request methods, etc. Basically once you can use Telnet to imitate a browser requesting a page, you'll feel more comfortable with how simple it really is.
>Can you recommend any good resources to help me orient my mind to this new way of thinking?
The thing about web frontend development is that it suffered from the browser wars and having to appeal to amateur developers. Amateur developers love "Worse is Better"[1]. Basically sacrifice all consistency in favor of simplicity and getting started quickly. "Worse is Better" makes things simple to the point of making ugly hacks for certain situations that don't fit that extreme focus on simplicity.
The browser wars made everything horribly inconsistent. Microsoft's strategy was to make the most broken non-standard code possible automatically work and everyone had to emulate that.
The most clean frontend development I've worked with was Angular with ScalaJS. Typescript in Angular 2 should be really clean. The underlying web browser stuff will never be cleaned up since it has to be backwards compatible.
[1] https://en.wikipedia.org/wiki/Worse_is_better
Edit: Replaced the JWZ URL with wikipedia. Apparently JWZ has some anti-hacker news redirect code on his site.
The thing about web frontend development is that it suffered from the browser wars and having to appeal to amateur developers. Amateur developers love "Worse is Better"[1]. Basically sacrifice all consistency in favor of simplicity and getting started quickly. "Worse is Better" makes things simple to the point of making ugly hacks for certain situations that don't fit that extreme focus on simplicity.
The browser wars made everything horribly inconsistent. Microsoft's strategy was to make the most broken non-standard code possible automatically work and everyone had to emulate that.
The most clean frontend development I've worked with was Angular with ScalaJS. Typescript in Angular 2 should be really clean. The underlying web browser stuff will never be cleaned up since it has to be backwards compatible.
[1] https://en.wikipedia.org/wiki/Worse_is_better
Edit: Replaced the JWZ URL with wikipedia. Apparently JWZ has some anti-hacker news redirect code on his site.
Angular feels clean enough, but how do you implement internationalisation properly? How do you switch to angular 2 now that angular 1 is obsolete? Same thing with bootstrap (v2 is largely incompatible with v3 which is mostly incompatible with v4)... Backend is okay; frontend really is a clusterfuck, because it seems all built for short-lived, one shot applications. I build professional applications that have to live and evolve for ages, and I'd rather not rewrite the 80000 LOC of code for every brand new shiny incompatible material design fully reactive 3D enabled VR compatible à la mode fashionable trendy JS+CSS framework that'll be obsoleted in 9 months.
At the moment, I really don't know what to do. Looking at the way people build applications nowadays (does somebody NOT use node.js and npm at some point?) with layers upon layers of languages, frameworks, 4 different module management systems, with READMEs that read like "install the dependancies using "gem install A B C; pip install E F G; npm install X Y Z; go install U V W; cargo install P Q R; then proceed with curl https://github/myshit/install.sh | bash" is really tiring.
Ghaaaaa!
At the moment, I really don't know what to do. Looking at the way people build applications nowadays (does somebody NOT use node.js and npm at some point?) with layers upon layers of languages, frameworks, 4 different module management systems, with READMEs that read like "install the dependancies using "gem install A B C; pip install E F G; npm install X Y Z; go install U V W; cargo install P Q R; then proceed with curl https://github/myshit/install.sh | bash" is really tiring.
Ghaaaaa!
I was using node.js for a while and having to deal with the same bugs over and over again. Usually the bug would be passing the wrong type or mistyping a name. I started using Typescript and things got a lot better. Scala.js is great and all, and probably a good choice if you're using Scala on the backend, but Typescript works a bit better because the Javascript it generates is pretty close to the original. If you search the HN archives, people seem pretty happy with it.
The difference is that Scala is a vastly better, designed language. It's not something like Typescript which tries to salvage JavaScript without being able to fix the worst parts.
Scala also has much better, more mature tooling and IDE support.
The build system is also amazing, not the mess cobbled together in JavaScript that is changing every second week.
In addition to that you have stable, existing and mature libraries which work on multiple platforms, achieving _real_ cross platform support. (Not this "if you make JavaScript run outside of the browser..." nonsense.)
Plus, the quality of libraries is so much higher because they aren't written by JS kids with a maximum attention span of 5 minutes.
Scala also has much better, more mature tooling and IDE support.
The build system is also amazing, not the mess cobbled together in JavaScript that is changing every second week.
In addition to that you have stable, existing and mature libraries which work on multiple platforms, achieving _real_ cross platform support. (Not this "if you make JavaScript run outside of the browser..." nonsense.)
Plus, the quality of libraries is so much higher because they aren't written by JS kids with a maximum attention span of 5 minutes.
Ok, this is really weird, why did your link forward me to this NSFW page until i copied the URL manually into the address bar (Again, NOT safe for work): http://imgur.com/32R3qLv
Hovering showed the correct jwz url as well. Is that your or JWZ's doing? JWZ's page has even retained the imgur favicon (chrome, mac).
[deleted]
I think it feels hacky because it is, and it's natural. And by natural I mean this is how spontaneous complex systems evolve. Internet is a result of half of a century of millions of people's contributions for different and often opposing goals and priorities. For other examples of hackiness take a look at other complex natural processes, like multicellular living creatures and ecosystem in general.
But Is hackiness how we humans want to do engineering? I don't think that biological systems are considered ideal models for building bridges or planes. Is software different?
I thought we were talking about what we already have, not what we want to have?
EDIT: Bridges and planes are built by strictly organized companies, with clear (ideally) leadership and plans. Internet has evolved much less centralized, and as a result, in a more natural fashion. No one stopping you from attempting to write a perfect software, but if you want to re-use results of million man-years of development, you'll have to deal with natural processes.
EDIT: Bridges and planes are built by strictly organized companies, with clear (ideally) leadership and plans. Internet has evolved much less centralized, and as a result, in a more natural fashion. No one stopping you from attempting to write a perfect software, but if you want to re-use results of million man-years of development, you'll have to deal with natural processes.
The best analogy I've seen with regard to code health is that software is not built, not engineered, rather it is grown. Depending on the technology of choice, your garden may adopt to different climates, requires different nutrients, and pleases different audience (or achieves different goals).
From that perspective, JavaScript is a garden where once planted, you can't change anything in your garden, and pretty soon it becomes inflexible to build upon old stuff.
The more tools you have, the better of you can get. E.g. TypeScript, and especially Dart help a lot with tooling (and making gardening fun again). What you end up with is isolated components that encapsulate their own code, HTML template and CSS rules. It may be called web component, angular or one of its many competitor, but eventually that is what brings you sanity.
And speaking of sanity: I've found that "the current hype" is almost always broken, half-baked, and lacks proper engineering practices. Go figure why... Use the tool that you enjoy working with and does the job well, and ignore the rest.
From that perspective, JavaScript is a garden where once planted, you can't change anything in your garden, and pretty soon it becomes inflexible to build upon old stuff.
The more tools you have, the better of you can get. E.g. TypeScript, and especially Dart help a lot with tooling (and making gardening fun again). What you end up with is isolated components that encapsulate their own code, HTML template and CSS rules. It may be called web component, angular or one of its many competitor, but eventually that is what brings you sanity.
And speaking of sanity: I've found that "the current hype" is almost always broken, half-baked, and lacks proper engineering practices. Go figure why... Use the tool that you enjoy working with and does the job well, and ignore the rest.
I think one reason is because there are two kinds of web development.
Website dev and web app dev.
I don't think they are mutually exclusive, but website dev is about styling and navigating into documents. It's stateless and the variety of content is unlimited. I don't think there is a "problem" here, it works, has good tools for what it has to do.
On the other hand, there is web app dev, and app dev is messy at present. My guess is that is lacks governance, it's not necessarily a bad thing, but it means things are taking time and must prove themselves to gain traction and become standards.
But yeah, doing something like a calendar input, with really perfect behavior, where you can navigate the calendar with the keyboard if focused, that is accessible, works on all device… is insanely hard and not solved by the platform yet, so everybody try something different.
Also, a lot of people that are more authors than programmers are "hacking" "app like" functionalities into their website, and it can get messy very quickly. No pun intended.
Website dev and web app dev.
I don't think they are mutually exclusive, but website dev is about styling and navigating into documents. It's stateless and the variety of content is unlimited. I don't think there is a "problem" here, it works, has good tools for what it has to do.
On the other hand, there is web app dev, and app dev is messy at present. My guess is that is lacks governance, it's not necessarily a bad thing, but it means things are taking time and must prove themselves to gain traction and become standards.
But yeah, doing something like a calendar input, with really perfect behavior, where you can navigate the calendar with the keyboard if focused, that is accessible, works on all device… is insanely hard and not solved by the platform yet, so everybody try something different.
Also, a lot of people that are more authors than programmers are "hacking" "app like" functionalities into their website, and it can get messy very quickly. No pun intended.
Lately I've been doing some web development on a fairly long-lived and large code-base
Therein lies the problem. I've been doing web development for 22 years and it's only just now getting good. React-like apps (I actually use Mithril) give you a much better understanding of how the app gets into a particular state when compared to jQuery.
Web programming on your typical long-lived large code base really is that bad, but start from scratch with something React-like and you'll have a much better experience.
Therein lies the problem. I've been doing web development for 22 years and it's only just now getting good. React-like apps (I actually use Mithril) give you a much better understanding of how the app gets into a particular state when compared to jQuery.
Web programming on your typical long-lived large code base really is that bad, but start from scratch with something React-like and you'll have a much better experience.
Absolutely. I feel like we're on the cusp of greatness -- between evergreen browsers, flexbox, Typescript, React/Redux, and Webpack my frontend experience has never been better.
It's inconsistent, but it's getting better. The tooling has been drastically improving over the last few years.
There's no "one true way" of doing stuff and the barrier to entry is low, which causes lots of different ecosystems to evolve. The browser vendors are trying to focus more on lower-level features, which the community is expected to use in order to build better abstractions.
I don't think it's worse than other platforms.
It really depends on what you're building. If you're making something that's largely document-focused, it's extremely easy. But as you start building more sophisticated applications, the complexity increases.
There's no "one true way" of doing stuff and the barrier to entry is low, which causes lots of different ecosystems to evolve. The browser vendors are trying to focus more on lower-level features, which the community is expected to use in order to build better abstractions.
I don't think it's worse than other platforms.
It really depends on what you're building. If you're making something that's largely document-focused, it's extremely easy. But as you start building more sophisticated applications, the complexity increases.
Yes it is awful.
How people manage to build applications given the festering pile of rubber bands, glue and fish heads that we call web development platforms these days is beyond me.
There was a time when even I could build a website. Then I stepped away for a few years to do other stuff and came back to witness in complete horror where things are now. Let's be frank, the tooling is abysmal.
I've been taking a look at Polymer, Dart and Flutter recently.
Looking at the goals of those projects I'd say that reading between the lines, even the likes of Google understand that something has to change.
How people manage to build applications given the festering pile of rubber bands, glue and fish heads that we call web development platforms these days is beyond me.
There was a time when even I could build a website. Then I stepped away for a few years to do other stuff and came back to witness in complete horror where things are now. Let's be frank, the tooling is abysmal.
I've been taking a look at Polymer, Dart and Flutter recently.
Looking at the goals of those projects I'd say that reading between the lines, even the likes of Google understand that something has to change.
The internet as a whole is one giant, hacked together system. There's no doubt that, with a magic reset button, we could build an internet that is vastly more secure, efficient and reliable than the current one.
But that's the nature of an emergent, distributed technology like the internet. Once the concept was born we ran with what we had, and once adoption hit a certain point it became impossible to start over again and do it correctly. I see it as an innate challenge that comes with the domain, like EM interference for electrical engineering.
But that's the nature of an emergent, distributed technology like the internet. Once the concept was born we ran with what we had, and once adoption hit a certain point it became impossible to start over again and do it correctly. I see it as an innate challenge that comes with the domain, like EM interference for electrical engineering.
I'm not sure a reset is really necessary. "The internet" is abstracted and modular enough that parts can be swapped out and improved without needing to start over.
Internet Protocol is being upgraded to IPv6 (any decade now), HTTP/2 is replacing the old HTTP 1.x (thanks SPDY!), TLS has replaced SSL, brotli is stepping up for gzip/deflate. Who knows, maybe QUIC[1] will be next.
Even on the programming side we have new languages entering the fray. Javascript has recently gotten huge upgrades, and WebAssembly has a lot of momentum behind it as well.
So on almost all layers we're able to swap in new protocols or technologies and everything still continues to function. It's actually a very robust system when you think about it.
Still, there are a few sore spots. DNS is in need of a redesign in my opinion. It wouldn't be impossible to replace, but not easy either.
A number of concepts in web design (such as "document flow") probably aren't going away either. But newer technologies (canvas, WebGL? who knows) may eventually replace the traditional DOM model.
[1] https://en.wikipedia.org/wiki/QUIC
Internet Protocol is being upgraded to IPv6 (any decade now), HTTP/2 is replacing the old HTTP 1.x (thanks SPDY!), TLS has replaced SSL, brotli is stepping up for gzip/deflate. Who knows, maybe QUIC[1] will be next.
Even on the programming side we have new languages entering the fray. Javascript has recently gotten huge upgrades, and WebAssembly has a lot of momentum behind it as well.
So on almost all layers we're able to swap in new protocols or technologies and everything still continues to function. It's actually a very robust system when you think about it.
Still, there are a few sore spots. DNS is in need of a redesign in my opinion. It wouldn't be impossible to replace, but not easy either.
A number of concepts in web design (such as "document flow") probably aren't going away either. But newer technologies (canvas, WebGL? who knows) may eventually replace the traditional DOM model.
[1] https://en.wikipedia.org/wiki/QUIC
The web isn't the internet. Someone else posted a quote (by Alan Kay?) about how the internet was an example of brilliant design, while the web was an example of amateurish engineering.
Yes. Web programming is a mess. It's layers and layers of half-baked solutions, each patching deficiencies in the previous layer while introducing new deficiencies. It's a convoluted Rune Goldbergian contraption, attempting to make a general application framework out technologies originally designed to display hypertext.
The individual parts make sense once you're familiar with them. Some are even designed by conscientious and competent people. But the feeling that, taken together, it's an ugly hack is inescapable.
The individual parts make sense once you're familiar with them. Some are even designed by conscientious and competent people. But the feeling that, taken together, it's an ugly hack is inescapable.
Damn. If I didn't know better, I'd have thought I'd written this myself while in an Ambien-induced fugue state.
This is exactly my feeling and much my own history. I think the intensity of your pain can be felt most acutely by those who once knew a saner world of software development.
For those who came of age in this era of Javascript hacks, framework of the day, standard of the week, and separate open source tool for every single task an app must perform, I think it is simply normal.
I say this because after several years applying my craft to my own business in the manner of my choosing, I have recently returned to Organized Development Land. When I read the code or a module is explained to me, all I can think is "are you effin' kidding me?" But I look around and everyone else has a straight face.
If you've stayed in the industry during this evolution, you have probably had moments of frustration or confusion wrought by this change, but have now had a full WTF epiphany--likely induced while simply trying to get something done for the hundredth time, that should've been relatively straightforward.
Mainstream software development is no longer about logic, algorithms, creativity, and design. It's about trying to glue together a hodge podge of disparate crap and trying to make it work. And, for the artisans of old, it can feel like soul-crushing assembly-line work.
This is exactly my feeling and much my own history. I think the intensity of your pain can be felt most acutely by those who once knew a saner world of software development.
For those who came of age in this era of Javascript hacks, framework of the day, standard of the week, and separate open source tool for every single task an app must perform, I think it is simply normal.
I say this because after several years applying my craft to my own business in the manner of my choosing, I have recently returned to Organized Development Land. When I read the code or a module is explained to me, all I can think is "are you effin' kidding me?" But I look around and everyone else has a straight face.
If you've stayed in the industry during this evolution, you have probably had moments of frustration or confusion wrought by this change, but have now had a full WTF epiphany--likely induced while simply trying to get something done for the hundredth time, that should've been relatively straightforward.
Mainstream software development is no longer about logic, algorithms, creativity, and design. It's about trying to glue together a hodge podge of disparate crap and trying to make it work. And, for the artisans of old, it can feel like soul-crushing assembly-line work.
Do web developers find ways to create work for themselves?
You allude to it below when you say "zillions of hours".
There is a significant amount of money moving through the "web development industry".
People are getting paid to write things that suck.
The internet actually has made leaps and bounds in terms of what can be delivered over it to the masses.
But the "web" has become a cesspool of redirects, overstuffed headers and pages crammed with beacons, ad server links and ad-related Javascript, accessible through ad-sales-company-sponsored software ("web browsers") to run the ad-related Javascript.
If and when users grow tired of web advertising, the entire system is a risk of a serious correction.
Again, significant and increasingly larger sums of money are moving through the web ad and user data collection cesspool so no one really cares how poor the quality of the "content" becomes.
And you want to learn to orient your mind to this "new way of thinking"?
Maybe you are not resisting change. Maybe you are resisting stupidity. Your time may be better spent focusing on backend development. Today's "backend" may be tomorrow's frontend.
All that "content" can easily be delivered without a single line of Javascript and without using search-engine-ad-sales-company-sponsored software.
You allude to it below when you say "zillions of hours".
There is a significant amount of money moving through the "web development industry".
People are getting paid to write things that suck.
The internet actually has made leaps and bounds in terms of what can be delivered over it to the masses.
But the "web" has become a cesspool of redirects, overstuffed headers and pages crammed with beacons, ad server links and ad-related Javascript, accessible through ad-sales-company-sponsored software ("web browsers") to run the ad-related Javascript.
If and when users grow tired of web advertising, the entire system is a risk of a serious correction.
Again, significant and increasingly larger sums of money are moving through the web ad and user data collection cesspool so no one really cares how poor the quality of the "content" becomes.
And you want to learn to orient your mind to this "new way of thinking"?
Maybe you are not resisting change. Maybe you are resisting stupidity. Your time may be better spent focusing on backend development. Today's "backend" may be tomorrow's frontend.
All that "content" can easily be delivered without a single line of Javascript and without using search-engine-ad-sales-company-sponsored software.
Definitely yes. I'm on the sidelines until things will settle down into something that makes more sense and if it doesn't then I won't be doing any web development.
Software is such a huge field there are a ton of interesting challenges outside of the web and the current mess does absolutely nothing to keep me interested. It's a veritable tower of Babel without a clear sense of direction or longevity.
Software is such a huge field there are a ton of interesting challenges outside of the web and the current mess does absolutely nothing to keep me interested. It's a veritable tower of Babel without a clear sense of direction or longevity.
I think all programming is, but Web programming is _particularly_ that way.
The least bad stack I've ever used is Reagent ( https://github.com/reagent-project/reagent ) - a Clojurescript library for React. Perhaps that's just _adding_ layers of hackery, but I found it made sense.
The least bad stack I've ever used is Reagent ( https://github.com/reagent-project/reagent ) - a Clojurescript library for React. Perhaps that's just _adding_ layers of hackery, but I found it made sense.
I use GWT for anything serious. It's not what the cool kids like, but it feels super-solid compared to the flake that I experience when working with a heap'o JS libs. And debugging it years later is awesome (barring a couple gotchas) because it makes sense.
I've always thought GWT has a crazy learning curve until we did a project in Angular2 on top of ASP.net core, using a customer-selected template that required tons of JS fun, with random CSS class names that have zero obvious semantic benefit so you have to look everything up. Not even Typescript could save the feeling that we were building a house of cards in a strong breeze. Same with Django + JS. Just felt too scripty for me.
I don't like leaky abstractions but honestly the modern web fundamentally forces you to use them for anything vaguely complex. It's not getting easier, it's getting much, much harder. GWT at least gives me a way to trade off complexity for a clunky but solid language, and I get to reuse code on the front and back ends.
I've always thought GWT has a crazy learning curve until we did a project in Angular2 on top of ASP.net core, using a customer-selected template that required tons of JS fun, with random CSS class names that have zero obvious semantic benefit so you have to look everything up. Not even Typescript could save the feeling that we were building a house of cards in a strong breeze. Same with Django + JS. Just felt too scripty for me.
I don't like leaky abstractions but honestly the modern web fundamentally forces you to use them for anything vaguely complex. It's not getting easier, it's getting much, much harder. GWT at least gives me a way to trade off complexity for a clunky but solid language, and I get to reuse code on the front and back ends.
Maybe it has changed since I last used GWT, but I remember GWT compiles taking a very long time, steadily increasing with the size of your app. Has this been fixed? I have some not-so-very-fond memories of 2 minute long compile times.
It has changed a ton. there is now super dev mode (I don't know when you last used it), so it no longer requires that java applet plugin. Also after the first compile, you only need to recompile changes. I agree with others after going to Angular, etc, I continually scratch my head on why GWT is not universally used more.
The web itself as we know it, was born from a bunch of hacks clobbered together by people who thought that the most important part of development was to "ship code". Features like images in browsers, or JavaScript, were designed and implemented in very short amounts of time and then all the cool features were copied by other browsers. With such a foundation, I think we can establish that modern web development indeed is a "hacks on hacks" thing.
A lot of people still believe that software development is all about "shipping code". And since many developers work alone, or in small teams - things like architecture, knowledge of web interfaces/APIs, etc. may not be something the developers are familiar with. Then the project becomes popular, which makes it harder to clean stuff up without breaking code depending on your project.
New developers hearing about companies embracing stuff like "Break stuff - ship code" isn't really helping them focus on quality either.
A lot of people still believe that software development is all about "shipping code". And since many developers work alone, or in small teams - things like architecture, knowledge of web interfaces/APIs, etc. may not be something the developers are familiar with. Then the project becomes popular, which makes it harder to clean stuff up without breaking code depending on your project.
New developers hearing about companies embracing stuff like "Break stuff - ship code" isn't really helping them focus on quality either.
This is why i find it so much fun to do applications on windows with .net you only need to know one language C# or VB.net and then you are set. You can create anything with just this, of course it will only work on windows but i dont mind, it just such a pleasure to only have one toolset and then just focus on the task at hand.
All of human civilization is a 'series of hacks on hacks'.
Like biological evolution before it.
Some parts of web-dev are really chaotic right now, but other parts can be very well-organized, same as server-side code.
For example, you need to compile all of your es6/es7/typescript code to JS (because nobody will write in pure ES5 nowadays), minify and concatenate resulting files - this part is very chaotic. But you need to touch it not so often.
You also need to write unit-tests. Tests itself will take 10% of their configuration code, it's very annoying also.
But when you'll write e2e tests, everything will be much more clean.
Main part, JS code (I recommend TypeScript) can be organized by same rules you use on the server.
Frameworks: Angular 2 is closer to Java enterprise apps (with all good and bad parts of it), React and jQuery are not frameworks and if your codebase is built on jQuery - bad news, it will be mostly spaghetti-code.
For example, you need to compile all of your es6/es7/typescript code to JS (because nobody will write in pure ES5 nowadays), minify and concatenate resulting files - this part is very chaotic. But you need to touch it not so often.
You also need to write unit-tests. Tests itself will take 10% of their configuration code, it's very annoying also.
But when you'll write e2e tests, everything will be much more clean.
Main part, JS code (I recommend TypeScript) can be organized by same rules you use on the server.
Frameworks: Angular 2 is closer to Java enterprise apps (with all good and bad parts of it), React and jQuery are not frameworks and if your codebase is built on jQuery - bad news, it will be mostly spaghetti-code.
Ah, yes. Another round of grumpy 'ol "why can't I pick/control every aspect of my application environment in the languages I love" developer whining. I swear some people just love saying "hacks on top of hacks". It's the new pejorative of our industry, despite the unparalleled success of what it's intended to dismiss. The hacky-ness we're observing is just an evolutionary byproduct of the "power vacuum" of software decentralization and democratization. Yes, it's inefficient and ugly in some places, but it's an amazingly practical way to distribute software. Just remember your perfect system is only perfect for you or your financials. To state otherwise is sophomoric and unscientific.
Strange that you feel that's what I was saying given that my original post said that I've worked in a variety of different languages and environments.
I apologize if I'm being too harsh, but I see these arguments over and over again and I don't think they result in anything beneficial. The thing we should be fighting is not-invented-here syndrome and only re-invent things that which cannot be improved upon for one reason or another.
Yes/no. Code is developing faster than standards update:
HTML - HTML 4.0.1 -> HTML5 (14 years)
CSS3 - in development since 1998
JS - ECMAScript 3 (1999) -> ECMAScript 5 (2009) -> ECMAScript 6 (2015...ish http://kangax.github.io/compat-table/es6/)
I think web development is a lot like Perl. It is flexable enough for anyone to write something simple and quick but creating a large maintainable project takes a lot of discipline.
I use a series of linters, style guides and naming conventions to keep from shooting myself in the foot but still will need to go back and clean up from time to time.
HTML - HTML 4.0.1 -> HTML5 (14 years)
CSS3 - in development since 1998
JS - ECMAScript 3 (1999) -> ECMAScript 5 (2009) -> ECMAScript 6 (2015...ish http://kangax.github.io/compat-table/es6/)
I think web development is a lot like Perl. It is flexable enough for anyone to write something simple and quick but creating a large maintainable project takes a lot of discipline.
I use a series of linters, style guides and naming conventions to keep from shooting myself in the foot but still will need to go back and clean up from time to time.
I felt the exact same thing when I started webdev after 3 years of app dev and a little bit of REST APIs (and backend) using python flask. For me JS, and all frameworks built using JS felt like attempts at revival of something that should have long died. Every new framework gives JS lovers (honestly no offence) a little bit of hope and adds a year or two to its survival. For a long time, I felt JS was a hack on top of a series of hacks!
I've just come to accept it now. The reason you're disliking it is probably because of its extreme hit and trial nature - unlike appdev which is more fluid and consistent.
I've just come to accept it now. The reason you're disliking it is probably because of its extreme hit and trial nature - unlike appdev which is more fluid and consistent.
My take on this is that backend developers have always been at odds with frontend developers in terms of being given larger salaries than frontend while not having to keep up with new UI technologies and simultaneously downplaying the skills of the front end programmers.
So now, when you have to learn about the web platform since you just cannot ignore it anymore, you are feeling pretty overwhelmed, and can't help yourself -- you fall back on what you know, which is to shit on the skills of front-end developers.
I say this as someone who has done front, back, database, ops, on web-based and desktop stacks.
So now, when you have to learn about the web platform since you just cannot ignore it anymore, you are feeling pretty overwhelmed, and can't help yourself -- you fall back on what you know, which is to shit on the skills of front-end developers.
I say this as someone who has done front, back, database, ops, on web-based and desktop stacks.
Did you even read what I said?
"anywhere from UI down to the bare metal"
I've done a lot of frontend work, including iOS, Android, MFC, OpenGL, Qt (with and without QML), etc... My UI work has often been praised, and I've salvaged many failing projects, including fixing completely broken UIs. I'm not sure where you got "not having to keep up with new UI technologies" or "downplaying the skills of front end programmers" from anything I said.
If anything, the frontend developers get a lot of credit for what the backend developers do. I enjoy backend work more, and it is frustrating when a GUI developer spends a few days and slaps a few screens on that update in response to signals that took months to implement, but they get all of the credit for the feature. It goes both ways, you know?
"anywhere from UI down to the bare metal"
I've done a lot of frontend work, including iOS, Android, MFC, OpenGL, Qt (with and without QML), etc... My UI work has often been praised, and I've salvaged many failing projects, including fixing completely broken UIs. I'm not sure where you got "not having to keep up with new UI technologies" or "downplaying the skills of front end programmers" from anything I said.
If anything, the frontend developers get a lot of credit for what the backend developers do. I enjoy backend work more, and it is frustrating when a GUI developer spends a few days and slaps a few screens on that update in response to signals that took months to implement, but they get all of the credit for the feature. It goes both ways, you know?
I'm curious, have you looked at Meteor?
https://wiki.dandascalescu.com/essays/why_meteor
https://wiki.dandascalescu.com/essays/why_meteor
No. I have no control over the software stack for this project, so for now I'm focusing on what they use first.
What you're witnessing is the migration of complexity to the frontend. It's becoming very difficult to find a backend problem that doesn't have a well-defined, generally accepted solution and accompanying FOSS that you would be stupid (or even borderline criminally negligent) to ignore. In fact, full-stack programming in general is boring enough that I welcome anything that stirs the pot a bit. That said, having tried at one time or another PM, management, and sales: programming is the worst monetizable career option, except for all the others.
> That said, having tried at one time or another PM, management, and sales: programming is the worst monetizable career option, except for all the others.
Could you clarify that sentence, please?
Could you clarify that sentence, please?
Just an Easter egg: http://wais.stanford.edu/Democracy/democracy_DemocracyAndChu...
I'm more unnerved by how few maintainers so many critical/core open source projects/libraries have, whether in web or otherwise.
However high our project or company's bus factor gets, it's concerning to realise that the framework or critical library underlying has a bus factor close to one. We can certainly adopt it, but that's folding in a lot of new complexity. o_O
This applies irrespective of the language, incidentally - it's often true in Java/Python/Scala even as in JavaScript/npm, as much as people like to bash on the latter.
However high our project or company's bus factor gets, it's concerning to realise that the framework or critical library underlying has a bus factor close to one. We can certainly adopt it, but that's folding in a lot of new complexity. o_O
This applies irrespective of the language, incidentally - it's often true in Java/Python/Scala even as in JavaScript/npm, as much as people like to bash on the latter.
weird. commenters seem to be either new web devs, or non-web devs at all judging from comments and cries.
web development is as hard as any other development environment. you must know a lot of stuff, hacks ARE NOT mandatory at all and it is not as bad as people tell you.
maybe you just work with terrible base code is the answer?
web development is as hard as any other development environment. you must know a lot of stuff, hacks ARE NOT mandatory at all and it is not as bad as people tell you.
maybe you just work with terrible base code is the answer?
Was it ever anything different?
From the very beginning† -- you know, back to the <img> tag, HTTP 1.0 -- it was always a series of shrewd tradeoffs (a.k.a. "hacks") in favor of what can be put in front of people now instead of what might take another 5-8 years of IETF meetings and mailing lists debates to hash out.
† Referring to "the web" as such; not "the internet", for which the initial design choices, while still hackish in their own way, were arrived at in ways decidedly less brutish and expedient.
From the very beginning† -- you know, back to the <img> tag, HTTP 1.0 -- it was always a series of shrewd tradeoffs (a.k.a. "hacks") in favor of what can be put in front of people now instead of what might take another 5-8 years of IETF meetings and mailing lists debates to hash out.
† Referring to "the web" as such; not "the internet", for which the initial design choices, while still hackish in their own way, were arrived at in ways decidedly less brutish and expedient.
Reading through all these comments, I feel there's one salient question left unanswered: What's the alternative, then, under such a divisive landscape of various OS and standards? Surely it's infeasible for the vast majority to develop native applications for each and every platform out there, for everything we want to do? The current web application solutions are the best people have come up with. If they're indeed so rubbish and we're in a "dark age", then why hasn't an alternative triumphed? It's not like companies with money and might haven't tried over all these decades, they just simply didn't succeed. There is a reason why web application is being so widely adopted, and attributing all to "errors and flukes" makes no sense.
Either you unite all the platforms to make them one, which I'd rather not for diversity's sake, or you accept the fact that there has to be something out there that supports all of them, which isn't going to be an easy feat no matter what.
By the way, I surely also hate CSS, and JS to an extent, but my experience programming UI in other platforms haven't been exactly pain-free either. The hate might have been a bit overblown. The nature of computer programming in its current form just simply fits badly with UI design. That's the fact.
Either you unite all the platforms to make them one, which I'd rather not for diversity's sake, or you accept the fact that there has to be something out there that supports all of them, which isn't going to be an easy feat no matter what.
By the way, I surely also hate CSS, and JS to an extent, but my experience programming UI in other platforms haven't been exactly pain-free either. The hate might have been a bit overblown. The nature of computer programming in its current form just simply fits badly with UI design. That's the fact.
Web developer is not ideal. That is more of a people issue than it is a technology issue.
Whatever our collective gripes about JavaScript, HTML, and CSS, we all know how to use them. We know how to handle cross-browser compatibility and different screen sizes. What we need to do a better job at -- and I think this is the root of the problem you're describing -- is pushing back on businesses wanting to ship features too quickly.
We've all been at places where no one values good work on the client. The C-levels want to get things out the door as quickly as possible. They complain that our work has bugs and we tell them "Well that's what you get for telling me I had 3 days."
Because of this heat, front-end engineers rarely engineer their software. As you put it, they hack it together on top of libraries that have been hacked together by others. The solution is to take the time required to do things correctly. That means testing. That means not shipping features so we have time to refactor and upgrade frameworks. That means paying attention to performance and developing tools for debugging errors in production. If we want web development to get better, these things can't be afterthoughts. They must be considered before we say something is "done" and ship it to production.
Whatever our collective gripes about JavaScript, HTML, and CSS, we all know how to use them. We know how to handle cross-browser compatibility and different screen sizes. What we need to do a better job at -- and I think this is the root of the problem you're describing -- is pushing back on businesses wanting to ship features too quickly.
We've all been at places where no one values good work on the client. The C-levels want to get things out the door as quickly as possible. They complain that our work has bugs and we tell them "Well that's what you get for telling me I had 3 days."
Because of this heat, front-end engineers rarely engineer their software. As you put it, they hack it together on top of libraries that have been hacked together by others. The solution is to take the time required to do things correctly. That means testing. That means not shipping features so we have time to refactor and upgrade frameworks. That means paying attention to performance and developing tools for debugging errors in production. If we want web development to get better, these things can't be afterthoughts. They must be considered before we say something is "done" and ship it to production.
[deleted]
Well, this is so good to read. Thanks for sharing!
One thing I haven't seen mentioned is that while the developer experience is getting more complex, the user experience is getting better and better.
That, in my opinion, makes all the messiness worth it. I'm not saying that there's nothing wrong with the state of web dev now, but it's not without reason that we are here today.
Remember the days of table-based layouts in HTML? shudder
That, in my opinion, makes all the messiness worth it. I'm not saying that there's nothing wrong with the state of web dev now, but it's not without reason that we are here today.
Remember the days of table-based layouts in HTML? shudder
I don't think the complexity of the web caused better UX. I think we just happen to care a lot more about UX in 2016 than we used to in this industry.
Sure, but caring a lot about UX necessitates pushing the envelope when it comes to web tech.
If we were satisfied with our HTML tables, we would never have moved on to jQuery, HTML5/CSS3, React etc.
If we were satisfied with our HTML tables, we would never have moved on to jQuery, HTML5/CSS3, React etc.
I'd love to know too, are there any frameworks that are at least more straightforward than React and Angular? One where you're not passing anonymous functions into functions with all sorts of confusing syntaxes, where you can just express what you want to do without having balance three types of punctuation that require the shift key to type.
Hackish? yeah!, immature? still yes!, sucks? hell no!
I believe the very nature of the web, and the internet itself, is a story of a hack onto another hack.
Think about the first internet communication mediums, protocols, etc. They were all "hackish" solutions. Internet over the telephone landline? why not? change it to the cable TV infrastructure? Sure!
The web itself morphed from text-based solutions (think telnet, gopher) to hyper-text documents and nowadays to full-applications. I acknowledge that this last iteration has been a growing pain indeed, it's a mess and hasn't been consolidated, yet.
Nevertheless I think the reason behind this hackish nature is due to the fact that the web (and the internet as a whole) are always pushing towards an Open Platform, open to everyone to develop and consume, without any corporation behind it.
Compare that kind of ecosystem with the more closed less-hackish ecosystems like Windows/OS X, Android/iOS app development, you can see the difference.
Just my two cents :)
I believe the very nature of the web, and the internet itself, is a story of a hack onto another hack.
Think about the first internet communication mediums, protocols, etc. They were all "hackish" solutions. Internet over the telephone landline? why not? change it to the cable TV infrastructure? Sure!
The web itself morphed from text-based solutions (think telnet, gopher) to hyper-text documents and nowadays to full-applications. I acknowledge that this last iteration has been a growing pain indeed, it's a mess and hasn't been consolidated, yet.
Nevertheless I think the reason behind this hackish nature is due to the fact that the web (and the internet as a whole) are always pushing towards an Open Platform, open to everyone to develop and consume, without any corporation behind it.
Compare that kind of ecosystem with the more closed less-hackish ecosystems like Windows/OS X, Android/iOS app development, you can see the difference.
Just my two cents :)
We're a smart industry, but we're not a wise industry.
We focus on solving tactical problems, ignoring the mountains of technical debt that are created from it, and that it leaves the strategic problem worse. We will do this because we need the solution today, not tomorrow.
We can elevate out of this when we're ready, when we say "enough is enough."
We focus on solving tactical problems, ignoring the mountains of technical debt that are created from it, and that it leaves the strategic problem worse. We will do this because we need the solution today, not tomorrow.
We can elevate out of this when we're ready, when we say "enough is enough."
Yes, the web was meant for building pages, not applications, and that shows. HTML and CSS are horrible at laying out apps (even with flexbox). Which is why using front-end libraries is critical. Have a look at https://webix.com - it's amazing how expressive that widgets library is: 10 lines of code for a master-detail tree+grid layout.
As for the server side and the client-server communication, nothing really beats Meteor - https://wiki.dandascalescu.com/essays/why_meteor. It removes a lot of the paradox of choice, while still letting you swap components out when you're ready (e.g. you can use PostgreSQL instead of Mongo, or React instead of Meteor's default view library).
As for the server side and the client-server communication, nothing really beats Meteor - https://wiki.dandascalescu.com/essays/why_meteor. It removes a lot of the paradox of choice, while still letting you swap components out when you're ready (e.g. you can use PostgreSQL instead of Mongo, or React instead of Meteor's default view library).
Also, while JavaScript has been a hacky language, ES2015 and ES2016 have really upped the game:
* Classes
* Modules
* Block-scoped variables
* Multi-line strings
* Default parameters
* Template Literals
* Arrow functions
* Promises
* Async/await
And JavaScript keeps eating the world:
"In three months from today, 98% of all Walmart.com traffic will be serviced via Node APIs and displayed with React.js according to Alex Grigoryan, Director of Software Engineering at WalMart Labs. Three months after that, SamsClub.com, Walmart’s second biggest property, will be 100% javascript based. Even their iOS and Android experiences will eventually be done in React Native, a javascript technology that’s made to replace native Java/Objective C coding." -- https://medium.com/presence-product-group/javascript-and-nod...
* Classes
* Modules
* Block-scoped variables
* Multi-line strings
* Default parameters
* Template Literals
* Arrow functions
* Promises
* Async/await
And JavaScript keeps eating the world:
"In three months from today, 98% of all Walmart.com traffic will be serviced via Node APIs and displayed with React.js according to Alex Grigoryan, Director of Software Engineering at WalMart Labs. Three months after that, SamsClub.com, Walmart’s second biggest property, will be 100% javascript based. Even their iOS and Android experiences will eventually be done in React Native, a javascript technology that’s made to replace native Java/Objective C coding." -- https://medium.com/presence-product-group/javascript-and-nod...
You mean eating the visible world. There's all the code which isn't public facing that runs everything else. For that matter, JS is dependent on layers of code not written in JS, some of which is visible.
Also, it's not like other programming languages don't have the features you listed. JS is playing catchup.
Also, it's not like other programming languages don't have the features you listed. JS is playing catchup.
That is because Html is a more readable form of RTF, but still a document descriptor none the less. and hack in with javascript.
If the world had settle in Word format, instead of javascript we will be using VBA, and everything else will look exactly the same.
I think what we really need is a web app environment, with programming as the first though
If the world had settle in Word format, instead of javascript we will be using VBA, and everything else will look exactly the same.
I think what we really need is a web app environment, with programming as the first though
I have been working with web technologies directly (not through Java or some other language) full time for almost 20 years. Here is the problem:
* In the 90s sloppy was awesome. The web is driven by marketing interests and not by technology interests. The name of the game back then was "get big fast". You need incompetent developers (many of them) to work in the technologies for extremely low pay, which means the technology must be extremely forgiving. The technologies tolerate a tremendous amount of sloppiness and so become sloppy themselves.
* The education around web technologies is deplorable. There are a couple of reasons for this. The technology is moving, growing, and enhancing rapidly making it hard to keep up with. Because there is sloppiness baked in its hard for people to immediately jump in and know the best approaches and avoid the pitfalls. Web technologies are generally considered incompetent toys (in academia) compared to more entrenched technologies like C++ and its spawn (C# and Java).
* Don't break the web. This means old broken approaches (the sloppiness) will continue to be supported forever even after they are deprecated and killed. We know what the best approaches are, but making the technologies more strict and unforgiving is the enemy of all marketing and shames incompetent developers (most of them). It is one thing if your language of choice fails and yells at you during a build process, but it is something different when this happens in production because web technologies don't require a build process.
You can safely ignore the technology excuses from many of the replies on here. These opinions come from people who learn web technologies only after learning something else (unrelated) first. For example, JavaScript is not Java, and if you look at it through a Java lens it will be incompetent for all kinds of reasons, but really the developer is just wishing they were still writing in Java. JavaScript will never be language x, but that isn't a valid reason to call it incompetent.
* In the 90s sloppy was awesome. The web is driven by marketing interests and not by technology interests. The name of the game back then was "get big fast". You need incompetent developers (many of them) to work in the technologies for extremely low pay, which means the technology must be extremely forgiving. The technologies tolerate a tremendous amount of sloppiness and so become sloppy themselves.
* The education around web technologies is deplorable. There are a couple of reasons for this. The technology is moving, growing, and enhancing rapidly making it hard to keep up with. Because there is sloppiness baked in its hard for people to immediately jump in and know the best approaches and avoid the pitfalls. Web technologies are generally considered incompetent toys (in academia) compared to more entrenched technologies like C++ and its spawn (C# and Java).
* Don't break the web. This means old broken approaches (the sloppiness) will continue to be supported forever even after they are deprecated and killed. We know what the best approaches are, but making the technologies more strict and unforgiving is the enemy of all marketing and shames incompetent developers (most of them). It is one thing if your language of choice fails and yells at you during a build process, but it is something different when this happens in production because web technologies don't require a build process.
You can safely ignore the technology excuses from many of the replies on here. These opinions come from people who learn web technologies only after learning something else (unrelated) first. For example, JavaScript is not Java, and if you look at it through a Java lens it will be incompetent for all kinds of reasons, but really the developer is just wishing they were still writing in Java. JavaScript will never be language x, but that isn't a valid reason to call it incompetent.
The web platform is disorganized and has many missing pieces. It has also grown quite a lot in the last couple of years, so it’s virtually impossible to understand all of it. As long as you’re disciplined about learning from the relevant blogs, it will “become better” (but it may take months).
How can you know what constitutes "relevant" though? There are loud voices in the community that seem right at first but the more you learn, the more you realise you may have been led astray. I guess that's a way of learning, but that particular path to enlightenment is covered in litter.
I suggest you choose to fall in love with Ember.js. She is the prettiest girl in your small town and she's really friendly. Start calling yourself a programmer instead of a coder - and help move Ember toward being, not just a framework, but an SDK for the web. Everyone can complain all they want about CSS and how it's broken etc, but no one has come up with a better solution. It's not the dark ages... in fact, it's the best time in web development so far. Developers haven't had to be 'designers' in the way they are being forced to now - with variable screen-size, and alternate UI patterns for each. HTML in little dynamic templates, variables for CSS preprocessors, ES6, and modular JS patterns. Things are wonderful. +1 for a new mental paradigm.
In my work I can be writing C++, or PHP or Javascript, depending on what part of the stack I'm working on.
C++ bugs are a bit hard to find, because the error messages are not very useful, so I launch the debugger, do a stack trace that fills the screen with arcane texts, then open the relevant source file in the line pointed by the debugger, and after about a minute of staring at that line and thinking, the bug is fixed.
In comparison to modern C++, JavaScript issues are complex beasts that can eat all your morning and give nothing in return. And then you test with another browser and it starts all over again.
Even so, some things like detecting the decimal separator supported by your operating system work in IE and Mozilla but were never implemented in Chrome, so you can't never really fix that 'bug'.
C++ bugs are a bit hard to find, because the error messages are not very useful, so I launch the debugger, do a stack trace that fills the screen with arcane texts, then open the relevant source file in the line pointed by the debugger, and after about a minute of staring at that line and thinking, the bug is fixed.
In comparison to modern C++, JavaScript issues are complex beasts that can eat all your morning and give nothing in return. And then you test with another browser and it starts all over again.
Even so, some things like detecting the decimal separator supported by your operating system work in IE and Mozilla but were never implemented in Chrome, so you can't never really fix that 'bug'.
I think what saddens me with web programming, is constant rewrites of the same old projects, that pretty much do the same thing. As a community we'd be better to focus on a few core APIs like a web shop or a booking app.
A church or school could have a common underlying built platform. Where functions of outfits are unified, we could drop in one size fits all solutions.
In England (UK) you have about 24 thousand schools these could be aided/driven by a few competing platforms. Charities and small shops likewise.
Platform constraints can also help. Having fixed html, perhaps would let designers just swap out CSS and imagery - job done.
Much web work is a brain drain, and a lot of good talent in my eyes is being squandered on petty engineering problems, when there is still a world out there that needs putting right.
A church or school could have a common underlying built platform. Where functions of outfits are unified, we could drop in one size fits all solutions.
In England (UK) you have about 24 thousand schools these could be aided/driven by a few competing platforms. Charities and small shops likewise.
Platform constraints can also help. Having fixed html, perhaps would let designers just swap out CSS and imagery - job done.
Much web work is a brain drain, and a lot of good talent in my eyes is being squandered on petty engineering problems, when there is still a world out there that needs putting right.
Why do you need any new APIs for that? Sounds like you just need a shared template.
I appreciate that a web shop could want for more than basic html representation. Although arguably there is something already like this: http://schema.org/Product . A search API?
But yes, good templates go a long way.
But yes, good templates go a long way.
Hmm, interesting ideas. I particularly like the search one, it'd be interesting if I could generate a search index that conforms to a particular spec and just store it as a static file which your browser can grab.
Any software, no matter what type, that evolves over time will become a series of hacks on hacks. The more the frequency of evolution is the more hacks will be there. Unfortunately the frequency of evolution in any web app is way way too much then other kinds of applications.
Everything is simple.
There is just a lot of it.
That's pretty much my view of internet and web technologies over time. It all did work, it all continues to work, to address security/performance/convenience we collectively add a few more little simple features/workarounds/quirks.
But ultimately the perception of the hackery of it all really stems from:
1. Quantity. There's a lot of stuff, it all works to some definition of "works" and there is typically more than one way of doing something.
2. Quality. When things are made, they are made for that time. As time goes by we can more clearly see the ambiguity of something, or the incompleteness of a feature, but by then it's too late and it's set in stone, our fix is usually to add something new (see #1).
There is just a lot of it.
That's pretty much my view of internet and web technologies over time. It all did work, it all continues to work, to address security/performance/convenience we collectively add a few more little simple features/workarounds/quirks.
But ultimately the perception of the hackery of it all really stems from:
1. Quantity. There's a lot of stuff, it all works to some definition of "works" and there is typically more than one way of doing something.
2. Quality. When things are made, they are made for that time. As time goes by we can more clearly see the ambiguity of something, or the incompleteness of a feature, but by then it's too late and it's set in stone, our fix is usually to add something new (see #1).
[deleted]
This thread is just a big circle jerk of non web-developers hating on web development.
Minimize you dependencies, organize your code into easy-to-fit-in-your-head, single-responsibility modules. Write a simpler solution instead of including another 100kb minified mess.
Someone else said it, but I'll repeat it: systems scale, languages don't. Javascript can be as good a language as any if you use it correctly. People bitch about the footguns but don't take the time to design their systems correctly. Yeah, Javascript fucking sucks when you write 10k lines of incoherent JQuery-soup in a single index.js file that provides all the functionality of your shitty asp.net page from 2001. Well no shit? You can write garbage in any language.
/rant
Minimize you dependencies, organize your code into easy-to-fit-in-your-head, single-responsibility modules. Write a simpler solution instead of including another 100kb minified mess.
Someone else said it, but I'll repeat it: systems scale, languages don't. Javascript can be as good a language as any if you use it correctly. People bitch about the footguns but don't take the time to design their systems correctly. Yeah, Javascript fucking sucks when you write 10k lines of incoherent JQuery-soup in a single index.js file that provides all the functionality of your shitty asp.net page from 2001. Well no shit? You can write garbage in any language.
/rant
Yes, the web is a very messy place. Maybe a kind of wild west of programming practices?
But it's also a place where you can do a lot of things that no one has thought before. There are not many rules and a wide diversity of approaches. The web platform never had many of those approaches (e.g. complex web applications) in mind when it was created. It works somehow, anyhow. It's chaotic, yes, but also flexible and full of freedom.
To stay sane in this world, you have to voluntarily and deliberatly (!) reduce this freedom and create yourself some small sane pockets that you understand well enough and feel comfortable with. This can be done by increasing the abstraction level and restricting feature sets (e.g. ESlint), using Frameworks (React, Bootstrap, ...) and transpilers (TypeScript, Babel, Sass). Note that you're loosing freedom here and you're buing into other peoples understanding how a sane place of web programming should look like. In the Web there are a lot of ways to do things, there's no monoculture! And if you don't like the existing ways, roll out your own (though I wish people would be more careful / sceptical with this attitude).
And there's the backend. You've got all choices of programming languages and frameworks there. If you're making a mess of you're backend, you really can't blame the web for it.
For someone without much web experience, this process of choosing frameworks, workflows, toolsets just to get to one (of many!) sane programming experience is surely daunting. You have to choose and configure your envirionment yourself first, just to get started. You really need someone experienced to set this up and understand most of its implications. If you're having so bad experiences with your current web project, maybe some bad decisions were made regarding this. Or too much freedom (and therefore chaos) was left in place and got out of hand.
If you don't have the experience to make those decisions, you could just start with one approach that is pupular right now. I guess on hacker news this would be something like React, Babel, etc.. There are a lot of tutorials out there to put this all together.
But it's also a place where you can do a lot of things that no one has thought before. There are not many rules and a wide diversity of approaches. The web platform never had many of those approaches (e.g. complex web applications) in mind when it was created. It works somehow, anyhow. It's chaotic, yes, but also flexible and full of freedom.
To stay sane in this world, you have to voluntarily and deliberatly (!) reduce this freedom and create yourself some small sane pockets that you understand well enough and feel comfortable with. This can be done by increasing the abstraction level and restricting feature sets (e.g. ESlint), using Frameworks (React, Bootstrap, ...) and transpilers (TypeScript, Babel, Sass). Note that you're loosing freedom here and you're buing into other peoples understanding how a sane place of web programming should look like. In the Web there are a lot of ways to do things, there's no monoculture! And if you don't like the existing ways, roll out your own (though I wish people would be more careful / sceptical with this attitude).
And there's the backend. You've got all choices of programming languages and frameworks there. If you're making a mess of you're backend, you really can't blame the web for it.
For someone without much web experience, this process of choosing frameworks, workflows, toolsets just to get to one (of many!) sane programming experience is surely daunting. You have to choose and configure your envirionment yourself first, just to get started. You really need someone experienced to set this up and understand most of its implications. If you're having so bad experiences with your current web project, maybe some bad decisions were made regarding this. Or too much freedom (and therefore chaos) was left in place and got out of hand.
If you don't have the experience to make those decisions, you could just start with one approach that is pupular right now. I guess on hacker news this would be something like React, Babel, etc.. There are a lot of tutorials out there to put this all together.
I totally agree you except I do think that the web can mess up the server-side stuff as well.
At the core things can be really simple, but then you need to set up SSL, some kind of database and potentially integrate a bunch of different services for things like sending emails, analytics, etc... At that point it is pretty easy to and up with a giant mess. These types of dependencies are not totally necessary but they are definitely part of the culture of web-development.
At the core things can be really simple, but then you need to set up SSL, some kind of database and potentially integrate a bunch of different services for things like sending emails, analytics, etc... At that point it is pretty easy to and up with a giant mess. These types of dependencies are not totally necessary but they are definitely part of the culture of web-development.
Ok, you're right, and I wasn't completely sure myself when writing this sentence. There are cases (integration of web services, the overall architecture) when some difficulties from the web architecture swap over to the backend.
But wouldn't you have a similar problem if you try to integrate something other than web services, too?
But wouldn't you have a similar problem if you try to integrate something other than web services, too?
One thing that frustrates me as a front-end dev is the inability to settle down in an ecosystem. Every minute, new tool/framework is coming with a tagline "There is no need to do that like you did with X, Y takes care of it for you".
Now the Y might be webpack/React, tomorrow it might me something else. Whoever says React gives them a consistent way of doing things, they would have said the same thing to Backbone/Angular/ember/bower/grunt/less/sass/precss/postcss/ .............
Ultimately, it is about controlling your mindset and navigating through this onslaught of tools/frameworks in the front end ecosystem.
Now the Y might be webpack/React, tomorrow it might me something else. Whoever says React gives them a consistent way of doing things, they would have said the same thing to Backbone/Angular/ember/bower/grunt/less/sass/precss/postcss/ .............
Ultimately, it is about controlling your mindset and navigating through this onslaught of tools/frameworks in the front end ecosystem.
One of my absolute favorite online comments is https://www.reddit.com/r/reactjs/comments/39wsfi/what_are_pr... :
"Every framework can be viewed as an attempt to say "the hardest part of writing a webapp is {X}, so here's some code to make that easier". ... Backbone is the result of feeling like the hard parts are fetching and persisting models to a REST API, and client side routing; that's basically all it does. Figuring out how to turn your models into HTML is easy (apparently), but models are hard, so it helps you.
Angular is what you get if you think the biggest problem with writing webapps is that Javascript isn't Java; Ember that it's not Ruby. (I kid. But I'm less familiar with those frameworks.) And so on. Everyone has their own ideas of what's hard to solve.
React + Flux is based on the idea that what's really hard with writing webapps is non-deterministic behaviour and unclear data flow. And if you've worked on a large Knockout or Backbone project, you're probably inclined to agree."
"Every framework can be viewed as an attempt to say "the hardest part of writing a webapp is {X}, so here's some code to make that easier". ... Backbone is the result of feeling like the hard parts are fetching and persisting models to a REST API, and client side routing; that's basically all it does. Figuring out how to turn your models into HTML is easy (apparently), but models are hard, so it helps you.
Angular is what you get if you think the biggest problem with writing webapps is that Javascript isn't Java; Ember that it's not Ruby. (I kid. But I'm less familiar with those frameworks.) And so on. Everyone has their own ideas of what's hard to solve.
React + Flux is based on the idea that what's really hard with writing webapps is non-deterministic behaviour and unclear data flow. And if you've worked on a large Knockout or Backbone project, you're probably inclined to agree."
It's not just "takes care of it for you". The constraints and assumptions are rarely mentioned, so every other thing is marketed (sometimes by its very owners, sometimes by the community) almost as a miracle that is - unlike its puny predecessors - "just works". Creating an impression things are easy.
My usual story with every new library, toolkit or framework (with the pace JS world's moving, it's new one for every new project) is that I start with "oh, nice" then find myself knee-deep into the its gory intestines, trying figure out how some "magic" works and how to make it do things I want or need it to do. No fun at all.
My usual story with every new library, toolkit or framework (with the pace JS world's moving, it's new one for every new project) is that I start with "oh, nice" then find myself knee-deep into the its gory intestines, trying figure out how some "magic" works and how to make it do things I want or need it to do. No fun at all.
I've been doing web development since 1995, starting with CGI "apps" in C and Perl. Yes, it is a pile of hacks. The fundamental issue is we're building "apps" on an environment intended for document delivery.
Is it really that there's some exceptionally high amount of hackery? Or is it just different hackery than the kind you're used to and have so thoroughly internalized that you no longer see it as a pile of hacks?
I like to think of web programming like the english language, how it's a mashup of all these other languages and ideas. It's hard to learn as an outsider and has many gotcha's and wrote learning exercises
Currently at work someone wants to learn to create web pages and prototype his ideas. He asked me if he's ready because he's learning JavaScript and I had to reply you still need to learn html, Css, sql and a server language to do what we do how we do it. It's a shame so he moved on to some new site / page from mit that's allows drag and drop boots troop elements and drag and drop database logic like "users must be logged in". It's unfortunate there's not much of a middle grown between learning 5 things and drag and drop.
Web programming is not that bad and I think you are missing something.
You're entering a time where ES6 is mostly implemented and should be feature-complete in most platforms soon. I cannot explain how big of an improvement this language is. Javascript used to be a language that other people worked in and I refused to understand. I wrote some thing in it and dabbled when necessary but I was always amazed at how primitive it was for such a high-level language. It was usable though with a bunch of libraries to support you. ES6 makes most of that legacy obsolete.
However ES6 is a bit of a kitchen-sink language now. There are multiple means to iterate over a collection, there are classes, monads and functors... did I just say monads? I meant Promises. And did I say functors? I meant sequence types with a useful prototype. The point is that if you choose the right subset for you it's a decent language now.
HTML5 kills the notion that, "the web is only for documents!" The acronym has aged a bit and is not really descriptive of what HTML5 is anymore. Most GUI libraries and systems I've seen implement the interface in terms of a tree of "objects" with the root node being the Window itself. That is essentially what the DOM is now with the browser providing the run-time loop, input, etc. We have a rather rich array of elements to work with... buttons, input boxes, a rich layout model, 2D canvases, WebGL contexts...
Where it does still suck and where I think you might be getting frustrated is in the tooling. There isn't much of a standard library in Javascript save for the objects you're given. They all loosely fit together with little cohesion. It is quite frustrating to get a program started and take it all the way to something on the level of Gmail, Facebook, or Twitter. It's even more frustrating if your expectation is an environment such as Qt where you have standard tools, libraries, and all of that.
However with some effort and determination you can tame the beast. The part of the kitchen I find most effective is the functional programming side. I use Fantasyland compatible libraries and wrap other libraries with them. I've devised my own configuration of build tools based on Webpack, npm, that I can spin up with Yeoman. It's not great but it's tolerable.
... but now I'm looking into Bucklescript since I'm a closet OCaml fan... and that seems to be another popular angle for building "large" applications in Javascript: compile down from a more familiar language with the tooling you need.
Nothing is straight-forward. Not immediate-mode custom UIs; not big, fancy frameworks like Qt; and certainly not the web... but the web as a platform is awfully powerful, flexible, and open.
You're entering a time where ES6 is mostly implemented and should be feature-complete in most platforms soon. I cannot explain how big of an improvement this language is. Javascript used to be a language that other people worked in and I refused to understand. I wrote some thing in it and dabbled when necessary but I was always amazed at how primitive it was for such a high-level language. It was usable though with a bunch of libraries to support you. ES6 makes most of that legacy obsolete.
However ES6 is a bit of a kitchen-sink language now. There are multiple means to iterate over a collection, there are classes, monads and functors... did I just say monads? I meant Promises. And did I say functors? I meant sequence types with a useful prototype. The point is that if you choose the right subset for you it's a decent language now.
HTML5 kills the notion that, "the web is only for documents!" The acronym has aged a bit and is not really descriptive of what HTML5 is anymore. Most GUI libraries and systems I've seen implement the interface in terms of a tree of "objects" with the root node being the Window itself. That is essentially what the DOM is now with the browser providing the run-time loop, input, etc. We have a rather rich array of elements to work with... buttons, input boxes, a rich layout model, 2D canvases, WebGL contexts...
Where it does still suck and where I think you might be getting frustrated is in the tooling. There isn't much of a standard library in Javascript save for the objects you're given. They all loosely fit together with little cohesion. It is quite frustrating to get a program started and take it all the way to something on the level of Gmail, Facebook, or Twitter. It's even more frustrating if your expectation is an environment such as Qt where you have standard tools, libraries, and all of that.
However with some effort and determination you can tame the beast. The part of the kitchen I find most effective is the functional programming side. I use Fantasyland compatible libraries and wrap other libraries with them. I've devised my own configuration of build tools based on Webpack, npm, that I can spin up with Yeoman. It's not great but it's tolerable.
... but now I'm looking into Bucklescript since I'm a closet OCaml fan... and that seems to be another popular angle for building "large" applications in Javascript: compile down from a more familiar language with the tooling you need.
Nothing is straight-forward. Not immediate-mode custom UIs; not big, fancy frameworks like Qt; and certainly not the web... but the web as a platform is awfully powerful, flexible, and open.
Nah, you are not missing anything. You are not alone, but you are also resisting change because you are not use to this fast pace of change. The reality is that you need really great memory and ability to organize and discover information fast to make sense of todays applications. It's layers upon layers of abstraction. It's terrible in a way when you have to work with others you have to deal with it. When you work by yourself, just keep it simple, choose a few well proven and solid stacks and just stick with them.
Application development on a web platform meant for documents is inherently a hack, but the evolution of the ecosystem is reaching a point where many of the hacks are quite good. There's just a lot of inertia from existing codebases and developers used to the previous ways of doing things, and FUD from places like Google with Angular and Polymer.
Web development seems to be particularly suited to the model of building a hack, then pouring concrete over it, then building the next layer of hacks on top.
Web development seems to be particularly suited to the model of building a hack, then pouring concrete over it, then building the next layer of hacks on top.
[deleted]
I was thinking about this the other day, and one possible way to improve the situation is place a hard separation between web documents from web applications. Currently we try to shove both capabilities into a single paradigm (stack). But the two don't mix well.
What might that look like? Ultimately a much more elegant HTML and simplified CSS for web documents, and quite likely no HTML for web apps -- the Javascript and CSS would merge into a GUI-oriented language.
What might that look like? Ultimately a much more elegant HTML and simplified CSS for web documents, and quite likely no HTML for web apps -- the Javascript and CSS would merge into a GUI-oriented language.
Yes.
It should have stayed as hypertext documents, just plain HTML + CSS, with everything else just covered by network protocols.
Instead it is a pile of hacks of trying to bend HTML + CSS + JavaScript to behave like native applications, but not quite, because the browser is in control of the L&F leading to yet another pile of hacks to make the already existing hacks to behave the same across all required browsers (including different versions of the same browser).
It should have stayed as hypertext documents, just plain HTML + CSS, with everything else just covered by network protocols.
Instead it is a pile of hacks of trying to bend HTML + CSS + JavaScript to behave like native applications, but not quite, because the browser is in control of the L&F leading to yet another pile of hacks to make the already existing hacks to behave the same across all required browsers (including different versions of the same browser).
One important thing is a final web page is a confluence of code coming from different sources, and not controlled by the end user or the developer/website. If you define some functionality, I could just override (intentionally or not) with my code which also gets loaded along with yours.
Combine this with the inconsistent browser playground, you might get some perspective of the hacky nature of the workings in the front end world.
Combine this with the inconsistent browser playground, you might get some perspective of the hacky nature of the workings in the front end world.
I agree, its way more complex than it should be, probably something to do with the browser wars and propriety software battling to add barriers of access
Have a look at Elm. That looks like a fairly promising alternative to some of this mess. I don't think you can get away from CSS and HTML5 though.
Are you sure the assessment web programming being a series of hacks on hacks isn't an artifact of inheriting a fairly long-lived and large code base?
I don't think I've touched a large codebase that has been around for a long time which didn't feel hackish.
I'd make the evaluation of web programming based on a language and framework that feels most proper to you, and based on the use of it with a brand new app.
I don't think I've touched a large codebase that has been around for a long time which didn't feel hackish.
I'd make the evaluation of web programming based on a language and framework that feels most proper to you, and based on the use of it with a brand new app.
My view is exactly contrary coming from system development experience. I cannot think why would anybody handcraft MVCish frameworks in js, jquery etc. I have programmed MVCish UI frameworks and middleware in c for AV products 10 years ago. And as a UI dev u want a working MVC. Now I'm using angular and totally feel at home. I think sans these new frameworks web must have been really dark place.
As working on backend and front end for many projects for different size of projects over years, I would say 'yes' as my short answer.
It might be hack on top of hack, but I find it quite enjoyable when I'm completely in control of what I'm delivering. When I know what's reliable and what's dangerous, I can work around those limitations. Where things get particularly painful are when you are at the mercy of decisions made by a client or boss who won't listen to reason. Then it's hell.
I agree, and I decided I won't accept the hacks and compromises anymore, and started building everything in Go (even frontend stuff) in my free time. There's much to do, but at least the foundation (type system, type safety, etc.) is very solid.
This way, I don't have to build on top of the hacky and messy things anymore, but slowly take my time and do things very right.
This way, I don't have to build on top of the hacky and messy things anymore, but slowly take my time and do things very right.
There isn't much of a difference between web and application development in my eyes. Both should be build on a service backend, with a common architecture making different systems work together through APIs or MOX-agents.
In that world the "view" part of your system might as well be web based. Making front end look and feel good, is terrible in everything anyway.
In that world the "view" part of your system might as well be web based. Making front end look and feel good, is terrible in everything anyway.
Not gonna comment on most of this, as I'm right there with you. Web development is a gigantic shit sandwich. But I have to at least respond to this:
> I'm not even talking about the fact that everything has to be stateless, in fact I develop desktop apps as stateless even driven UIs as well,
No, you do not. UIs are state machines (not like state machines, they actually are state machines). It is impossible to have a stateless interactive UI. If it is stateless, it might be a web page or document, but it is not a UI.
Any attempt to make a "stateless" UI will fail because of this impossibility. What many half-baked frameworks will attempt to do is make them as stateless as possible, which is a recipe for disaster, as they can't actually get rid of the state, they can only move it to some location where it wasn't designed to store state (Routes? Cookies?), or to some location where the semantics and comprehensibility have been compromised. In fact, this statelessness is precisely one of the major problems with web programming...you're trying to bolt something inherently stateful onto a format that was designed for statelessness (HTML was created for documents, not apps).
Programmers in general, and UI programmers in particular, need to get over their fetish for statelessness. Sure, modeling a stateless problem with stateful code is ridiculous, but if you try to model a stateful problem with stateless code you are going to have a much worse time. Modeling state is hard...don't make it harder by pretending it doesn't exist.
> I'm not even talking about the fact that everything has to be stateless, in fact I develop desktop apps as stateless even driven UIs as well,
No, you do not. UIs are state machines (not like state machines, they actually are state machines). It is impossible to have a stateless interactive UI. If it is stateless, it might be a web page or document, but it is not a UI.
Any attempt to make a "stateless" UI will fail because of this impossibility. What many half-baked frameworks will attempt to do is make them as stateless as possible, which is a recipe for disaster, as they can't actually get rid of the state, they can only move it to some location where it wasn't designed to store state (Routes? Cookies?), or to some location where the semantics and comprehensibility have been compromised. In fact, this statelessness is precisely one of the major problems with web programming...you're trying to bolt something inherently stateful onto a format that was designed for statelessness (HTML was created for documents, not apps).
Programmers in general, and UI programmers in particular, need to get over their fetish for statelessness. Sure, modeling a stateless problem with stateful code is ridiculous, but if you try to model a stateful problem with stateless code you are going to have a much worse time. Modeling state is hard...don't make it harder by pretending it doesn't exist.
[deleted]
Frontend always was and always will be harder than backend, regardless of the platform/framework etc.
Yes, the fact that HTML / CSS is a technology designed in a different era (slow keyboard+mouse desktops) for a different purpose (displaying static hyperlinked documents) doesn't make life any easier.
Everything is a mess, so keep it as simple as possible. Yeah it's nice to have an awesome frontend with javascript but it's much simpler and cleaner to post something back to the server.
I fell in love with web programing 14 years ago because I don't have to save the state of the UI and activate or deactive buttons.
I fell in love with web programing 14 years ago because I don't have to save the state of the UI and activate or deactive buttons.
true, unless you look at incredible new ways of UI design like React and its Clojurescript counterpart, Om and others. FRP and similar concepts has so dramatically changed how I think about software design that I now use it for most of my native C++ projects as well, or at least, I get as close to it as I can.
> Is web programming really that bad? Is it really just that I need a new mental paradigm?
In the sense that there's 1000 web frameworks that all put their own shitty spin on everything, yes definitely. OTOH it shouldn't be hard for you to improve on those things and release web framework #1001.
In the sense that there's 1000 web frameworks that all put their own shitty spin on everything, yes definitely. OTOH it shouldn't be hard for you to improve on those things and release web framework #1001.
This is a good resource in terms of 'getting your head into the space'.
https://12factor.net/
Not aimed at beginners but it made me think a lot more about how complex this can actually be then a set of related technologies.
https://12factor.net/
Not aimed at beginners but it made me think a lot more about how complex this can actually be then a set of related technologies.
HTML and JS are bad, but you can reduce them to a basic syntax that you can work with. CSS on the other hand requires hacks to perform the most basic operations like positioning an element relative to another element or centering an element inside of a container.
As a non-web-dev, the hardest problem I've encountered is choice.
Which framework should I choose to do X? To do Y? Do they play together? Are they still supported? Are they well documented? What assumptions are made by them?
There are dozens of options for most things, but no guide to them.
Which framework should I choose to do X? To do Y? Do they play together? Are they still supported? Are they well documented? What assumptions are made by them?
There are dozens of options for most things, but no guide to them.
Isn't everything? The older I get the more I realize that all of the orderly systems I thought governed life, society and the universe are in fact a system of hacks and bag of tricks. Sure there are rules. Except when there are exceptions. And on it goes.
From my experience, it is, especially in front end development when you must have cross-browser support. For me the term cross-browser support itself is quite amusing and nonsensical given that there is supposed to be a standard.
So what exactly are the front-end stack haters proposing as an alternative to hack-on-hack? Should we just dev/maintain N code bases of native apps to run on every OS and then somehow connect them?
Haters are missing the big picture...
Haters are missing the big picture...
Yeah it is. Django is a good example of a framework that is popular and well documented overall. Yet when a new Django revision comes out the books and documentation from third parties take months to follow on. So by the time I've learned all the major changes in a revision well enough it's already party over for that revision. Official support is just ending because they have a new revision out. Unless it's an LTS build but that means there is a whole lot of new stuff in these non-LTS releases.
I for one would prefer to have Django and other projects abandon the minor revision numbers like 1.8 and 1.9 in favor of what Asterisk did and call them what they are. Version 8 and Version 9.
That'd make it feel less hacky and if done right they could encourage longer support cycles for these major version releases.
I for one would prefer to have Django and other projects abandon the minor revision numbers like 1.8 and 1.9 in favor of what Asterisk did and call them what they are. Version 8 and Version 9.
That'd make it feel less hacky and if done right they could encourage longer support cycles for these major version releases.
Django is moving in that direction by having each LTS have its own major version number, and backwards compatibility guarantees within each major version. So you can think in terms of major versions every two years if you want.
You can start your project on Django 2.0 (expected December 2017) and "Version 2" will be supported (via 2.2 LTS) through April 2022.
https://www.djangoproject.com/download/#supported-versions
You can start your project on Django 2.0 (expected December 2017) and "Version 2" will be supported (via 2.2 LTS) through April 2022.
https://www.djangoproject.com/download/#supported-versions
It's the same like any other open source project: it gives you 100 ways to hang yourself and maybe only one way to do it right. Your job is then how to find that one way.
Frameworks? use them when you need to deliver crap, fast! :)
Frameworks? use them when you need to deliver crap, fast! :)
You are not crazy. Many, many people have come before you and asked the same. The reply is always the same. Yet the craziness continues, it multiplies and it leaves nothing in its wake. Nothing stirred in the embers.
And the DOM was.
And the DOM was.
my biggest realisation of this was when reading the opening chapters to Michel Zalewski's Tangled web [1]. He does an excellent brief intro to how we got to where we are, warts and all.
Things like content sniffing where a browser can't work out what type of file it's been given, so has an algorithm to take a guess and render based on that are what we've got to deal with.
[1] https://www.amazon.com/Tangled-Web-Securing-Modern-Applicati...
Things like content sniffing where a browser can't work out what type of file it's been given, so has an algorithm to take a guess and render based on that are what we've got to deal with.
[1] https://www.amazon.com/Tangled-Web-Securing-Modern-Applicati...
If you've been codign "since before the web", then you should be able to see the whole picture. The browser is the new VM. Horrible hacks are necessary to test ideas and move forward new paradigms.
About 15 years ago I made the conscious decision to ignore web programming entirely, in the hopes that in a few years things would settle down and get some sanity. Apparently this has not happened.
Its very, opinionated. It has to be! (for now)
I can agree with almost every opinion in the comments, almost everyone is right. But with a strong opinion and a strong mental model there is light at the end of the tunnel.
The future is bright for web applications, and almost everyone in the space is aware of the biggest issues, which is important as the browsers adapt new features to help ease the pain.
Web development is a scary place but it can be enjoyable when the right pieces are in place. Older web applications have crazy hacks and made up anti-patterns to solve problems, which mix context between the client and the server making it a nightmare to wrap your head around or even implement new features.
Often a new feature in such application guides the developer to accept the fate of adding more technical debt, and creates a strong desire for a better way with no way out without a major overhaul of the backend and frontend. I have spent countless hours building patches to older systems just to prepare them for the option of pivoting to more modern approaches.
Today web application development is a fast moving target. Design patterns are changing from framework to framework. Even from framework version to version. i.e Angular 2.
It's almost as if the current state of frontend development is very comb shaped. broad in approaches, and that the community is digging deep into patterns that are showing success in scaling, and performance. We have to deal with various topics, the lack of concurrency, performance of the DOM, managing scope, and state.
I have a few opinionated methodologies to help me in modern web development.
1. Pick a strong frontend and backend frameworks and know them well.
2. Don't mix the backend and the frontend code. Keep the backend API in context to the business domain, data validation, and security. Allow the client to be an independent consumer of the API for portability and scalable distribution.
3. Keep your JSON responses as flat as possible, and avoid deeply nested data structures. Rely on functional programming to map and reduce your data on the client into deeply nested structures if needed.
4. Decide what the client can compute for free computation cycles.
5. Stay as data-driven as possible. Fall back to the server or micro-service if the client is not efficient at a demanding task.
6. Choose libraries with the least restraints and high flexiblity. They should not obfuscate or complicate your ability to implement the design. I find most libraries can assume to much control.
We are in a better place today then we have ever been for web applications. Though the learning curve is intense and the subjects broad. Especially for fullstack developers. I feel that finding what works and an opinion of how it should be done is important.
I am less picky about the backend technolgies as I am with the frontend. I would really only consider Angular, or React for my frontend. Both Angular and React expect you to form a mental model of how they work, and what a build pipeline should look like which is very project specific in my experience.
Its the wild west our here, and expect things to continue to change. Building an opinion, vetting new libraries to add to your toolbox, and experimenting is just part of the web application world.
I can agree with almost every opinion in the comments, almost everyone is right. But with a strong opinion and a strong mental model there is light at the end of the tunnel.
The future is bright for web applications, and almost everyone in the space is aware of the biggest issues, which is important as the browsers adapt new features to help ease the pain.
Web development is a scary place but it can be enjoyable when the right pieces are in place. Older web applications have crazy hacks and made up anti-patterns to solve problems, which mix context between the client and the server making it a nightmare to wrap your head around or even implement new features.
Often a new feature in such application guides the developer to accept the fate of adding more technical debt, and creates a strong desire for a better way with no way out without a major overhaul of the backend and frontend. I have spent countless hours building patches to older systems just to prepare them for the option of pivoting to more modern approaches.
Today web application development is a fast moving target. Design patterns are changing from framework to framework. Even from framework version to version. i.e Angular 2.
It's almost as if the current state of frontend development is very comb shaped. broad in approaches, and that the community is digging deep into patterns that are showing success in scaling, and performance. We have to deal with various topics, the lack of concurrency, performance of the DOM, managing scope, and state.
I have a few opinionated methodologies to help me in modern web development.
1. Pick a strong frontend and backend frameworks and know them well.
2. Don't mix the backend and the frontend code. Keep the backend API in context to the business domain, data validation, and security. Allow the client to be an independent consumer of the API for portability and scalable distribution.
3. Keep your JSON responses as flat as possible, and avoid deeply nested data structures. Rely on functional programming to map and reduce your data on the client into deeply nested structures if needed.
4. Decide what the client can compute for free computation cycles.
5. Stay as data-driven as possible. Fall back to the server or micro-service if the client is not efficient at a demanding task.
6. Choose libraries with the least restraints and high flexiblity. They should not obfuscate or complicate your ability to implement the design. I find most libraries can assume to much control.
We are in a better place today then we have ever been for web applications. Though the learning curve is intense and the subjects broad. Especially for fullstack developers. I feel that finding what works and an opinion of how it should be done is important.
I am less picky about the backend technolgies as I am with the frontend. I would really only consider Angular, or React for my frontend. Both Angular and React expect you to form a mental model of how they work, and what a build pipeline should look like which is very project specific in my experience.
Its the wild west our here, and expect things to continue to change. Building an opinion, vetting new libraries to add to your toolbox, and experimenting is just part of the web application world.
I think any programming model that's been around for a long time is complex. Backward compat is the devil. Take OpenGL for example. All the compat stuff has made it practically impenetrable.
HTML, CSS and JavaScript are improving. Your experience as a web programmer depends on the browsers you are working with. If your clients include IE6 users, your life is going to be worse.
It is the amazing architecture that integrates those hacks, though.
Because it has to do something nothing could everdone before ? Unites the worl, provides collaborative environment. So it needs time to evolve. You will hate it less overtime
where does the hacking end?
i see using an electron passing over an elemental substrate as a hack of electromagnetism to allow its properties to represent arithmetic logic
i see little endian as a hack of binary notation of sets to be able to compose information
everything you do is a hack on top of a hack.. on the shoulders of giant stacked turtles.. or some such
what about web development sucks for you? in recognising them do you have any ideas for how to relieve your pain points?
web development is the same as application work.. solving problems
i see using an electron passing over an elemental substrate as a hack of electromagnetism to allow its properties to represent arithmetic logic
i see little endian as a hack of binary notation of sets to be able to compose information
everything you do is a hack on top of a hack.. on the shoulders of giant stacked turtles.. or some such
what about web development sucks for you? in recognising them do you have any ideas for how to relieve your pain points?
web development is the same as application work.. solving problems
I know there's a bit of boilerplate to learn, but if you stick to React + Redux + Fetch using Babel and Webpack, you'll have a much easier time of it overall.
Yes, it is. That is exactly what I have found. It's just insanity. I can honestly say Javascript made me cry today. It's not just you. There is a better way.
Yes, very much so. And everybody is too busy making money to go back to before all those wrong decisions and apply the knowledge we now got from hindsight.
You are resisting change. User experience code is different from backend code. It is often a pile of incomplete abstractions and device specific hacks.
It is but don't worry about it. It's getting better by the hour.
Just think about this: Has it ever been easier to reach so many people with so little effort?
Just think about this: Has it ever been easier to reach so many people with so little effort?
The trick to web-dev is to avoid a "back-end" at all costs. Just make all your "data" available in human friendly HTML.
Programming is just a series of hacks on hacks.
Yes, it sucks. So how do we fix it?
(In perfect world, how would you reinvent the web as an application platform...)
You sound like a good candidate for something like Elm (elm-lang.org), with its Elm Architechture.
That's a colorful way to put it, but yes! Of course it is. That's what makes it fun.
Web programming is ok. A lot of the complexity comes because it is actually two different problems:
1) The problem of displaying a (mostly static) page of HTML
2) The problem creating an application
There are web frameworks in existence that solve either of these problems, but things get ugly when people don't think about which problem they are trying to solve.
1) The problem of displaying a (mostly static) page of HTML
2) The problem creating an application
There are web frameworks in existence that solve either of these problems, but things get ugly when people don't think about which problem they are trying to solve.
The real problem is that 1 was turned into 2 without replacing 1. It's kind of amazing that HTML and CSS have survived all the way through 2016, and don't look they're going to be replaced for a long time.
[deleted]
Yes. And while HTML5 brought a lot of awesome features, it also created another set of problems, the least of which, is the syntax is impossible. There are 100 "right" ways to do things now, when in fact, a language should specify an exact way of doing something.
I have a a very similar background as the OP.
Also seen/worked on projects that are a mess and devs there built hacks upon hacks to keep everything up.
I also felt like I am stupid (besides studying software engineering and working in the web business for 15 years) or I miss something. But then I also had the privilege to work with very skilled people and get a different perspective.
Here comes my argument:
I argue that most projects that went to be a mess have been set up by people that had to work with incomplete information or insufficient time to conquer the stated problem. So I project the question "is-technology-the-problem?" to "is-the-team-the-problem?".
In my experience much bad influence - that create messy projects - comes from the lack or the way of communication between technical designers (who say whats possible), developers (who say how its possible) and other stakeholders (who normally "just want something"). I think of a situation here, where I had to work with a sales guy who proudly sold "rapid development" and "agile iterations" without understanding the technical or management perspective of true rapid development.
When it comes to making design decisions (which WILL influence the "messiness") the web is full of different approaches, technologies and so called "best practices". If you're a designer of a "will-become-big"-project it is difficult to make those decisions based on this variety of solutions (which as the OP stated almost everytime suck after some months). The fact that every framework presents itself as the best and most versatile does not help at all.
My best practice to go out and talk to people about my problem and not ask the internet. Its others people experience you only can access in a discussion, because normally you don't and cannot know what information you lack and therefore ask superficial questions on the web and thus get superficial solutions and have to conquer previously unexpected problems in long-term.
Another argument I want to make:
If you were a carpenter and would have to build the interior of an opera you would not go to the web, google for a month and then think you have exhausted all available resources and now you are ready to build that opera interior. The ubiquity of "quick solutions" make developers believe there are no long-term-effects of such decisions and thus most such small decisions never get discussed. If you have worked in teams in other branches (building digital arts, building a house boat, stuff like that, where you MUST have a team) you get the point of what I am saying. Its only computer science where people stop talking because they think everything is clear to everybody.
About your question about orientation:
I suggest getting aware of the high level concepts of full stack web development and truly understand the concerns every layer tries to attack. Web-Development - like every other software engineering discipline - is all about Devide&Conquer. N-Tier development (one approach to D&C) is nothing new, but the semantics of web development are new. A good designer has to speak those new semantics fluently. It also helps getting a good feeling about what actually is a "best practice" and what is just sold as such. There simply is no universality to web programming as there is none to other software engineering disciplines.
I gained a lot of confidence in knowing about the classification of problems and how you would generally combine them instead of building a big hashmap of problem -> web-tech-framework (This also reminded me of some complexity courses I took in my studies). Giving clear semantics to different parts of your application and discussing those layers using natural language also reduces your teams vulnerability to total chaos and prepares for unexpected changes of requirements.
Further I learned from experience that its often the time-constraint that promotes messy code that never gets cleaned up because the project somewhat dies a slow death, which in my eyes is just a reminder that web-tech is something new to the society as a whole.
Finally:
Thus I developed the following perspective: I see myself as a moderator of language and problem-awareness. I often argue in front of customers that if you describe the project as a map of the problem domain there are A LOT of blank areas and its our teams effort that will unveil/debunk/uncover those blank areas. I also point out that there are a lot of semi-blank-areas on our project map. I for example know how agile development looks like that does NOT generate a hack-upon-hack architecture but the others don't. On the other hand I have no knowledge whatsoever about interiors of operas (to reuse the example from above). Its that explicit merge of information that prevents a projects structure going astray.
Also seen/worked on projects that are a mess and devs there built hacks upon hacks to keep everything up.
I also felt like I am stupid (besides studying software engineering and working in the web business for 15 years) or I miss something. But then I also had the privilege to work with very skilled people and get a different perspective.
Here comes my argument:
I argue that most projects that went to be a mess have been set up by people that had to work with incomplete information or insufficient time to conquer the stated problem. So I project the question "is-technology-the-problem?" to "is-the-team-the-problem?".
In my experience much bad influence - that create messy projects - comes from the lack or the way of communication between technical designers (who say whats possible), developers (who say how its possible) and other stakeholders (who normally "just want something"). I think of a situation here, where I had to work with a sales guy who proudly sold "rapid development" and "agile iterations" without understanding the technical or management perspective of true rapid development.
When it comes to making design decisions (which WILL influence the "messiness") the web is full of different approaches, technologies and so called "best practices". If you're a designer of a "will-become-big"-project it is difficult to make those decisions based on this variety of solutions (which as the OP stated almost everytime suck after some months). The fact that every framework presents itself as the best and most versatile does not help at all.
My best practice to go out and talk to people about my problem and not ask the internet. Its others people experience you only can access in a discussion, because normally you don't and cannot know what information you lack and therefore ask superficial questions on the web and thus get superficial solutions and have to conquer previously unexpected problems in long-term.
Another argument I want to make:
If you were a carpenter and would have to build the interior of an opera you would not go to the web, google for a month and then think you have exhausted all available resources and now you are ready to build that opera interior. The ubiquity of "quick solutions" make developers believe there are no long-term-effects of such decisions and thus most such small decisions never get discussed. If you have worked in teams in other branches (building digital arts, building a house boat, stuff like that, where you MUST have a team) you get the point of what I am saying. Its only computer science where people stop talking because they think everything is clear to everybody.
About your question about orientation:
I suggest getting aware of the high level concepts of full stack web development and truly understand the concerns every layer tries to attack. Web-Development - like every other software engineering discipline - is all about Devide&Conquer. N-Tier development (one approach to D&C) is nothing new, but the semantics of web development are new. A good designer has to speak those new semantics fluently. It also helps getting a good feeling about what actually is a "best practice" and what is just sold as such. There simply is no universality to web programming as there is none to other software engineering disciplines.
I gained a lot of confidence in knowing about the classification of problems and how you would generally combine them instead of building a big hashmap of problem -> web-tech-framework (This also reminded me of some complexity courses I took in my studies). Giving clear semantics to different parts of your application and discussing those layers using natural language also reduces your teams vulnerability to total chaos and prepares for unexpected changes of requirements.
Further I learned from experience that its often the time-constraint that promotes messy code that never gets cleaned up because the project somewhat dies a slow death, which in my eyes is just a reminder that web-tech is something new to the society as a whole.
Finally:
Thus I developed the following perspective: I see myself as a moderator of language and problem-awareness. I often argue in front of customers that if you describe the project as a map of the problem domain there are A LOT of blank areas and its our teams effort that will unveil/debunk/uncover those blank areas. I also point out that there are a lot of semi-blank-areas on our project map. I for example know how agile development looks like that does NOT generate a hack-upon-hack architecture but the others don't. On the other hand I have no knowledge whatsoever about interiors of operas (to reuse the example from above). Its that explicit merge of information that prevents a projects structure going astray.
HTML5 seems significantly less advanced than Java AWT was in 1997.
But it looks prettier.
Are you talking about the client or server side?
house of cards.
with each card being the flavor of the month provided by an external source.
it's almost enough to make me want to go back to activex.
with each card being the flavor of the month provided by an external source.
it's almost enough to make me want to go back to activex.
Yes, it's you resisting change.
The web world is just a new world of different problems. One of the most interesting things about this world is there are a LOT of participants. A big part of the web world is diversity, it's kind of like moving from the country to a big multi cultural city. Many many many ideas are being thrown around. Finding cohesion between ideas is tricky. Being a learner in this world is bewildering.
Understanding the browser is very important, perhaps start with http://www.html5rocks.com/en/tutorials/internals/howbrowsers...
If you are a good coder, javascript can be awesome. Put a lot of time into understanding the language. Don't stray into variants like typescript or coffeescript or elm or anything else till you are pretty happy with js. Prioritize learning ES6 over any variants. The bulk of information on the net and libraries, etc is standard js.
Get a good understanding of webserver, HTTP / Web sockets. Sniff packets and also understand HTTPS.
Invest a lot of time into HTML and CSS, there's a lot of advice on how to build your own CSS frameworks from the ground up, this is really worthwhile. But also spend a bunch of time with something established like bootstrap ( or any other UI framework ) so you can see what problems frameworks are trying to solve.
Language? Frameworks? This is where it gets tricky. I suggest understanding a Node stack, as it's popular, and a lot of examples use it as a backend. It may not be what you actually end up using. Checkout Angular2, React / redux as they are popular javascript frameworks that run in the browser to deliver application like UI. However, go for statically generated pages if you don't need that kind of UI, classic GET/POST delivered webpages still deliver a lot of value.
Security / Authentication - Can be very tricky and in some environments it's left to roll your own
Data - Can be super convoluted, often taught in a web context without much concern for security and authentication (depending on stack). In general avoid having too many layers between your data store and the UI. SQL / NoSQL / BigData Stores are all toys to play with (but each data store tech has its own problems and tradeoffs) and more often are getting mixed together.
Now, because you can pick and choose nearly any aspect of the above, it can become very hackish, especially as new toys are coming along all the time.
If I was going to recommend a single thing to start playing around with? probably meteor. It packages up a lot of modern web things for you, it's all javascript, it uses a mongo back end (which is a json store, not necessarily the greatest choice of DB though), has a easy package system, and supports a number of popular front ends. None of which is how you should choose a production stack, but it can be a good way to get started.
Understanding the browser is very important, perhaps start with http://www.html5rocks.com/en/tutorials/internals/howbrowsers...
If you are a good coder, javascript can be awesome. Put a lot of time into understanding the language. Don't stray into variants like typescript or coffeescript or elm or anything else till you are pretty happy with js. Prioritize learning ES6 over any variants. The bulk of information on the net and libraries, etc is standard js.
Get a good understanding of webserver, HTTP / Web sockets. Sniff packets and also understand HTTPS.
Invest a lot of time into HTML and CSS, there's a lot of advice on how to build your own CSS frameworks from the ground up, this is really worthwhile. But also spend a bunch of time with something established like bootstrap ( or any other UI framework ) so you can see what problems frameworks are trying to solve.
Language? Frameworks? This is where it gets tricky. I suggest understanding a Node stack, as it's popular, and a lot of examples use it as a backend. It may not be what you actually end up using. Checkout Angular2, React / redux as they are popular javascript frameworks that run in the browser to deliver application like UI. However, go for statically generated pages if you don't need that kind of UI, classic GET/POST delivered webpages still deliver a lot of value.
Security / Authentication - Can be very tricky and in some environments it's left to roll your own
Data - Can be super convoluted, often taught in a web context without much concern for security and authentication (depending on stack). In general avoid having too many layers between your data store and the UI. SQL / NoSQL / BigData Stores are all toys to play with (but each data store tech has its own problems and tradeoffs) and more often are getting mixed together.
Now, because you can pick and choose nearly any aspect of the above, it can become very hackish, especially as new toys are coming along all the time.
If I was going to recommend a single thing to start playing around with? probably meteor. It packages up a lot of modern web things for you, it's all javascript, it uses a mongo back end (which is a json store, not necessarily the greatest choice of DB though), has a easy package system, and supports a number of popular front ends. None of which is how you should choose a production stack, but it can be a good way to get started.
+1 for Meteor. It makes is far, far easier to develop a client-server + mobile web app than any other combination of server-side framework and client libraries. You get web, Android and iOS apps from the same codebase, and direct integration with the largest repository of libraries, https://www.npmjs.com/, with over 300k libraries.
Yes, 300k libraries means a lot of crap one, which is why there's http://npms.io, which searches by code quality + popularity + how well the library is maintained.
Meteor covers security, authentication, database, client-server sync, mobile app generation, but leaves the choice of front-end library to you. It works with Polymer Paper Elements (Material Design for the web), as well as with React.
It's an opinionated platform that makes a lot of choices for you, but has become more and more flexible. You can swap the view layer, and the database layer too (Postgres and MySQL are supported besides the default MongoDB).
More at https://wiki.dandascalescu.com/essays/why_meteor
Yes, 300k libraries means a lot of crap one, which is why there's http://npms.io, which searches by code quality + popularity + how well the library is maintained.
Meteor covers security, authentication, database, client-server sync, mobile app generation, but leaves the choice of front-end library to you. It works with Polymer Paper Elements (Material Design for the web), as well as with React.
It's an opinionated platform that makes a lot of choices for you, but has become more and more flexible. You can swap the view layer, and the database layer too (Postgres and MySQL are supported besides the default MongoDB).
More at https://wiki.dandascalescu.com/essays/why_meteor
It can be OK, but yes.
Yes.
[deleted]
yes
[deleted]
All these dozens of disparate ad-hoc web technologies and defacto standards are built like a tower of babel on quicksand. No one truly understands all of it. Without View Source and a healthy dose of copying/stealing no one could get any of it to function. Yet in spite of all of this - this web thing somehow works. The only takeaway is to not bother trying to grok all of it. It would only lead to madness and missed deadlines. Just try to avoid frameworks that emphasize purity of design over pragmatism and instead use a workflow that gets you to the finish line.
I think you're extremely overselling the complexity of things. Sure, there's a lot of layers and parts involved in making web pages work and in the popular web development ecosystem in general, but they were usually created to solve specific problems, and knowing of them can help you recognize how problems you may run into may be solved. None of them work by magic or are beyond comprehension.
The browser speaks the HTTP protocol to a webserver, and receives primarily HTML. The HTML is styled with CSS and can execute Javascript. Javascript running in a web page uses the DOM (Document Object Model) to interact with the page's HTML.
Javascript bundlers (Browserify, Webpack, etc) let you modularize your code across multiple files and bundle it up into a single output file for browsers to download. Javascript minifiers exist to strip out everything from a Javascript source file that's not strictly necessary to execute it (comments, whitespace, original variable names, etc) in order to make it smaller for download. Various compile-to-javascript systems exist: Babel to let you use upcoming Javascript features, Flow and Typescript to let you use annotations for static typing, emscripten to let you C/C++ on the web, etc.
Like any other popular programming language, there's a healthy ecosystem of libraries for Javascript. There are a lot for algorithms and data structures like any other language, and you also have plenty specifically for adding abstractions to using the DOM. The DOM is definitely usable on its own, but many applications benefit from using abstractions from libraries to interact with the DOM. This isn't very different from the popularity of GUI libraries (Qt, GTK, MFC, wxWidgets, etc) in desktop applications over the raw OS windowing APIs. jQuery provides a fluent API for manipulating sets of elements directly. React provides a system for making modular user interfaces taking some inspiration from functional programming and de-emphasizes manipulating elements.
All of the parts mentioned above were introduced to solve a specific problem. If you understand the problem they were built to solve, then their designs are often intuitive. If you don't currently understand the problem they were built to solve, then (for anything after the 2nd paragraph) you probably haven't hit that problem and often don't need to use them.
The browser speaks the HTTP protocol to a webserver, and receives primarily HTML. The HTML is styled with CSS and can execute Javascript. Javascript running in a web page uses the DOM (Document Object Model) to interact with the page's HTML.
Javascript bundlers (Browserify, Webpack, etc) let you modularize your code across multiple files and bundle it up into a single output file for browsers to download. Javascript minifiers exist to strip out everything from a Javascript source file that's not strictly necessary to execute it (comments, whitespace, original variable names, etc) in order to make it smaller for download. Various compile-to-javascript systems exist: Babel to let you use upcoming Javascript features, Flow and Typescript to let you use annotations for static typing, emscripten to let you C/C++ on the web, etc.
Like any other popular programming language, there's a healthy ecosystem of libraries for Javascript. There are a lot for algorithms and data structures like any other language, and you also have plenty specifically for adding abstractions to using the DOM. The DOM is definitely usable on its own, but many applications benefit from using abstractions from libraries to interact with the DOM. This isn't very different from the popularity of GUI libraries (Qt, GTK, MFC, wxWidgets, etc) in desktop applications over the raw OS windowing APIs. jQuery provides a fluent API for manipulating sets of elements directly. React provides a system for making modular user interfaces taking some inspiration from functional programming and de-emphasizes manipulating elements.
All of the parts mentioned above were introduced to solve a specific problem. If you understand the problem they were built to solve, then their designs are often intuitive. If you don't currently understand the problem they were built to solve, then (for anything after the 2nd paragraph) you probably haven't hit that problem and often don't need to use them.
Thanks for a lesson on how the web works, but I'm already quite familiar with it. Your long answer proves my point about its needless complexity and layer upon layer of historical cruft. Can the complexity be buried under various frameworks and toolkits? Sure, to some extent. But not entirely. Browser inconsistencies always manage to sneak through forcing the developer to learn the entire stack.
If you do know that much, then I'd think painting the ecosystem as beyond understanding seems a little disingenuous! A little sorry for the textwall, it was mainly intended for outsiders considering webdev and got re-purposed into a reply to you.
The cleanest and most efficient methodologies for web development today are largely unpopular.
The people who know how to write efficient websites, web pages, and web software in general are going to be either the people who have been doing it long enough to remember the old ways, or those who wade through enough of today's bullshit to understand how to do things with less code, and faster rendering times.
The people who know how to write efficient websites, web pages, and web software in general are going to be either the people who have been doing it long enough to remember the old ways, or those who wade through enough of today's bullshit to understand how to do things with less code, and faster rendering times.
[deleted]
We are all Windows programmers now.
The web is really just one enormous operating system we're all just hacking on.
But it's only slightly better then this but not as clean as Linux. W3C sort of plays the role of Torvalds
The web is really just one enormous operating system we're all just hacking on.
But it's only slightly better then this but not as clean as Linux. W3C sort of plays the role of Torvalds
It's been ruined by a generation of developers who believe it a good idea to build stateful applications on top of an inherently stateless document-centric infrastructure.
when I glance over your words I hear the sentence you've written in my mind's ear - even though tongues were never made for speaking - we LITERALLY use an organ that is for chewing and swallowing food, and using it to talk with, which we can only do while our mouth isn't doing what it's actually built for, which is to chew and swallow!
And that's what we choose to imitate to communicate with each other? A hack on top of a hack!!! Why should I write something that makes you hear in your mind's ear my chewing organ fashioning air.
Wouldn't it be a lot better to ACTUALLY communicate with you some kind of direct meaning, rather than trying to jury-rig an entire civilization on top of imitations of flapping meat? Plus, the spelling is linked with the meaning anyway, if I had misspelled "meat" as "meet" just now you would have been confused! So why not take away the part where you're hearing this in your mind's ear, and just communicate!
blah blah blah. In other words, it doesn't matter what "INFRASTRUCTURE IS". A two year old's infrastructure for language is a mouth organ that they also eat with. It's OBVIOUSLY a design wart. This is completely obvious.
It also works. Gmail is fine and fun to use, even though as I type a to: field it predicts the address. Not something a stateless document-centric infrastructure was designed to do.
Oh well. It's called progress and civilization. It doesn't matter if it starts with flapping a chewing organ, and then imitating a poor abstraction of that through writing. who cares!
And that's what we choose to imitate to communicate with each other? A hack on top of a hack!!! Why should I write something that makes you hear in your mind's ear my chewing organ fashioning air.
Wouldn't it be a lot better to ACTUALLY communicate with you some kind of direct meaning, rather than trying to jury-rig an entire civilization on top of imitations of flapping meat? Plus, the spelling is linked with the meaning anyway, if I had misspelled "meat" as "meet" just now you would have been confused! So why not take away the part where you're hearing this in your mind's ear, and just communicate!
blah blah blah. In other words, it doesn't matter what "INFRASTRUCTURE IS". A two year old's infrastructure for language is a mouth organ that they also eat with. It's OBVIOUSLY a design wart. This is completely obvious.
It also works. Gmail is fine and fun to use, even though as I type a to: field it predicts the address. Not something a stateless document-centric infrastructure was designed to do.
Oh well. It's called progress and civilization. It doesn't matter if it starts with flapping a chewing organ, and then imitating a poor abstraction of that through writing. who cares!
This is the crux of the matter. Surprised how few of the comments which addresses this.
Just look at how many JS frameworks which have a "router" component. So rather than navigating documents you end up faking that we navigate documents. Wonder why things are getting so hard?
Look at how many have difficulties in distinguishing what REST is supposed to be and RPC. Both have a place - but many look for the "one" solution and ends up using something they call REST in a RPC style.
Just look at how many JS frameworks which have a "router" component. So rather than navigating documents you end up faking that we navigate documents. Wonder why things are getting so hard?
Look at how many have difficulties in distinguishing what REST is supposed to be and RPC. Both have a place - but many look for the "one" solution and ends up using something they call REST in a RPC style.
Just a nitpick, but stateless/stateful are descriptions applied to protocols not applications. The mechanics of persisting application context between request/response events might be contentious and varied in web applications, but just because the protocol is stateless doesn't necessarily mean that your application is more difficult to maintain.
I agree with your point, but it is begging the question: are we overlooking the value/potential that a generation of developers found in the stateless nature of HTTP?
I agree with your point, but it is begging the question: are we overlooking the value/potential that a generation of developers found in the stateless nature of HTTP?
As primarily a back-end developer I am being exposed to some front-end work at the moment with AngularJS/CoffeeScript.
I have to agree with you. I'm not enjoying it at all.
I have to agree with you. I'm not enjoying it at all.
I feel for you. You're being exposed to a framework that is a mess in one of the [most hated languages of 2016][0]
[0]: https://stackoverflow.com/research/developer-survey-2016
[0]: https://stackoverflow.com/research/developer-survey-2016
The most popular back-end language being Javascript makes me sad.
[deleted]
In theory, no.
In practice, yes.
In practice, yes.
Nailed it!
Yes.
Whoa. Betteridge's law doesn't apply here. Weird!
Whoa. Betteridge's law doesn't apply here. Weird!
Lately I've been doing some web development on a fairly long-lived and large code-base, but I'm finding it MUCH harder to wrap my head around than application development ever was. I think my difficulty is that the whole environment feels so... HACKISH... everything is a horrible hack on top of a horrible hack. (yes, I'm familiar with the history, been using the Internet since before the web) I'm not even talking about the fact that everything has to be stateless, in fact I develop desktop apps as stateless even driven UIs as well, but just the fact that it really feels like there's no consistent way to do anything, there are 1000 different frameworks, all with their own way of doing the most basic tasks, and my experience is that they all ... well... suck.
Am I missing something? Is it me resisting change? Is web programming really that bad? Is it really just that I need a new mental paradigm?
Can you recommend any good resources to help me orient my mind to this new way of thinking?