8 ms·

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on wh

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the browser experience on-par with native? How do all these things interact, and what about all the other factors that I'm not smart enough to see, but usually someone on HN points out for me? But no, I never get to read that, just complaints about how the whole community is dumb. Really? That seems unlikely. I don't believe this is pointless tech churn, akin to fashion. It really feels to me, at least, that there is a direction that the tooling is heading. I'm not sure what it is, but I feel like if that's where these conversations were focused (instead of just rejecting the current state of things) we could figure it out. Yeah, it's frustrating as shit, we needed to all be pissed about it for a bit, but let's have a productive conversation.

madeofpalk 11y ago
I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something they think they have to because 'all the cool kids' are. This discussion is often brought up in relation to React/Redux/Babel/Webpack, and people thinking they have to completely master all of them to start making websites, when the reality couldn't be further from the truth. Twitter had an amusing quip of the topic last week: > If you’re feeling overwhelmed by Slack or React (judging by the HN front page this week), I politely suggest you re-evaluate your life. https://twitter.com/iamdevloper/status/707146929075949568 https://twitter.com/iamdevloper/status/707146929075949568
- porker 11y ago
  > I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something 'all the cool kids' are. There may be that. There's also: a) Some of us are old enough to have mortages/kids/parents to support/houses needing renovation/desire a balanced life. We value skills that stay useful, and don't have the free time to keep learning variants of the same again and again* b) Companies we work at/for value stability. They look at IT choices on a 5+year horizon; they don't have VC money to burn to 'rewrite' when JavaScript framework X no longer works. Which am I more likely to get sacked for? 1) Not using the cool thing and us missing out, or 2) using the cool thing and having to explain in 18 months time that we need another $20,000 to rewrite it into the Next Cool Thing? Before you write us off, please do a 360 and see what the field looks like from other perspectives. * I didn't say 'don't have time to learn'. We learn - but what we learn is evaluated carefully, and we have a much wider field to learn (Programming/Management/PM/Negotation - just a few of the core work-focused skills) [Edited for formatting]
  - madeofpalk 11y ago
    Why is everyone so anxious about this? That's the part that confuses me. When we introduced a library for a new project (at a Big Old Media Company with a team varying from interns, to working-70-hours-a-week millennials, to 9-5 family people) it was fine. If someone had something to learn about one of the 5 APIs, they read the entire library documentation (which takes like 20 minutes) or just turned around and asked someone.\ I'm not convinced we found the only developers who like React, but it does seem like there's a certain audience of people (which overlaps heavily with HN) who love to complain about their self-inflicted anxiety.
    - porker 11y ago
      > When we introduced a library for a new project Great, a real data point! From this and previous comments, I'm guessing the library was React? And from another comment on this page, you haven't bolted-on multiple libraries for form handling, routing etc. A few questions: * What is the projected lifetime of the new project? * Will the code be updated continuously (vs write once & freeze)? * What does your ecosystem around React look like? * What library/framework were you using before which you replaced with React? * Have yoiu committed to using React on new projects for the next.. 24 months? It'd be great to learn more, as it sounds like a non-Facebook scale project, i.e. more relevant to most of us... AFAICT no one in this thread is saying they don't like React, or if $Company paid them to learn it they wouldn't (paid learning time, what's not to love?). It's about the pace of change, reinvention, and expectation to use latest and greatest and be future-proof.
      - Klathmon 11y ago
        >expectation to use latest and greatest and be future-proof In javascript (just like in any other programming language) you generally get one or the other. You can have the "cutting edge" features or libraries, or you can stay a bit behind and have one that's stable and will stick around for a while. People are using features of JS that aren't even in the spec yet then getting burnt out when they break in the future? Using a library at version 0.0.3 and getting upset when 2.4.3 breaks something? There is nothing wrong with using mature systems, and that's why I personally feel all of this "javascript fatigue" is self inflicted. If it is going to be a project you write once then don't touch for 5 years, maybe don't use react 0.15.beta-4 as your library of choice...
_pmf_ 11y ago
> Is this a race to make the browser experience on-par with native? Everything points into the opposite direction, unfortunately.
askyourmother 11y ago
A lot of js devs came straight to js without any previous language experience. Hence we are seeing lots of ideas and frameworks thrown out there. The worst example is the proliferation of single function libraries, yes, create a js lib for a single function. It will settle down. Mostly as the devs grow a bit older and wiser, and as the end users start to rebel a bit harder - already non-tech people are publically lamenting js-heavy sites, wondering why so slow to load and run. Lean js is happy js.
- Klathmon 11y ago
  I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them. I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything) Installing that small, well tested, and standards compliant function using a single npm command is significantly better than trying to do it correctly myself (which would most likely take an hour or so just to look over it's exact functional requirements, and it would most likely have subtle bugs), half-ass it and write my own "not quite reduce but close-ish" that i now need to use everywhere and need to train new hires on because "I didn't want to install a 31 line lib, so now you have this non-standard system that's buggy in it's own strange ways", or copy-and-paste the code from somewhere muddying the legal status of my codebase.
  - douche 11y ago
    It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language. Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the churn-rate means that virtually no one will have the exact version of a library that you require pre-cached in their browser.
    - deleted 11y ago
marklgr 11y ago
> I don't believe this is pointless tech churn, akin to fashion. This is not pointless, but it is pretty uncontrolled. Basically, there is a natural tendency for engineers to want and rewrite old stuff, once all the flaws of once-cherished yesteryear solutions are glaring. Normally, engineers don't have a freehand in ditching old projects and rewriting from scratch, so they have to maintain what exists. But with all the startups and the site redesigns, now they can, and they do. Why not--it's fun, it replaces old solutions that showed their limits, and the scope is somewhat limited; it's just a website, after all. Moreover, everyone can jump in and create their foobar.js lib or framework; the core node/JS is pretty easy. > It really feels to me, at least, that there is a direction that the tooling is heading. It is quite uncertain. Progress is made when you build on previous work, but here it is mosly about saying that the old solution doesn't work eventually, so let's do it this way instead. It looks a lot like infinite recursion, with pretty thin state.
- rtpg 11y ago
  Rewriting can pay off in spades very quickly. Just as some examples.... we've moved some pages to vanilla jQuery to Angular and have gained orders of magnitude more stability (read: basically no state-inconsistency bugs in newer pages). If you're faced with vanilla javascript in the DOM and have any amount of complexity to it, then you should be using angular/react, if not for your sanity than for the sanity of the one who will need to maintain your code (read: you in 3 months). If you're knowledgable enough to know that your use-case doesn't work with the newer tools, then more power to you. But the productivity gains from moving away from your jQuery spaghetti code to one of the more managed frameworks is well worth the rewrite time. I don't know much about going from Angular to React, or Backbone to Angular though.... the choice of framework is likely dependent on what kind of user interactions dominate your app and subjective comfort. But if you're careful, you can actually transition apps slowly over to Angular and I assure you, you could get rid of so much of your custom-written (probably not well tested) DOM management code it's not even funny.
  - bphogan 11y ago
    You know, if people approached web programming like actual programming, with layers of abstraction, there wouldn't be spaghetti code in the first place, and one could move to a different framework as needed. But the problem is nobody stays with anything long enough in the web world to learn it well. 5 years ago, Backbone, Then Knockout. Then Angular. Then Ember. Now React. Seriously, a dev with 5 years of experience in JS has literally the same 1 year of experience over and over now. :D
hawski 11y ago
This industry (and most things where many people are involved) is very complex system. There are several different motivations and goals at stake at the same time. I don't know if it is even possible to tell single direction of this system. I studied industrial automation and I see it as a automation system a bit. To make it simple I compare it to i.e. temperature control. There are many things influencing temperature in a room. Yet we want certain temperature in this room. We try to maintain good temperature and "good" can have multiple meanings. But everything in environment changes constantly and even if nothing changes we still have inertia. That illustration probably is not that helpful. What I try to say is that it is probably almost impossible to tell where we are heading. We can recognize some general trends for a while, maybe even few longer term. This is very complex system, we see things as we go. In case of this system if we would commonly start to believe that system is heading in certain direction for sure, because of feedback loop it would change this direction. Maybe what I want to express is just that I think that I should read more on systems and game theory. I didn't have time to make this post shorter, sorry.
aedron 11y ago
> why the ecosystem looks like this It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently. The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alone there was Struts, WebWork, Wicket, Tapestry, JSF, Spring MVC, and countless others, each one sucking more than the other. They are all pretty much dead now because people realized the insanity of trying to build a GUI using a page request based approach. This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser). The attempts to compile down to JS is the best we can currently do, which is why the best and most complex JavaScript applications that have ever been made have been done this way, but obviously a native solution will be the better solution. The best bet would be an intermediate layer, a kind of JVM for the web, on which a thousand languages could run. That is bound to be a long way out though, so we have at least a few more years of pointless JavaScript framework churn.
- Yaggo 11y ago
  > [Javascript] simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser). Electron? Atom? Slack? React Native? Espruino? Also, there are plenty of non-web Node.js applications, e.g. https://github.com/sindresorhus/awesome-nodejs#command-line-apps https://github.com/sindresorhus/awesome-nodejs#command-line-...
  - evook 11y ago
    Wrapping a browser instead of using one directly doesn't make your application run in a non-browser runtime environment. And to be completely honest, probably sacrificing a bit karma. All of your examples enforce my point of view on JS as a 'use it as minimal as necessary' language else avoid it.
cognivore 11y ago
"...but let's have a productive conversation." Okay, I'll bite. With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty? Where does the churn end if it's not pointless? Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly implemented that most everyone tries to abstract it away at some point, and a language that is universally regarded as one of the worst ever. Is that what you build on for the future? Cause then I do see it being pointless tech churn because your fundamental building blocks are too seriously flawed. If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight. If you had such a thing this thread of conversations wouldn't even be happening. I sincerely hope that someone smarter than me comes up with that (yes, Java was a close but no cigar) and we gravitate away from the morass we have now.
- untog 11y ago
  > With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty? Well, WebAssembly is on the way, so you won't have to use JavaScript. WebGL means you could, I guess, skip over the DOM entirely if you wanted to. None of this is fantastic, of course, but it's where we are. Programs that people can download on demand existed, and still exist, yet the web is more popular. It's cross-platform, you don't have to install anything, updates are instant. What cross-platform UI are you going to use to address Windows, Mac, iOS and Android together? To put it more succinctly, the "truth and beauty" for me is that it works, and it works today. I'm far happier iterating on that than noodling around imagining the perfect code execution environment that, as far as I can see, has no hope of existing any time soon.
- mapgrep 11y ago
  I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things, but setting that aside: The web app platform represents one of the largest, if not literally THE largest, explosions of programming and application development ever seen in the history of humankind. It also represents one of the most open and portable computing environments ever developed. It incubated a revolutionary and indispensable app for indexing, searching, and retrieving an unprecedented staggering corpus of human knowledge (Google.com); apps that have enabled hundreds of millions of people to effortlessly publish their writing, videos, pictures, etc globally and instantly (Twitter, YouTube, WordPress, Blogger, etc etc); apps that make it trivial to find most of the people you have ever known and to collapse time and space to communicate with them (Facebook, Gmail, etc etc); apps that enable you to select virtually any product imaginable and have it delivered, usually within 24 hours if needed (Amazon, Ebay, etc etc); not to mention probably millions of other more obscure apps to handle amazingly specific mundanities of office life, travel, entertainment, citizenship, finance, etc etc etc. To look at all this and land on the conclusion that JavaScript and the web stack are fucked up‚— "a language that is universally regarded as one of the worst ever" — period, full stop, EOM, throw them out — seems aggressively contemptuous and beside the point. It's sort of like looking at a raging party filled with some of the most interesting people you've known and some of the most interesting people you've ever heard of and complaining about the type of speakers being used to play the music. I can't speak for the OP but I think that's roughly what they were getting at. (Also, side note, Tim Berners Lee may perhaps have conceived the web as a place for documents, but he also seems to have since then embraced it as an application platform, not that his opinion or original vision should in any way confine what the web becomes. http://venturebeat.com/2013/03/09/tim-berners-lee-sxsw/ http://venturebeat.com/2013/03/09/tim-berners-lee-sxsw/ )
protonfish 11y ago
I don't know how productive this is, but here is my take on this situation that you likely aren't going to hear anywhere else. I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web dev, I can tell you my experience was like turning on the lights after struggling in the dark. Basically what I found is that web app development was designed to work great in specific ways. If you don't know this and try to get it to work in a way that it was never meant to, you're gonna have a bad time. Sadly, every front end framework and many JavaScript libraries fall into this category. They focus on bending the natural web development paradigm into some other form. Which one will "win"? None - there's no right way to do something wrong. The real question is when we will stop falling for the pitch of the snake oil salesmen. I assure you, there is no functionality that any of the frameworks bring that does not already exist and can be implemented in much simpler, maintainable and architecturally sound ways. Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples. Another reason we are inundated with poor frameworks is there is no other good entry point for developers new to web application development. Nobody wants to (or should have to) read the HTTP spec when they just want a simple CRUD app. In summary: the reason these JavaScript frameworks exist is 1) Easy starting point for beginners 2) Make web development more like desktop/OOP/whatever the average developer is used to. There there cannot be a "good" web architecture until one is based on how web development actually works, not how we think it should work.
- ktRolster 11y ago
  Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples. Please do. I am interested in seeing more detail in your post.
- bonif 11y ago
  I would upvote this comment 10 times if possible.
- gglitch 11y ago
  Can you point to any more elaborated examples or write-ups of the kind of html/http work you're describing here? I'd love to learn more.
jayhuang 11y ago
Honestly it's a bit disheartening to see a community with so much insight readily jump to bashing every single "hip new thing" in the browser/JS world, heck, even npm/bower. I think part of it is because of the proliferation of JS in recent years, whereas many people still have this notion of copy/paste Javascript "skiddies". Even among new grads with significantly less experience, I often hear some voicing concerns that "web developers are not real programmers", or there's "nothing hard about front-end work", "CSS is only for designers", or "only people who can't do CS become web developers". On the other hand, yes, new frameworks are appearing every day, and it's obvious this is a huge source of frustration; but we do we need to chase every new framework? Is it actually true that an application written in X framework HAS to be re-written every 2 years instead of a pure jQuery-based application? What is preventing you from continuing to use Angular v1, that you have no choice but to port everything to v2? (also worth noting that you can port only parts of your app to v2 and run them in tandem but I digress) I don't want to start another flame war here (which seems to be a common trend these few days), but how many people do you know that has a deep understanding of the costs of DOM reflows and how to mitigate/minimize them? As a full stack developer who has done quite a bit of front-end work the past few years, I can tell you: not many. Okay, so maybe you say: "For X and Y application that knowledge isn't important." That very well may be the case, but how about those that build richer and more complex interfaces that (maybe) involves thousands or even hundreds of thousands of elements on the page? What then? Has no one ever seen the absolutely abysmal jank and (lack of) performance some JS apps have? Is it really so horrible that we have to bash and nitpick on every single thing someone makes in the web community? Is it wrong for your kid to come home one day, exclaim "look what I drew today!", and show you a horrific picture of you looking like a gorilla? Or maybe it's okay that a lot of people are very working hard to do away with the hairy pain points we have currently, make it harder for you to shoot yourself in the foot, and maybe introduce some (small) pain points of their own inadvertently? Maybe it's possible that we're not all perfect humans with perfect ideas? I'll give a quick example of what it's been like for my experience/or the experience of people I've worked with with jQuery/Angular/React. jQuery: I want to update this element, okay I'll add a class or id as an identifier and query the DOM. Then I'll change the text in here. Oh but now I want to add another element to this list here (but I haven't cached the selector because I haven't learned that yet), let me query that element, create a new element, then append it. Angular: I want to update the text on this element, okay, I'll change it in $scope, or the template directly. I also need to add a list item, okay, let's just .push() the new record in our $scope variable and it'll appear since we already told Angular to iterate on this model. As for DOM updates? Well, I may or may not know it, but Angular is going to update it for me on the next $digest cycle which happens in intervals or can be triggered manually, after doing a dirty check for $scope/$watch. React: Similar to my thought process with Angular, I update the list item in our model with setState, and React will do its virtual DOM diffs and update for me, or maybe it doesn't update because shouldComponentUpdate told it not to. And it only touches the elements necessary on the actual DOM. Perhaps it doesn't seem like a big difference, but after working with all 3, speaking from personal experience: once you have to return to doing pure jQuery, you realize how forced and unnatural everything now feels. Give it five minutes: https://signalvnoise.com/posts/3124-give-it-five-minutes https://signalvnoise.com/posts/3124-give-it-five-minutes

madeofpalk 11y ago

I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something they think they have to because 'all the cool kids' are. This discussion is often brought up in relation to React/Redux/Babel/Webpack, and people thinking they have to completely master all of them to start making websites, when the reality couldn't be further from the truth. Twitter had an amusing quip of the topic last week: > If you’re feeling overwhelmed by Slack or React (judging by the HN front page this week), I politely suggest you re-evaluate your life. https://twitter.com/iamdevloper/status/707146929075949568 https://twitter.com/iamdevloper/status/707146929075949568

porker 11y ago
> I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something 'all the cool kids' are. There may be that. There's also: a) Some of us are old enough to have mortages/kids/parents to support/houses needing renovation/desire a balanced life. We value skills that stay useful, and don't have the free time to keep learning variants of the same again and again* b) Companies we work at/for value stability. They look at IT choices on a 5+year horizon; they don't have VC money to burn to 'rewrite' when JavaScript framework X no longer works. Which am I more likely to get sacked for? 1) Not using the cool thing and us missing out, or 2) using the cool thing and having to explain in 18 months time that we need another $20,000 to rewrite it into the Next Cool Thing? Before you write us off, please do a 360 and see what the field looks like from other perspectives. * I didn't say 'don't have time to learn'. We learn - but what we learn is evaluated carefully, and we have a much wider field to learn (Programming/Management/PM/Negotation - just a few of the core work-focused skills) [Edited for formatting]
- madeofpalk 11y ago
  Why is everyone so anxious about this? That's the part that confuses me. When we introduced a library for a new project (at a Big Old Media Company with a team varying from interns, to working-70-hours-a-week millennials, to 9-5 family people) it was fine. If someone had something to learn about one of the 5 APIs, they read the entire library documentation (which takes like 20 minutes) or just turned around and asked someone.\ I'm not convinced we found the only developers who like React, but it does seem like there's a certain audience of people (which overlaps heavily with HN) who love to complain about their self-inflicted anxiety.
  - porker 11y ago
    > When we introduced a library for a new project Great, a real data point! From this and previous comments, I'm guessing the library was React? And from another comment on this page, you haven't bolted-on multiple libraries for form handling, routing etc. A few questions: * What is the projected lifetime of the new project? * Will the code be updated continuously (vs write once & freeze)? * What does your ecosystem around React look like? * What library/framework were you using before which you replaced with React? * Have yoiu committed to using React on new projects for the next.. 24 months? It'd be great to learn more, as it sounds like a non-Facebook scale project, i.e. more relevant to most of us... AFAICT no one in this thread is saying they don't like React, or if $Company paid them to learn it they wouldn't (paid learning time, what's not to love?). It's about the pace of change, reinvention, and expectation to use latest and greatest and be future-proof.
    - Klathmon 11y ago
      >expectation to use latest and greatest and be future-proof In javascript (just like in any other programming language) you generally get one or the other. You can have the "cutting edge" features or libraries, or you can stay a bit behind and have one that's stable and will stick around for a while. People are using features of JS that aren't even in the spec yet then getting burnt out when they break in the future? Using a library at version 0.0.3 and getting upset when 2.4.3 breaks something? There is nothing wrong with using mature systems, and that's why I personally feel all of this "javascript fatigue" is self inflicted. If it is going to be a project you write once then don't touch for 5 years, maybe don't use react 0.15.beta-4 as your library of choice...

_pmf_ 11y ago

> Is this a race to make the browser experience on-par with native? Everything points into the opposite direction, unfortunately.

askyourmother 11y ago

A lot of js devs came straight to js without any previous language experience. Hence we are seeing lots of ideas and frameworks thrown out there. The worst example is the proliferation of single function libraries, yes, create a js lib for a single function. It will settle down. Mostly as the devs grow a bit older and wiser, and as the end users start to rebel a bit harder - already non-tech people are publically lamenting js-heavy sites, wondering why so slow to load and run. Lean js is happy js.

Klathmon 11y ago
I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them. I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything) Installing that small, well tested, and standards compliant function using a single npm command is significantly better than trying to do it correctly myself (which would most likely take an hour or so just to look over it's exact functional requirements, and it would most likely have subtle bugs), half-ass it and write my own "not quite reduce but close-ish" that i now need to use everywhere and need to train new hires on because "I didn't want to install a 31 line lib, so now you have this non-standard system that's buggy in it's own strange ways", or copy-and-paste the code from somewhere muddying the legal status of my codebase.
- douche 11y ago
  It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language. Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the churn-rate means that virtually no one will have the exact version of a library that you require pre-cached in their browser.
  - deleted 11y ago

marklgr 11y ago

> I don't believe this is pointless tech churn, akin to fashion. This is not pointless, but it is pretty uncontrolled. Basically, there is a natural tendency for engineers to want and rewrite old stuff, once all the flaws of once-cherished yesteryear solutions are glaring. Normally, engineers don't have a freehand in ditching old projects and rewriting from scratch, so they have to maintain what exists. But with all the startups and the site redesigns, now they can, and they do. Why not--it's fun, it replaces old solutions that showed their limits, and the scope is somewhat limited; it's just a website, after all. Moreover, everyone can jump in and create their foobar.js lib or framework; the core node/JS is pretty easy. > It really feels to me, at least, that there is a direction that the tooling is heading. It is quite uncertain. Progress is made when you build on previous work, but here it is mosly about saying that the old solution doesn't work eventually, so let's do it this way instead. It looks a lot like infinite recursion, with pretty thin state.

rtpg 11y ago
Rewriting can pay off in spades very quickly. Just as some examples.... we've moved some pages to vanilla jQuery to Angular and have gained orders of magnitude more stability (read: basically no state-inconsistency bugs in newer pages). If you're faced with vanilla javascript in the DOM and have any amount of complexity to it, then you should be using angular/react, if not for your sanity than for the sanity of the one who will need to maintain your code (read: you in 3 months). If you're knowledgable enough to know that your use-case doesn't work with the newer tools, then more power to you. But the productivity gains from moving away from your jQuery spaghetti code to one of the more managed frameworks is well worth the rewrite time. I don't know much about going from Angular to React, or Backbone to Angular though.... the choice of framework is likely dependent on what kind of user interactions dominate your app and subjective comfort. But if you're careful, you can actually transition apps slowly over to Angular and I assure you, you could get rid of so much of your custom-written (probably not well tested) DOM management code it's not even funny.
- bphogan 11y ago
  You know, if people approached web programming like actual programming, with layers of abstraction, there wouldn't be spaghetti code in the first place, and one could move to a different framework as needed. But the problem is nobody stays with anything long enough in the web world to learn it well. 5 years ago, Backbone, Then Knockout. Then Angular. Then Ember. Now React. Seriously, a dev with 5 years of experience in JS has literally the same 1 year of experience over and over now. :D

hawski 11y ago

This industry (and most things where many people are involved) is very complex system. There are several different motivations and goals at stake at the same time. I don't know if it is even possible to tell single direction of this system. I studied industrial automation and I see it as a automation system a bit. To make it simple I compare it to i.e. temperature control. There are many things influencing temperature in a room. Yet we want certain temperature in this room. We try to maintain good temperature and "good" can have multiple meanings. But everything in environment changes constantly and even if nothing changes we still have inertia. That illustration probably is not that helpful. What I try to say is that it is probably almost impossible to tell where we are heading. We can recognize some general trends for a while, maybe even few longer term. This is very complex system, we see things as we go. In case of this system if we would commonly start to believe that system is heading in certain direction for sure, because of feedback loop it would change this direction. Maybe what I want to express is just that I think that I should read more on systems and game theory. I didn't have time to make this post shorter, sorry.

aedron 11y ago

> why the ecosystem looks like this It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently. The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alone there was Struts, WebWork, Wicket, Tapestry, JSF, Spring MVC, and countless others, each one sucking more than the other. They are all pretty much dead now because people realized the insanity of trying to build a GUI using a page request based approach. This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser). The attempts to compile down to JS is the best we can currently do, which is why the best and most complex JavaScript applications that have ever been made have been done this way, but obviously a native solution will be the better solution. The best bet would be an intermediate layer, a kind of JVM for the web, on which a thousand languages could run. That is bound to be a long way out though, so we have at least a few more years of pointless JavaScript framework churn.

Yaggo 11y ago
> [Javascript] simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser). Electron? Atom? Slack? React Native? Espruino? Also, there are plenty of non-web Node.js applications, e.g. https://github.com/sindresorhus/awesome-nodejs#command-line-apps https://github.com/sindresorhus/awesome-nodejs#command-line-...
- evook 11y ago
  Wrapping a browser instead of using one directly doesn't make your application run in a non-browser runtime environment. And to be completely honest, probably sacrificing a bit karma. All of your examples enforce my point of view on JS as a 'use it as minimal as necessary' language else avoid it.

cognivore 11y ago

"...but let's have a productive conversation." Okay, I'll bite. With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty? Where does the churn end if it's not pointless? Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly implemented that most everyone tries to abstract it away at some point, and a language that is universally regarded as one of the worst ever. Is that what you build on for the future? Cause then I do see it being pointless tech churn because your fundamental building blocks are too seriously flawed. If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight. If you had such a thing this thread of conversations wouldn't even be happening. I sincerely hope that someone smarter than me comes up with that (yes, Java was a close but no cigar) and we gravitate away from the morass we have now.

untog 11y ago
> With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty? Well, WebAssembly is on the way, so you won't have to use JavaScript. WebGL means you could, I guess, skip over the DOM entirely if you wanted to. None of this is fantastic, of course, but it's where we are. Programs that people can download on demand existed, and still exist, yet the web is more popular. It's cross-platform, you don't have to install anything, updates are instant. What cross-platform UI are you going to use to address Windows, Mac, iOS and Android together? To put it more succinctly, the "truth and beauty" for me is that it works, and it works today. I'm far happier iterating on that than noodling around imagining the perfect code execution environment that, as far as I can see, has no hope of existing any time soon.
mapgrep 11y ago
I'm not sure putting down JavaScript, web browsers, and the DOM, and saying the ideal future is completely free of apps built on this platform, is technically being "productive" in a conversation ABOUT those things, but setting that aside: The web app platform represents one of the largest, if not literally THE largest, explosions of programming and application development ever seen in the history of humankind. It also represents one of the most open and portable computing environments ever developed. It incubated a revolutionary and indispensable app for indexing, searching, and retrieving an unprecedented staggering corpus of human knowledge (Google.com); apps that have enabled hundreds of millions of people to effortlessly publish their writing, videos, pictures, etc globally and instantly (Twitter, YouTube, WordPress, Blogger, etc etc); apps that make it trivial to find most of the people you have ever known and to collapse time and space to communicate with them (Facebook, Gmail, etc etc); apps that enable you to select virtually any product imaginable and have it delivered, usually within 24 hours if needed (Amazon, Ebay, etc etc); not to mention probably millions of other more obscure apps to handle amazingly specific mundanities of office life, travel, entertainment, citizenship, finance, etc etc etc. To look at all this and land on the conclusion that JavaScript and the web stack are fucked up‚— "a language that is universally regarded as one of the worst ever" — period, full stop, EOM, throw them out — seems aggressively contemptuous and beside the point. It's sort of like looking at a raging party filled with some of the most interesting people you've known and some of the most interesting people you've ever heard of and complaining about the type of speakers being used to play the music. I can't speak for the OP but I think that's roughly what they were getting at. (Also, side note, Tim Berners Lee may perhaps have conceived the web as a place for documents, but he also seems to have since then embraced it as an application platform, not that his opinion or original vision should in any way confine what the web becomes. http://venturebeat.com/2013/03/09/tim-berners-lee-sxsw/ http://venturebeat.com/2013/03/09/tim-berners-lee-sxsw/ )

protonfish 11y ago

I don't know how productive this is, but here is my take on this situation that you likely aren't going to hear anywhere else. I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web dev, I can tell you my experience was like turning on the lights after struggling in the dark. Basically what I found is that web app development was designed to work great in specific ways. If you don't know this and try to get it to work in a way that it was never meant to, you're gonna have a bad time. Sadly, every front end framework and many JavaScript libraries fall into this category. They focus on bending the natural web development paradigm into some other form. Which one will "win"? None - there's no right way to do something wrong. The real question is when we will stop falling for the pitch of the snake oil salesmen. I assure you, there is no functionality that any of the frameworks bring that does not already exist and can be implemented in much simpler, maintainable and architecturally sound ways. Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples. Another reason we are inundated with poor frameworks is there is no other good entry point for developers new to web application development. Nobody wants to (or should have to) read the HTTP spec when they just want a simple CRUD app. In summary: the reason these JavaScript frameworks exist is 1) Easy starting point for beginners 2) Make web development more like desktop/OOP/whatever the average developer is used to. There there cannot be a "good" web architecture until one is based on how web development actually works, not how we think it should work.

ktRolster 11y ago
Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples. Please do. I am interested in seeing more detail in your post.
bonif 11y ago
I would upvote this comment 10 times if possible.
gglitch 11y ago
Can you point to any more elaborated examples or write-ups of the kind of html/http work you're describing here? I'd love to learn more.

jayhuang 11y ago

Honestly it's a bit disheartening to see a community with so much insight readily jump to bashing every single "hip new thing" in the browser/JS world, heck, even npm/bower. I think part of it is because of the proliferation of JS in recent years, whereas many people still have this notion of copy/paste Javascript "skiddies". Even among new grads with significantly less experience, I often hear some voicing concerns that "web developers are not real programmers", or there's "nothing hard about front-end work", "CSS is only for designers", or "only people who can't do CS become web developers". On the other hand, yes, new frameworks are appearing every day, and it's obvious this is a huge source of frustration; but we do we need to chase every new framework? Is it actually true that an application written in X framework HAS to be re-written every 2 years instead of a pure jQuery-based application? What is preventing you from continuing to use Angular v1, that you have no choice but to port everything to v2? (also worth noting that you can port only parts of your app to v2 and run them in tandem but I digress) I don't want to start another flame war here (which seems to be a common trend these few days), but how many people do you know that has a deep understanding of the costs of DOM reflows and how to mitigate/minimize them? As a full stack developer who has done quite a bit of front-end work the past few years, I can tell you: not many. Okay, so maybe you say: "For X and Y application that knowledge isn't important." That very well may be the case, but how about those that build richer and more complex interfaces that (maybe) involves thousands or even hundreds of thousands of elements on the page? What then? Has no one ever seen the absolutely abysmal jank and (lack of) performance some JS apps have? Is it really so horrible that we have to bash and nitpick on every single thing someone makes in the web community? Is it wrong for your kid to come home one day, exclaim "look what I drew today!", and show you a horrific picture of you looking like a gorilla? Or maybe it's okay that a lot of people are very working hard to do away with the hairy pain points we have currently, make it harder for you to shoot yourself in the foot, and maybe introduce some (small) pain points of their own inadvertently? Maybe it's possible that we're not all perfect humans with perfect ideas? I'll give a quick example of what it's been like for my experience/or the experience of people I've worked with with jQuery/Angular/React. jQuery: I want to update this element, okay I'll add a class or id as an identifier and query the DOM. Then I'll change the text in here. Oh but now I want to add another element to this list here (but I haven't cached the selector because I haven't learned that yet), let me query that element, create a new element, then append it. Angular: I want to update the text on this element, okay, I'll change it in $scope, or the template directly. I also need to add a list item, okay, let's just .push() the new record in our $scope variable and it'll appear since we already told Angular to iterate on this model. As for DOM updates? Well, I may or may not know it, but Angular is going to update it for me on the next $digest cycle which happens in intervals or can be triggered manually, after doing a dirty check for $scope/$watch. React: Similar to my thought process with Angular, I update the list item in our model with setState, and React will do its virtual DOM diffs and update for me, or maybe it doesn't update because shouldComponentUpdate told it not to. And it only touches the elements necessary on the actual DOM. Perhaps it doesn't seem like a big difference, but after working with all 3, speaking from personal experience: once you have to return to doing pure jQuery, you realize how forced and unnatural everything now feels. Give it five minutes: https://signalvnoise.com/posts/3124-give-it-five-minutes https://signalvnoise.com/posts/3124-give-it-five-minutes