14 ms·

I admire your exceptional work cataloguing these resources. However, just one look at that giant horde of links is, to me, a perfect demonstration of why the f

I admire your exceptional work cataloguing these resources. However, just one look at that giant horde of links is, to me, a perfect demonstration of why the front-end development ecosystem is way out of control. Its amazing to me that the autoconf/automake/libtool system for making write-once-run-everywhere *nix applications is downright simple by today's standards. Every year the hot libraries change, the build tools change, the metalanguages, the data formats, even the damn paradigms change. Each generation requires more layers trying to fix up the underlying evil that nobody who soaks themselves in the matter will admit: the browser is a bad app platform and javascript is a bad language. Both have been pressed into serving a purpose for which neither were designed.

acemarke 10y ago
Your comment seems to be a bit of a non-sequitur. Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Would you prefer to build your application using Make, Scons, Waf, CMake, QMake, Tup, Bash scripts, Maven, Gradle, Ant, Buck, or something else? The build tool question is _totally_ solved, right? :) Yes, the JS community has been reinventing a number of wheels. Yes, the browser environment and JS standard lib have weaknesses. On the other hand, it's also allowed developers to build useful applications that are immediately distributable to pretty much anyone who has an internet connection.
- nightski 10y ago
  The benefits you acknowledge (distribution) are not because of the tech but in spite of it. At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative. That alternative could be distributed to a large percentage of desktops in a relatively quick manner saving billions if not trillions of dollars in wasted productivity. It will never happen though. * EDIT: This comes from someone who uses React, Redux, webpack, etc.. daily
  - goldbeck 10y ago
    If this is such a good and valuable idea, why will it never happen? Seems the major internet-interface makers (Google via Chrome, FB via their app, for ex), are vying for control over the way people develop web applications too. Making an alternative that gets adopted would be invaluable to them.
    - jpk 10y ago
      It won't happen because none of them will implement the other guy's new thing. Chrome would do the Google thing, Edge would do the Microsoft thing, and Firefox would sit back and balk that none of that junk is standardized. Then webdevs would just stick with Javascript and friends because it's the only thing that mostly works everywhere. That's exactly what happened to Dart, right? It had aspirations of hopping into Chrome along side JS but who else was going to put it in their browser? Now it's just another thing that compiles to Javascript because that's the only way you'd get anybody to adopt it.
      - tannhaeuser 10y ago
        You could also see it the other way around. That we've come pretty far with standardization based on JavaScript and HTML5 (and CSS and SQL and POSIX and IP ...). What do you expect exactly?
      - jfoutz 10y ago
        Mozilla is probably in the best position to do something. If it's good enough to get developers to switch and rave about it, ms and google will follow to keep mindshare.
        tannhaeuser 10y ago
        JavaScript was invented by Netscape, the predecessor of Mozilla. Also Firefox came out in a phase of browser stagnation, but Chrome in particular and the other browsers are so powerful today that I'm more worried we're going to loose web standards to "whatever WebKit does". So I wouln't hold my breath.
- camus2 10y ago
  > Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipelines easier. Let's take Java for instance, groovy, maven and war packaging considerably made Java server development easier. Java frameworks like Spring are trying very hard to make servlet development easier, by making complexity opt-in. Java is getting constructs like modules which will help with library development, C++ too, QT is streamlining its API ... So I'd totally disagree about your statement. The success of Go yet another proof of this. People are tired with unnecessary complexity and are ready to give up on "elegance" for the sake of simplicity.
  - acemarke 10y ago
    And the Javascript world has gotten a defined syntax for modules, package managers, and build tools that implement build pipelines, compilation, and linking. Same concepts, new language and environment. My point is that building complex software inherently involves _some_ amount of complexity on the development side, which is reflected in the language syntax and tooling used with that language. Now that people are building complex apps in Javascript, we're seeing catch-up in the tools used to build Javascript apps to match the tools that have existed for years on the desktop/native side.
    - deleted 10y ago
      [deleted]
  - mentat 10y ago
    The word Java and "simple development" is just absurd for any real application much less most enterprise applications.
    - Turbots 10y ago
      Omfg seriously? It's been the most widely used programming language for enterprise applications for the last 5 years.. Have you ever done Java development?
- EugeneOZ 10y ago
  Rust, PHP had simple af builds/packaging. So no, not everything is complex, just old dinosaurs AND web.
  - eropple 10y ago
    PHP's packaging was only "simple af" until you had a binary dependency that wasn't part of your operating system. Complicated things exist.
    - objectified 10y ago
      But now you're hitting on one of the main points that was always criticized in PHP: the fact that it came with a lot of batteries included. The upside of this is that it makes PHP applications very easy to deploy, because often, you either don't need to resort to binary dependencies outside the realms of your OS's packaging system, or there will be a `php[major-version]-[library_binding]` package for your OS probably already in your OS's official package mirrors. Say all you want about PHP, but of all the application stacks I've had to deploy, PHP was and is probably still the simplest. The advantage of that shouldn't be underestimated. The only serious competitor in that space that I've ever touched is probably Go.
    - fredsted 10y ago
      Doesn't composer do that? Ie. https://packagist.org/packages/anam/phantomjs-linux-x86-binary https://packagist.org/packages/anam/phantomjs-linux-x86-bina...
    - EugeneOZ 10y ago
      Yeah, you can recompile PHP 2-3 times per year, and it's just long line of args, nothing more. And you can compare it with every-time compilation of modern js apps. What an equation! And you forgot to mention Rust, but let's pretend it's normal way of arguing.
  - mattnewton 10y ago
    I would never want to use php's "just recompile it with the new dependencies" approach ever again. It's a complete mess as soon as you go off the rails of what's included by default.
- kuschku 10y ago
  > Would you prefer to build your application using Make, Scons, Waf, CMake, QMake, Tup, Bash scripts, Maven, Gradle, Ant, Buck, or something else? The build tool question is _totally_ solved, right? :) Yes. I've worked with CMake, Gradle, Maven, Ant, with webpack, makefiles, and the entire rest. And you know what? I went back to ES5, just because it's easier than fighting the JS environment. Comparing your average build.gradle with a webpack config is downright insane. Why does the web environment have to be so much more complicated than the native world? The web could be so much more powerful if they'd study history, and learn from it.
  - BigJono 10y ago
    With what webpack config though? Half the problem with the web stack is inexperienced people making things way more complicated than they need to be. A minimal webpack.config is pretty damn simple.
- _pmf_ 10y ago
  > Qt is big and complicated. I'd encourage every developer considering Electron to give Qt/QML a try. It merges the declarative nature of WPF with a nicer syntax and the ability to use JS directly in the QML file, obliterating the need for converters of formatters (that plague XAML/WPF and JavaFX). Writing custom components is trivial and intuitive, with zero syntactic overhead (if a QML file "MyCompX" is present, you can instantiate its contents with "MyCompX" without any additional setup). For Android, it has the advantage of being able to hot-reload the UI without jumping through hoops (simply serve them over HTTP and install a small reload handler in your app that can be triggered either from the app of by something like a UDP message from the host). (Change one like in the app's main and you are able to pull the QML files from a local directory so you can modify them on the tablet without a PC or internet connection ...) I'm actually reluctant to mention Qt/QML because I consider it to be my secret magic silver bullet for portable (non-web) UI development. Regarding the license (there's a lot of misinformation, including Qt's main site trying to coerce you into using the commercial license): if you link dynamically, commercial usage is not a problem (LGPL). (This is usually only an issue on iOS.) The recent Electron situation (needed on one hand, loathed on the other hand) is a unique opportunity for Qt to gain (back) some developer mind share, but to avoid alienating web developers with scary C++ stuff it would help to decouple QtCreator from the Qt C++ API: offering a version that only exposes the QML editor and interface generator, and ships qmlscene as execution runtime and an option to deploy the QML-only application with a rebranded qmlscene (embedding the QML resources and a custom icon). To be clear: this all exists right now, but with the C++ part enabled (which will scare off some developers even if they can create applications without it).
  - fauigerzigerk 10y ago
    >The recent Electron situation (needed on one hand, loathed on the other hand) is a unique opportunity for Qt to gain (back) some developer mind share, but to avoid alienating web developers with scary C++ stuff it would help to decouple QtCreator from the Qt C++ API For me it's exactly the other way around. If I'm using Qt it's because I want to use C++ to make my app as efficient as possible in terms of CPU and memory usage. Now that JavaScript is in the picture, I'm less likely to consider Qt for a cross platform app because I can just as well use any of the other more popular options like Electron or ReactNative. Qt used to be a C++ GUI framework. Rebranding it as something else won't work. They won't get the web crowd and they will alienate people who want to avoid web technology.
- austincheney 10y ago
  The most disappointing part of all of this is that in the JS environment no build step is required, but it is often there anyways...
  - oatmealsnap 10y ago
    What do you mean? Are you referring to gulp and other similar tools?
    - austincheney 10y ago
      I am referring to any build step. Do you need a build step to execute JS?
colordrops 10y ago
I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem. The situation has already changed years ago. We aren't going to get off of your lawn while you continue to beat a dead horse. The web is built on open standards and there are billions of pages and apps out there. To expect web development to be a perfect monoculture is a failure of your imagination and ability to adapt rather than a failure of the ecosystem.
- johnwheeler 10y ago
  People wouldn't complain about it so much if it didn't suck.
- paganel 10y ago
  Not the OP, but I expect the web to be a thing where documents (i.e. mainly text) don't have any issues rendering on my 5-year old phone or on my 8-year laptop (both of which work very well, still, and which I don't plan to replace anytime soon). The recent web practices (I'm talking mostly of the last 2-3 years, since more and more people have started copying Twitter with its launch of its "every website needs to be a JS-app" thingie) have practically destroyed how most of the websites are displayed by the 2 devices I own. Sites like Hacker News or Wikipedia, which still work perfectly fine, are very far and few between. I sincerely deplore this.
  - deleted 10y ago
    [deleted]
  - ng12 10y ago
    Well what's unique about HN and Wikipedia? They're largely non-monezited. If Buzzfeed can make more money off of a flashy website it's hard to argue with.
    - shortstuffsushi 10y ago
      I don't think it's either/or. You can make a "flashy" (in the sense of Buzzfeed) without it being burdened by huge amounts of js. Likewise, monetized sites are still frequently not like Wikipedia or HN.
droopyEyelids 10y ago
I'm reading some negativity into your take. I see an incredibly complicated problem space- presentation of multimedia content and execution of code on billions of 'fragmented' devices over which the content creator has no control- and the minds of humanity iterating on approaches to the problem.
ng12 10y ago
> the browser is a bad app platform and javascript is a bad language Yeah, and we're finally making real progress towards making it better. I used to do web development because nobody else wanted to, now I do because it's really fun. This is a forum for hackers -- we should be excited about the unsolved problems instead of complaining that things are changing.
- kerkeslager 10y ago
  I'm not complaining that things are changing, I'm complaining that things are changing for the worse.
  - ng12 10y ago
    And you are totally wrong about that. This is the most exciting time to be a web developer since jQuery first came out. I promise it only looks that way from the outside.
    - kerkeslager 10y ago
      I am very much not looking at it from the outside. ES6 is a step backward. Prototypical inheritance was one of the few things Javascript had going for it, but because CS majors who only learned Java in undergrad couldn't be bothered to learn prototypical inheritance now we have two incompatible inheritance systems instead. Promises are minor syntactic sugar over callbacks which could be implemented as a library. Meanwhile `this` still doesn't mean "this", there's still no integer or boolean types, accessing a nonexistent variable silently fails but happily continues execution, only reporting an error when it's far away from the problem. There's no threading, no security primitives, and no decent debugger. None of the problems are being fixed and the new features are either lackluster or make things worse. And that's just the language itself. The ecosystem is in more of a shambles. Web development in the age of left-pad and global shared state being normal is exciting in the same sense as plagues of frogs and locusts are exciting: it's not boring but if it were boring that would be better.
      - 10y ago
kccqzy 10y ago
It's quite possible to use react with nothing else: no build tools, no transpilers, no fancy JSX, so in terms of tooling complexity, it can be as simple as you want or as complex as you want. Regarding the complexity of the underlying system, I think this is not a concern of the typical frontend developer. It has nothing to do with JavaScript or the web. If you are writing a "simple" C program on Linux, would you be concerned about the complexity of the underlying C library (yes glibc is rather big and complex) or the Linux kernel? You won't. This is the point of abstractions. If you want, you don't have to learn about any of these; treat the implementation as a black box and start writing actual frontend code.
- adventist 10y ago
  Any resources you can provide about how to use React without JSX? JSX is a blocker for me.
  - kccqzy 10y ago
    > JSX is not a requirement for using React. Using React without JSX is especially convenient when you don't want to set up compilation in your build environment. > Each JSX element is just syntactic sugar for calling React.createElement(component, props, ...children). So, anything you can do with JSX can also be done with just plain JavaScript. Source: https://facebook.github.io/react/docs/react-without-jsx.html https://facebook.github.io/react/docs/react-without-jsx.html
  - ng12 10y ago
    It's basically just to use the React.createElement API that JSX transpiles to. I say give JSX a chance though.
    - tdfx 10y ago
      I had an initial negative reaction to JSX, as well. It grows on you, though.
  - acemarke 10y ago
    Sure. At the bare minimum, you write "manual" `React.createElement()` calls. To simplify or shorten things, you can alias `React.createElement()` to something like `h()`. There's also a variety of libs to help with that process. We have an existing ES5/Backbone app that's built with Require.js, and we don't have a "compile" step in there. We just added our first couple React+Redux-based features into that codebase, but can't use JSX due to that lack of compilation. I opted to bring in https://github.com/Jador/react-hyperscript-helpers https://github.com/Jador/react-hyperscript-helpers as an alternative to JSX. Not perfect, but it's a suitable alternative given our limitations. There's several other "virtual DOM/hyperscript"-ish packages out there as well.
melq 10y ago
Why is an active ecosystem with healthy competition a bad thing? Personally, I can't stand javascript, and why you'd ever elect to use it for backend/server side code mystifies me. So I don't use it (or work in web development), and couldn't care less about what platform the hip web devs deem acceptable.
- user5994461 10y ago
  healthy competition is robust and tested. A short fade that's gonna be abandoned within a year or so doesn't quality as healthy competition.
- mod 10y ago
  I mostly agree, however it does seem to make some sense to dive deep into one ecosystem, instead of learning & keeping up with two. (Let's not pretend that Javascript is the only one advancing--Django of a few years ago is not compatible with Django of today, as one other example). I have always used python/ruby on the backend, and I prefer them, but I recently worked on a couple of javascript backend projects, and I found one abhorrent and the other quite pleasant. As could probably be expected, the practices used to develop the latter were just better. (These were even done by the same developers, in large part, and the differences were mainly lessons learned). Anyway, if you're already working in a javascript-heavy front-end like React, it doesn't seem like such a stretch to use it on the backend, too.
  - frankpf 10y ago
    Would you mind elaborating on some of those practices (specifically, the problems that made working on the first codebase abhorrent)?
user5994461 10y ago
Let's advocate the other extreme. Get back to mainframe and Cobol. No more fuckups dealing with endless changes. No more need to deal with youngsters and their framework of the year. Of course, it comes with its own issues, but you'll be blind to them for the first few years while you enjoy the cure of stability :D
- kerkeslager 10y ago
  Or, you know, let's advocate reasonable positions and not pretend that the only alternative to Javascript is Cobol.
braveo 10y ago
I was having a similar discussion just today. I was told I should be using swagger, and upon learning more about I started asking why they didn't just build tooling around WSDL. I couldn't see anything enabled by Swagger that isn't enabled by WSDL. About the only thing I could think of was simplicity due to it being more specialized than WSDL. I was told javascript can consume swagger easier, which may be true, but I don't know why that's a significant problem with WSDL seeing as how you could autogenerate the javascript interfaces anyway. I still can't really wrap my head around what problem Swagger is solving that wasn't already solved by WSDL.
- lobster_johnson 10y ago
  The problem with WSDL, at least at its inception, was that it tied in with the whole WS-* extravaganza, a set of standards that are built on top of each other and heavily based on XML. While WSDL has evolved to support RESTful services, early WSDL was closely tied to SOAP. The XML thing is slippery slope. Suddenly your toolchain has to be aware of namespaces, XSD schemas, and so on. It's a largeish universe of a standards that sound good on paper but don't contribute meaningfully to anyone's productivity. And XML has historically been (and still is) popular with the enterprise Java crowd — J2EE, Spring and so on — there's a pretty steep divide between that and the more agile world of web devs and startups. If you're buying into the XML stack, WSDL will seem like a nuisance more than a productivity multiplier. That said, I don't think Swagger/OpenAPI is very good, either. It's replacing XML with YAML, and introducing its own set of issues. And the community and tooling ecosystem aren't quite there.
  - braveo 10y ago
    The question I posed in the discussion is why they didn't extend WSDL instead of trying to rebuild the entire ecosystem by creating Swagger. To me the XML/JSON thing is a non-issue. I've never really gotten the unreadability of XML argument given a decent prettifier (which also applies to JSON), especially for something like a web service description. I guess my thing is, we already have a web service description language, it's called WSDL, and it's already been extended to support REST, why not extend it to support whatever use case you have, or build the tooling around it to support said use case? You could have easily built the Swagger Spec to spit out WSDL instead of JSON. It means you would have been able to lean on the existing tools that can swallow a WSDL file instead of having to recreate the entire ecosystem yourself. What I kept getting back was "JSON > XML" and to me that's just a non-issue. It's so far down the list of what's important that I can't imagine making the decision to try and recreate all the tooling around WSDL for it. And I guess I've never really had your experience with WSDL because I've never been forced to be aware of namespacing issues any further into my system than the edges. Perhaps I've been lucky, but I've been using WSDL for years to ease integrating into web services and I've never stopped and thought to myself that it would be better in JSON with a YAML spec. And I rarely deal with SOAP nowadays, and when I do, I just use a library to swallow the WSDL and do the right thing. I guess that's really where I'm coming from. It smacks of religion to me.
Tloewald 10y ago
It's funny how using a bad language and bad platform I can put together a robust, networked, maintainable, cross-platforn application faster than I could with any prior set of tools. Weird. And, by the way, I'm not defending react.
dntrkv 10y ago
Browsers and JavaScript are what we have, we can't magically replace every browser and JS implementation in the world. We have to figure out where we want to go and slowly get there. That is exactly what is happening in the frontend world and that is why there is so much churn. Browser apps have to work across 4 major browsers with versions going back almost 10 years, an infinite amount of screen sizes, and a near infinite amount of devices. There is no other platform with the capabilities of the browser that has this much reach. If we had the ability to start from scratch and build the ultimate web platform, yes, it would probably be way better than what we have, but we don't have that ability nor will we ever have it, so talking about it is a waste of time. We need to look at our current capabilities, where we want to be in the future, and iterate until we get there. All of the tooling we have serves a purpose and solves a problem, it's not like frontend devs are adding tooling for the fuck of it. Take a common stack nowadays: React, Redux, Webpack, Babel, Eslint, Yarn, Styled Components Every single one of those tools in the stack make my life easier. I don't have to use all of them. In fact, there was a time where I didn't, but I would never want to go back to that time because these tools allow me to build way more complex apps way faster than I used to. And the other great thing about these tools is you can add/remove them as needed. Take something like browser prefixes, as browser support for certain prefixes or features are implemented at a large enough scale, the tooling for that becomes obsolete and you drop it. And as far as JavaScript goes, pre ES6 I would agree, it sucked. Post-ES6, I will have to disagree. I love writing JS nowadays.
- segphault 10y ago
  > And the other great thing about these tools is you can add/remove them as needed. In order to get that freedom, you need to build the tooling in such a way that it aligns with the web standards, so that when the standards catch up you can drop what you don't actually need anymore. We all switched from coffescript to ES6 and Babel because ES6, being standards-based, will eventually be supported in browsers, right? And yet, with JSX we have a gratuitously non-standard dialect of JavaScript that isn't on the standards track and will never be natively supported in browsers. So, even when browsers catch up and offer full support for modern ES6 syntax, we're still stuck with transpilers because Facebook thought it was a good idea to tightly couple their custom templating language to JavaScript itself instead of wrapping it in template literals, which is the standards-based approach that ES6 actually provides for embedded DSLs and templating. Today, in Europe and North America, roughly ~85% of users run a browser version that has native ES6 support. IE marketshare fell off a cliff in 2016, and now IE11 is at less than five percent and still falling. I don't actually need to transpile during development today, and I won't need to do it in production either in a year or two, and yet everything written with JSX will need a transpiler forever.
banachtarski 10y ago
> However, just one look at that giant horde of links is, to me, a perfect demonstration of why the front-end development ecosystem is way out of control. This has got to be the biggest jump to a conclusion I've seen in HN comments this year, without a close second. Sincerely, C programmer who thinks there still something to be learned from some of the architectural underpinnings of a library like React.
venture_lol 10y ago
That's because noone really, truly, honestly want to RTFM of a given stack, library, etc. It's more fun to roll your own or to pick up a new one. I mean, in how may ways can you organize code that manipulate a DOM tree, pull data, massage data, and update the DOM tree? Well, the more the merrier :)
- jacquesm 10y ago
  I fear that this comment embodies more than a little bit of truth.
batmansmk 10y ago
Good troll. Ask your users to install your app and qualify as extra features (with associated budget) the capabilities of bookmarking, sharing urls, having multiple tabs, "remember me" and forms autocomplete, going back, having a history, or auto-update. Justify it to them it's because their browser is a bad frontend platform. Like this horrible, horrible mobile twitter lite ;). In my first year of programming, html was such a joy to use compared to gcc. Could get a button with a background color and an image displayed under 2min. Just saying.
- NoGravitas 10y ago
  The web is a great platform, and so are browsers. JS apps running in the browser? Not so much. How many of those features you list are routinely broken by SPAs? Bookmarking and sharing URLs? Almost always. Going back and having a history? Often. Having multiple tabs, and forms autocomplete? Sometimes. I hate web development mainly because I love the web so much.
austincheney 10y ago
> a perfect demonstration of why the front-end development ecosystem is way out of control. The answer to this is simple but horribly disappointing. In the military we describe this behavior as "justifying your existence". There are three separate causes to this problem. First, solving valid problems is hard in any environment. Dicking around with tooling and configuration is easy. This includes frameworks, abstraction libraries, and so forth. Real problems are often tied to products, services, or end-user problems (opposed to these invented developer problems). Second, writing open source software takes initiative and discipline. It is easier to have the energy for hard problems when people are telling you what to work on and you are getting paid. In this case failing to complete the hard problems bring retribution and eventually termination. When you are on your own or volunteering your time you have to really want it, which completely compounds the first point. Third, there is a low barrier to entry to do front-end work. You can copy paste some code from the internet into your browser console and watch it do stuff. You don't need a compiler, special environment to get started, or any kind of fancy software. This problem is compounded in the legacy corporate world where web technologies are still viewed as inferior child's play for incompetent weak-minded children. After all real developers write ALL of their web related code in Java 6 (sarcasm).
- russdpale 10y ago
  So true.. At my fortune 50 company we force ie to render in ie7 engine for our internal reporting. Yes, that ie7...
sharun 10y ago
It's like the Engineering teams at Google and Facebook have never heard of Microsoft or Sun or Adobe. There are so many lessons (learnt the hard way) in the evolution of .NET, Java and Flash that these guys seem to be completely oblivious too. Google, Facebook devs please go spend some time with the language and platform greybeards at Microsoft. EDIT: Feels like Software Engineering needs a set of Software History textbooks to keep reminding us of what has already been built.
- chillacy 10y ago
  Any specific examples? Nodejs seems like it's managed to avoid the early java mistakes of XML everywhere and one-thread-per-request servers.
- axiomabsolute 10y ago
  To be fair, I'm pretty sure some of the engineers at Google and Facebook have spent some time with the language and platform graybeards at Microsoft, Sun, or Adobe. Some of them are those "graybeards" (in quotes, because they don't literally have gray beards). [1] [1] : https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer) https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
amptorn 10y ago
> Every year the hot libraries change Front-end development is fashion.
fenomas 10y ago
And thus, yet another insipid "hey let's argue about JS fatigue!" comment clobbers another HN comment page, with 100+ replies not one of which has anything to do with TFA.
- monkmartinez 10y ago
  If it wasn't a problem, it wouldn't be upvoted. That is how voting works. I'm not a JavaScript programmer, although I have dabbled extensively in the past. My impression of this thread is that not much has changed in that world. Sencha, titanium, and Phonegap were super hot back in the day, along with jQuery, SproutCore, Knockout and Backbone. Now it is all different for JS. That fuckng sucks.
  - ng12 10y ago
    It's such a dumb argument that boils down to "things are changing and I don't like it!". Javascript fatigue is not real. I am completely convinced anyone who says otherwise has never had to maintain a non-trivial web application in Backbone/jQuery -- meaning they're complaining about frameworks that weren't built for their use cases.
    - douche 10y ago
      Javascript fatigue is real. Shit in front-end land changes so fast it is impossible to keep up with. We just finished a rewrite from jQuery to Angular 1, with updates to all the tooling that goes along with it. We're now at least three years behind the curve... Hooray! Meanwhile, the backend frameworks we've been using have had one minor version Nuget package release in the same timespan.
      - ng12 10y ago
        Angular 1 is 7 years old. And guess what? It's still a perfectly valid framework to build a web application with. There is no "curve".
        10y ago
joelhooks 10y ago
React has been "the yearly hot library" since 2013 for anybody counting along.
j_s 10y ago
Old school devs and those who prefer to invest the bulk of their effort on the backend might be delighted to discover Intercooler.js https://news.ycombinator.com/item?id=12885980 https://news.ycombinator.com/item?id=12885980
altern8tif 10y ago
So much negativity here. Constantly pushing the boundaries of existing technology is how we got here in the first place. If we were content with the status quo, we'd still be looking at a four-month journey from New York to San Francisco on horseback.
- hiram112 10y ago
  No it's more like we've got a 2 month journey on the Hindenburg.
- pbreit 10y ago
  Ironic analogy. Because what used to take a day in Rails now takes a week in [pick your back-end]/[pick your JS frontend].
weq 10y ago
amen. I rolled a angular app 3 years ago, and now most of the libs i used are unsupported, and impossible to upgrade anything cause of dependency hell. now we dont use yeoman to create react apps, and we have a thousand start kits that get u off the ground. your node_modules directory probably has 30k+ plus files before a single line of your app is written. yarn just imagine ur an embedded programmer, and you boss asks u to write a hello world for the nexet device, and u come back with a react app with 30,000 dependencies to get the job done. then u find a bug, which fb just fixed in the next release. But u cant upgrade to the latest version, because that conflicts with library that is used by a 3rd level dep, that is used to add padding to a smiley somewhere.
vrde 10y ago
The thing that backend devs don't realize is that frontend is not easy. A frontend dev builds something that will be used by a HUMAN, while a backend dev builds something that will be used by a PROGRAM. Related to the comment, things were changing a lot because there is not one single way to do things, as in iOS/Android. There is no standard imposed by a huge private company like Apple or Google. Everyone is free to reinvent the wheel. Facebook did something super valuable, that is ReactJS, and this is becoming the _de facto standard_. ReactJS is simple, opinionated, and supported by a large corporation. Thanks to ReactJS a new ecosystem was born, and now finally you have many projects gravitating around it, and this is good. It's just a matter of time IMO. I strongly disagree with _"the browser is a bad app platform and javascript is a bad language"_. JavaScript has its quirks, but it's also really plesant to work with if you don't do weird shit like `isNaN('wft' - 1) // it's true`. The browser is a great virtual machine that is democratizing the web. If you are doing things right, you can have graceful degradation (it degrade gracefully to a lower level of user in experience in older browsers) to increase the audience of your web app, from the dev in SF with gigabit internet to someone living in a rural area in a not so tech advanced country. This of course has a cost, that is spending time developing your app.
- wccrawford 10y ago
  As a fullstack dev, it amuses me when my underlings claim that backend is hard and they want to learn it. They're already doing front-end. (And yes, we're working them towards more and more backend, and even mobile.) It's just different, IMO. Programming is programming, but different specialties have different things you need to worry about.
  - H1Supreme 10y ago
    Absolutely. I've been doing "frontend" work before it was even a term (ie. html tables for layout), and it's still the #1 thorn in my side. Even with all the tools available, developing a functional, aesthetically pleasing GUI is not an easy task. Plus, organizing your code so it's not a 15-nested-div mess with inline CSS just to make the damn thing look right. It's probably why most of my personal projects have a CLI, and that's it.
whostolemyhat 10y ago
Would you rather have less documentation and fewer tutorials? I wouldn't call four links about a new library excessive.
ThePhysicist 10y ago
There's no need to actually use all these complex tools if you don't want to. We wrote a pretty large (>20kloc) React application with a simple require.js based build flow using a Makefile that invokes a couple of tools for bundling the JS and generating assets like CSS. We used our own resource loader framework based on jquery (Redux didn't exist at the time) and a simple routing library (director.js). Still works like a charm! In my opinion, the important thing in frontend development is to know which tools and libraries to adopt and which ones to ignore. As a platform, I find JS+HTML5 really appealing and I'm happy that there are many ways to use and creatively remix these technologies, so I don't see the large churn in the ecosystem as a disadvantage but rather as proof that browser-based JS works very well as a platform to develop applications on.

acemarke 10y ago

Your comment seems to be a bit of a non-sequitur. Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Would you prefer to build your application using Make, Scons, Waf, CMake, QMake, Tup, Bash scripts, Maven, Gradle, Ant, Buck, or something else? The build tool question is _totally_ solved, right? :) Yes, the JS community has been reinventing a number of wheels. Yes, the browser environment and JS standard lib have weaknesses. On the other hand, it's also allowed developers to build useful applications that are immediately distributable to pretty much anyone who has an internet connection.

nightski 10y ago
The benefits you acknowledge (distribution) are not because of the tech but in spite of it. At the end of the day all it would take is one of the 3 major browser vendors to offer an alternative. That alternative could be distributed to a large percentage of desktops in a relatively quick manner saving billions if not trillions of dollars in wasted productivity. It will never happen though. * EDIT: This comes from someone who uses React, Redux, webpack, etc.. daily
- goldbeck 10y ago
  If this is such a good and valuable idea, why will it never happen? Seems the major internet-interface makers (Google via Chrome, FB via their app, for ex), are vying for control over the way people develop web applications too. Making an alternative that gets adopted would be invaluable to them.
  - jpk 10y ago
    It won't happen because none of them will implement the other guy's new thing. Chrome would do the Google thing, Edge would do the Microsoft thing, and Firefox would sit back and balk that none of that junk is standardized. Then webdevs would just stick with Javascript and friends because it's the only thing that mostly works everywhere. That's exactly what happened to Dart, right? It had aspirations of hopping into Chrome along side JS but who else was going to put it in their browser? Now it's just another thing that compiles to Javascript because that's the only way you'd get anybody to adopt it.
    - tannhaeuser 10y ago
      You could also see it the other way around. That we've come pretty far with standardization based on JavaScript and HTML5 (and CSS and SQL and POSIX and IP ...). What do you expect exactly?
    - jfoutz 10y ago
      Mozilla is probably in the best position to do something. If it's good enough to get developers to switch and rave about it, ms and google will follow to keep mindshare.
      - tannhaeuser 10y ago
        JavaScript was invented by Netscape, the predecessor of Mozilla. Also Firefox came out in a phase of browser stagnation, but Chrome in particular and the other browsers are so powerful today that I'm more worried we're going to loose web standards to "whatever WebKit does". So I wouln't hold my breath.
camus2 10y ago
> Application development is complex, period. Posix development is complicated. Qt is big and complicated. Makefiles are complicated. Autotools is complicated. Big Java server apps are complicated. C++ is complicated. We've just hit the point where people are trying to do the same thing in a browser. Actually, Java, C++,QT and co are going through great length to make development simpler and all the compilation pipelines easier. Let's take Java for instance, groovy, maven and war packaging considerably made Java server development easier. Java frameworks like Spring are trying very hard to make servlet development easier, by making complexity opt-in. Java is getting constructs like modules which will help with library development, C++ too, QT is streamlining its API ... So I'd totally disagree about your statement. The success of Go yet another proof of this. People are tired with unnecessary complexity and are ready to give up on "elegance" for the sake of simplicity.
- acemarke 10y ago
  And the Javascript world has gotten a defined syntax for modules, package managers, and build tools that implement build pipelines, compilation, and linking. Same concepts, new language and environment. My point is that building complex software inherently involves _some_ amount of complexity on the development side, which is reflected in the language syntax and tooling used with that language. Now that people are building complex apps in Javascript, we're seeing catch-up in the tools used to build Javascript apps to match the tools that have existed for years on the desktop/native side.
  - deleted 10y ago
    [deleted]
- mentat 10y ago
  The word Java and "simple development" is just absurd for any real application much less most enterprise applications.
  - Turbots 10y ago
    Omfg seriously? It's been the most widely used programming language for enterprise applications for the last 5 years.. Have you ever done Java development?
EugeneOZ 10y ago
Rust, PHP had simple af builds/packaging. So no, not everything is complex, just old dinosaurs AND web.
- eropple 10y ago
  PHP's packaging was only "simple af" until you had a binary dependency that wasn't part of your operating system. Complicated things exist.
  - objectified 10y ago
    But now you're hitting on one of the main points that was always criticized in PHP: the fact that it came with a lot of batteries included. The upside of this is that it makes PHP applications very easy to deploy, because often, you either don't need to resort to binary dependencies outside the realms of your OS's packaging system, or there will be a `php[major-version]-[library_binding]` package for your OS probably already in your OS's official package mirrors. Say all you want about PHP, but of all the application stacks I've had to deploy, PHP was and is probably still the simplest. The advantage of that shouldn't be underestimated. The only serious competitor in that space that I've ever touched is probably Go.
  - fredsted 10y ago
    Doesn't composer do that? Ie. https://packagist.org/packages/anam/phantomjs-linux-x86-binary https://packagist.org/packages/anam/phantomjs-linux-x86-bina...
  - EugeneOZ 10y ago
    Yeah, you can recompile PHP 2-3 times per year, and it's just long line of args, nothing more. And you can compare it with every-time compilation of modern js apps. What an equation! And you forgot to mention Rust, but let's pretend it's normal way of arguing.
- mattnewton 10y ago
  I would never want to use php's "just recompile it with the new dependencies" approach ever again. It's a complete mess as soon as you go off the rails of what's included by default.
kuschku 10y ago
> Would you prefer to build your application using Make, Scons, Waf, CMake, QMake, Tup, Bash scripts, Maven, Gradle, Ant, Buck, or something else? The build tool question is _totally_ solved, right? :) Yes. I've worked with CMake, Gradle, Maven, Ant, with webpack, makefiles, and the entire rest. And you know what? I went back to ES5, just because it's easier than fighting the JS environment. Comparing your average build.gradle with a webpack config is downright insane. Why does the web environment have to be so much more complicated than the native world? The web could be so much more powerful if they'd study history, and learn from it.
- BigJono 10y ago
  With what webpack config though? Half the problem with the web stack is inexperienced people making things way more complicated than they need to be. A minimal webpack.config is pretty damn simple.
_pmf_ 10y ago
> Qt is big and complicated. I'd encourage every developer considering Electron to give Qt/QML a try. It merges the declarative nature of WPF with a nicer syntax and the ability to use JS directly in the QML file, obliterating the need for converters of formatters (that plague XAML/WPF and JavaFX). Writing custom components is trivial and intuitive, with zero syntactic overhead (if a QML file "MyCompX" is present, you can instantiate its contents with "MyCompX" without any additional setup). For Android, it has the advantage of being able to hot-reload the UI without jumping through hoops (simply serve them over HTTP and install a small reload handler in your app that can be triggered either from the app of by something like a UDP message from the host). (Change one like in the app's main and you are able to pull the QML files from a local directory so you can modify them on the tablet without a PC or internet connection ...) I'm actually reluctant to mention Qt/QML because I consider it to be my secret magic silver bullet for portable (non-web) UI development. Regarding the license (there's a lot of misinformation, including Qt's main site trying to coerce you into using the commercial license): if you link dynamically, commercial usage is not a problem (LGPL). (This is usually only an issue on iOS.) The recent Electron situation (needed on one hand, loathed on the other hand) is a unique opportunity for Qt to gain (back) some developer mind share, but to avoid alienating web developers with scary C++ stuff it would help to decouple QtCreator from the Qt C++ API: offering a version that only exposes the QML editor and interface generator, and ships qmlscene as execution runtime and an option to deploy the QML-only application with a rebranded qmlscene (embedding the QML resources and a custom icon). To be clear: this all exists right now, but with the C++ part enabled (which will scare off some developers even if they can create applications without it).
- fauigerzigerk 10y ago
  >The recent Electron situation (needed on one hand, loathed on the other hand) is a unique opportunity for Qt to gain (back) some developer mind share, but to avoid alienating web developers with scary C++ stuff it would help to decouple QtCreator from the Qt C++ API For me it's exactly the other way around. If I'm using Qt it's because I want to use C++ to make my app as efficient as possible in terms of CPU and memory usage. Now that JavaScript is in the picture, I'm less likely to consider Qt for a cross platform app because I can just as well use any of the other more popular options like Electron or ReactNative. Qt used to be a C++ GUI framework. Rebranding it as something else won't work. They won't get the web crowd and they will alienate people who want to avoid web technology.
austincheney 10y ago
The most disappointing part of all of this is that in the JS environment no build step is required, but it is often there anyways...
- oatmealsnap 10y ago
  What do you mean? Are you referring to gulp and other similar tools?
  - austincheney 10y ago
    I am referring to any build step. Do you need a build step to execute JS?

colordrops 10y ago

I don't know about others but I tire of these comments chiding the "out of control" front-end ecosystem. The situation has already changed years ago. We aren't going to get off of your lawn while you continue to beat a dead horse. The web is built on open standards and there are billions of pages and apps out there. To expect web development to be a perfect monoculture is a failure of your imagination and ability to adapt rather than a failure of the ecosystem.

johnwheeler 10y ago
People wouldn't complain about it so much if it didn't suck.
paganel 10y ago
Not the OP, but I expect the web to be a thing where documents (i.e. mainly text) don't have any issues rendering on my 5-year old phone or on my 8-year laptop (both of which work very well, still, and which I don't plan to replace anytime soon). The recent web practices (I'm talking mostly of the last 2-3 years, since more and more people have started copying Twitter with its launch of its "every website needs to be a JS-app" thingie) have practically destroyed how most of the websites are displayed by the 2 devices I own. Sites like Hacker News or Wikipedia, which still work perfectly fine, are very far and few between. I sincerely deplore this.
- deleted 10y ago
  [deleted]
- ng12 10y ago
  Well what's unique about HN and Wikipedia? They're largely non-monezited. If Buzzfeed can make more money off of a flashy website it's hard to argue with.
  - shortstuffsushi 10y ago
    I don't think it's either/or. You can make a "flashy" (in the sense of Buzzfeed) without it being burdened by huge amounts of js. Likewise, monetized sites are still frequently not like Wikipedia or HN.

droopyEyelids 10y ago

I'm reading some negativity into your take. I see an incredibly complicated problem space- presentation of multimedia content and execution of code on billions of 'fragmented' devices over which the content creator has no control- and the minds of humanity iterating on approaches to the problem.

ng12 10y ago

> the browser is a bad app platform and javascript is a bad language Yeah, and we're finally making real progress towards making it better. I used to do web development because nobody else wanted to, now I do because it's really fun. This is a forum for hackers -- we should be excited about the unsolved problems instead of complaining that things are changing.

kerkeslager 10y ago
I'm not complaining that things are changing, I'm complaining that things are changing for the worse.
- ng12 10y ago
  And you are totally wrong about that. This is the most exciting time to be a web developer since jQuery first came out. I promise it only looks that way from the outside.
  - kerkeslager 10y ago
    I am very much not looking at it from the outside. ES6 is a step backward. Prototypical inheritance was one of the few things Javascript had going for it, but because CS majors who only learned Java in undergrad couldn't be bothered to learn prototypical inheritance now we have two incompatible inheritance systems instead. Promises are minor syntactic sugar over callbacks which could be implemented as a library. Meanwhile `this` still doesn't mean "this", there's still no integer or boolean types, accessing a nonexistent variable silently fails but happily continues execution, only reporting an error when it's far away from the problem. There's no threading, no security primitives, and no decent debugger. None of the problems are being fixed and the new features are either lackluster or make things worse. And that's just the language itself. The ecosystem is in more of a shambles. Web development in the age of left-pad and global shared state being normal is exciting in the same sense as plagues of frogs and locusts are exciting: it's not boring but if it were boring that would be better.
    - 10y ago

kccqzy 10y ago

It's quite possible to use react with nothing else: no build tools, no transpilers, no fancy JSX, so in terms of tooling complexity, it can be as simple as you want or as complex as you want. Regarding the complexity of the underlying system, I think this is not a concern of the typical frontend developer. It has nothing to do with JavaScript or the web. If you are writing a "simple" C program on Linux, would you be concerned about the complexity of the underlying C library (yes glibc is rather big and complex) or the Linux kernel? You won't. This is the point of abstractions. If you want, you don't have to learn about any of these; treat the implementation as a black box and start writing actual frontend code.

adventist 10y ago
Any resources you can provide about how to use React without JSX? JSX is a blocker for me.
- kccqzy 10y ago
  > JSX is not a requirement for using React. Using React without JSX is especially convenient when you don't want to set up compilation in your build environment. > Each JSX element is just syntactic sugar for calling React.createElement(component, props, ...children). So, anything you can do with JSX can also be done with just plain JavaScript. Source: https://facebook.github.io/react/docs/react-without-jsx.html https://facebook.github.io/react/docs/react-without-jsx.html
- ng12 10y ago
  It's basically just to use the React.createElement API that JSX transpiles to. I say give JSX a chance though.
  - tdfx 10y ago
    I had an initial negative reaction to JSX, as well. It grows on you, though.
- acemarke 10y ago
  Sure. At the bare minimum, you write "manual" `React.createElement()` calls. To simplify or shorten things, you can alias `React.createElement()` to something like `h()`. There's also a variety of libs to help with that process. We have an existing ES5/Backbone app that's built with Require.js, and we don't have a "compile" step in there. We just added our first couple React+Redux-based features into that codebase, but can't use JSX due to that lack of compilation. I opted to bring in https://github.com/Jador/react-hyperscript-helpers https://github.com/Jador/react-hyperscript-helpers as an alternative to JSX. Not perfect, but it's a suitable alternative given our limitations. There's several other "virtual DOM/hyperscript"-ish packages out there as well.

melq 10y ago

Why is an active ecosystem with healthy competition a bad thing? Personally, I can't stand javascript, and why you'd ever elect to use it for backend/server side code mystifies me. So I don't use it (or work in web development), and couldn't care less about what platform the hip web devs deem acceptable.

user5994461 10y ago
healthy competition is robust and tested. A short fade that's gonna be abandoned within a year or so doesn't quality as healthy competition.
mod 10y ago
I mostly agree, however it does seem to make some sense to dive deep into one ecosystem, instead of learning & keeping up with two. (Let's not pretend that Javascript is the only one advancing--Django of a few years ago is not compatible with Django of today, as one other example). I have always used python/ruby on the backend, and I prefer them, but I recently worked on a couple of javascript backend projects, and I found one abhorrent and the other quite pleasant. As could probably be expected, the practices used to develop the latter were just better. (These were even done by the same developers, in large part, and the differences were mainly lessons learned). Anyway, if you're already working in a javascript-heavy front-end like React, it doesn't seem like such a stretch to use it on the backend, too.
- frankpf 10y ago
  Would you mind elaborating on some of those practices (specifically, the problems that made working on the first codebase abhorrent)?

user5994461 10y ago

Let's advocate the other extreme. Get back to mainframe and Cobol. No more fuckups dealing with endless changes. No more need to deal with youngsters and their framework of the year. Of course, it comes with its own issues, but you'll be blind to them for the first few years while you enjoy the cure of stability :D

kerkeslager 10y ago
Or, you know, let's advocate reasonable positions and not pretend that the only alternative to Javascript is Cobol.

braveo 10y ago

I was having a similar discussion just today. I was told I should be using swagger, and upon learning more about I started asking why they didn't just build tooling around WSDL. I couldn't see anything enabled by Swagger that isn't enabled by WSDL. About the only thing I could think of was simplicity due to it being more specialized than WSDL. I was told javascript can consume swagger easier, which may be true, but I don't know why that's a significant problem with WSDL seeing as how you could autogenerate the javascript interfaces anyway. I still can't really wrap my head around what problem Swagger is solving that wasn't already solved by WSDL.

lobster_johnson 10y ago
The problem with WSDL, at least at its inception, was that it tied in with the whole WS-* extravaganza, a set of standards that are built on top of each other and heavily based on XML. While WSDL has evolved to support RESTful services, early WSDL was closely tied to SOAP. The XML thing is slippery slope. Suddenly your toolchain has to be aware of namespaces, XSD schemas, and so on. It's a largeish universe of a standards that sound good on paper but don't contribute meaningfully to anyone's productivity. And XML has historically been (and still is) popular with the enterprise Java crowd — J2EE, Spring and so on — there's a pretty steep divide between that and the more agile world of web devs and startups. If you're buying into the XML stack, WSDL will seem like a nuisance more than a productivity multiplier. That said, I don't think Swagger/OpenAPI is very good, either. It's replacing XML with YAML, and introducing its own set of issues. And the community and tooling ecosystem aren't quite there.
- braveo 10y ago
  The question I posed in the discussion is why they didn't extend WSDL instead of trying to rebuild the entire ecosystem by creating Swagger. To me the XML/JSON thing is a non-issue. I've never really gotten the unreadability of XML argument given a decent prettifier (which also applies to JSON), especially for something like a web service description. I guess my thing is, we already have a web service description language, it's called WSDL, and it's already been extended to support REST, why not extend it to support whatever use case you have, or build the tooling around it to support said use case? You could have easily built the Swagger Spec to spit out WSDL instead of JSON. It means you would have been able to lean on the existing tools that can swallow a WSDL file instead of having to recreate the entire ecosystem yourself. What I kept getting back was "JSON > XML" and to me that's just a non-issue. It's so far down the list of what's important that I can't imagine making the decision to try and recreate all the tooling around WSDL for it. And I guess I've never really had your experience with WSDL because I've never been forced to be aware of namespacing issues any further into my system than the edges. Perhaps I've been lucky, but I've been using WSDL for years to ease integrating into web services and I've never stopped and thought to myself that it would be better in JSON with a YAML spec. And I rarely deal with SOAP nowadays, and when I do, I just use a library to swallow the WSDL and do the right thing. I guess that's really where I'm coming from. It smacks of religion to me.

Tloewald 10y ago

It's funny how using a bad language and bad platform I can put together a robust, networked, maintainable, cross-platforn application faster than I could with any prior set of tools. Weird. And, by the way, I'm not defending react.

dntrkv 10y ago

Browsers and JavaScript are what we have, we can't magically replace every browser and JS implementation in the world. We have to figure out where we want to go and slowly get there. That is exactly what is happening in the frontend world and that is why there is so much churn. Browser apps have to work across 4 major browsers with versions going back almost 10 years, an infinite amount of screen sizes, and a near infinite amount of devices. There is no other platform with the capabilities of the browser that has this much reach. If we had the ability to start from scratch and build the ultimate web platform, yes, it would probably be way better than what we have, but we don't have that ability nor will we ever have it, so talking about it is a waste of time. We need to look at our current capabilities, where we want to be in the future, and iterate until we get there. All of the tooling we have serves a purpose and solves a problem, it's not like frontend devs are adding tooling for the fuck of it. Take a common stack nowadays: React, Redux, Webpack, Babel, Eslint, Yarn, Styled Components Every single one of those tools in the stack make my life easier. I don't have to use all of them. In fact, there was a time where I didn't, but I would never want to go back to that time because these tools allow me to build way more complex apps way faster than I used to. And the other great thing about these tools is you can add/remove them as needed. Take something like browser prefixes, as browser support for certain prefixes or features are implemented at a large enough scale, the tooling for that becomes obsolete and you drop it. And as far as JavaScript goes, pre ES6 I would agree, it sucked. Post-ES6, I will have to disagree. I love writing JS nowadays.

segphault 10y ago
> And the other great thing about these tools is you can add/remove them as needed. In order to get that freedom, you need to build the tooling in such a way that it aligns with the web standards, so that when the standards catch up you can drop what you don't actually need anymore. We all switched from coffescript to ES6 and Babel because ES6, being standards-based, will eventually be supported in browsers, right? And yet, with JSX we have a gratuitously non-standard dialect of JavaScript that isn't on the standards track and will never be natively supported in browsers. So, even when browsers catch up and offer full support for modern ES6 syntax, we're still stuck with transpilers because Facebook thought it was a good idea to tightly couple their custom templating language to JavaScript itself instead of wrapping it in template literals, which is the standards-based approach that ES6 actually provides for embedded DSLs and templating. Today, in Europe and North America, roughly ~85% of users run a browser version that has native ES6 support. IE marketshare fell off a cliff in 2016, and now IE11 is at less than five percent and still falling. I don't actually need to transpile during development today, and I won't need to do it in production either in a year or two, and yet everything written with JSX will need a transpiler forever.

banachtarski 10y ago

> However, just one look at that giant horde of links is, to me, a perfect demonstration of why the front-end development ecosystem is way out of control. This has got to be the biggest jump to a conclusion I've seen in HN comments this year, without a close second. Sincerely, C programmer who thinks there still something to be learned from some of the architectural underpinnings of a library like React.

venture_lol 10y ago

That's because noone really, truly, honestly want to RTFM of a given stack, library, etc. It's more fun to roll your own or to pick up a new one. I mean, in how may ways can you organize code that manipulate a DOM tree, pull data, massage data, and update the DOM tree? Well, the more the merrier :)

jacquesm 10y ago
I fear that this comment embodies more than a little bit of truth.

batmansmk 10y ago

Good troll. Ask your users to install your app and qualify as extra features (with associated budget) the capabilities of bookmarking, sharing urls, having multiple tabs, "remember me" and forms autocomplete, going back, having a history, or auto-update. Justify it to them it's because their browser is a bad frontend platform. Like this horrible, horrible mobile twitter lite ;). In my first year of programming, html was such a joy to use compared to gcc. Could get a button with a background color and an image displayed under 2min. Just saying.

NoGravitas 10y ago
The web is a great platform, and so are browsers. JS apps running in the browser? Not so much. How many of those features you list are routinely broken by SPAs? Bookmarking and sharing URLs? Almost always. Going back and having a history? Often. Having multiple tabs, and forms autocomplete? Sometimes. I hate web development mainly because I love the web so much.

austincheney 10y ago

> a perfect demonstration of why the front-end development ecosystem is way out of control. The answer to this is simple but horribly disappointing. In the military we describe this behavior as "justifying your existence". There are three separate causes to this problem. First, solving valid problems is hard in any environment. Dicking around with tooling and configuration is easy. This includes frameworks, abstraction libraries, and so forth. Real problems are often tied to products, services, or end-user problems (opposed to these invented developer problems). Second, writing open source software takes initiative and discipline. It is easier to have the energy for hard problems when people are telling you what to work on and you are getting paid. In this case failing to complete the hard problems bring retribution and eventually termination. When you are on your own or volunteering your time you have to really want it, which completely compounds the first point. Third, there is a low barrier to entry to do front-end work. You can copy paste some code from the internet into your browser console and watch it do stuff. You don't need a compiler, special environment to get started, or any kind of fancy software. This problem is compounded in the legacy corporate world where web technologies are still viewed as inferior child's play for incompetent weak-minded children. After all real developers write ALL of their web related code in Java 6 (sarcasm).

russdpale 10y ago
So true.. At my fortune 50 company we force ie to render in ie7 engine for our internal reporting. Yes, that ie7...

sharun 10y ago

It's like the Engineering teams at Google and Facebook have never heard of Microsoft or Sun or Adobe. There are so many lessons (learnt the hard way) in the evolution of .NET, Java and Flash that these guys seem to be completely oblivious too. Google, Facebook devs please go spend some time with the language and platform greybeards at Microsoft. EDIT: Feels like Software Engineering needs a set of Software History textbooks to keep reminding us of what has already been built.

chillacy 10y ago
Any specific examples? Nodejs seems like it's managed to avoid the early java mistakes of XML everywhere and one-thread-per-request servers.
axiomabsolute 10y ago
To be fair, I'm pretty sure some of the engineers at Google and Facebook have spent some time with the language and platform graybeards at Microsoft, Sun, or Adobe. Some of them are those "graybeards" (in quotes, because they don't literally have gray beards). [1] [1] : https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer) https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)

amptorn 10y ago

> Every year the hot libraries change Front-end development is fashion.

fenomas 10y ago

And thus, yet another insipid "hey let's argue about JS fatigue!" comment clobbers another HN comment page, with 100+ replies not one of which has anything to do with TFA.

monkmartinez 10y ago
If it wasn't a problem, it wouldn't be upvoted. That is how voting works. I'm not a JavaScript programmer, although I have dabbled extensively in the past. My impression of this thread is that not much has changed in that world. Sencha, titanium, and Phonegap were super hot back in the day, along with jQuery, SproutCore, Knockout and Backbone. Now it is all different for JS. That fuckng sucks.
- ng12 10y ago
  It's such a dumb argument that boils down to "things are changing and I don't like it!". Javascript fatigue is not real. I am completely convinced anyone who says otherwise has never had to maintain a non-trivial web application in Backbone/jQuery -- meaning they're complaining about frameworks that weren't built for their use cases.
  - douche 10y ago
    Javascript fatigue is real. Shit in front-end land changes so fast it is impossible to keep up with. We just finished a rewrite from jQuery to Angular 1, with updates to all the tooling that goes along with it. We're now at least three years behind the curve... Hooray! Meanwhile, the backend frameworks we've been using have had one minor version Nuget package release in the same timespan.
    - ng12 10y ago
      Angular 1 is 7 years old. And guess what? It's still a perfectly valid framework to build a web application with. There is no "curve".
      - 10y ago

joelhooks 10y ago

React has been "the yearly hot library" since 2013 for anybody counting along.

j_s 10y ago

Old school devs and those who prefer to invest the bulk of their effort on the backend might be delighted to discover Intercooler.js https://news.ycombinator.com/item?id=12885980 https://news.ycombinator.com/item?id=12885980

altern8tif 10y ago

So much negativity here. Constantly pushing the boundaries of existing technology is how we got here in the first place. If we were content with the status quo, we'd still be looking at a four-month journey from New York to San Francisco on horseback.

hiram112 10y ago
No it's more like we've got a 2 month journey on the Hindenburg.
pbreit 10y ago
Ironic analogy. Because what used to take a day in Rails now takes a week in [pick your back-end]/[pick your JS frontend].

weq 10y ago

amen. I rolled a angular app 3 years ago, and now most of the libs i used are unsupported, and impossible to upgrade anything cause of dependency hell. now we dont use yeoman to create react apps, and we have a thousand start kits that get u off the ground. your node_modules directory probably has 30k+ plus files before a single line of your app is written. yarn just imagine ur an embedded programmer, and you boss asks u to write a hello world for the nexet device, and u come back with a react app with 30,000 dependencies to get the job done. then u find a bug, which fb just fixed in the next release. But u cant upgrade to the latest version, because that conflicts with library that is used by a 3rd level dep, that is used to add padding to a smiley somewhere.

vrde 10y ago

The thing that backend devs don't realize is that frontend is not easy. A frontend dev builds something that will be used by a HUMAN, while a backend dev builds something that will be used by a PROGRAM. Related to the comment, things were changing a lot because there is not one single way to do things, as in iOS/Android. There is no standard imposed by a huge private company like Apple or Google. Everyone is free to reinvent the wheel. Facebook did something super valuable, that is ReactJS, and this is becoming the _de facto standard_. ReactJS is simple, opinionated, and supported by a large corporation. Thanks to ReactJS a new ecosystem was born, and now finally you have many projects gravitating around it, and this is good. It's just a matter of time IMO. I strongly disagree with _"the browser is a bad app platform and javascript is a bad language"_. JavaScript has its quirks, but it's also really plesant to work with if you don't do weird shit like `isNaN('wft' - 1) // it's true`. The browser is a great virtual machine that is democratizing the web. If you are doing things right, you can have graceful degradation (it degrade gracefully to a lower level of user in experience in older browsers) to increase the audience of your web app, from the dev in SF with gigabit internet to someone living in a rural area in a not so tech advanced country. This of course has a cost, that is spending time developing your app.

wccrawford 10y ago
As a fullstack dev, it amuses me when my underlings claim that backend is hard and they want to learn it. They're already doing front-end. (And yes, we're working them towards more and more backend, and even mobile.) It's just different, IMO. Programming is programming, but different specialties have different things you need to worry about.
- H1Supreme 10y ago
  Absolutely. I've been doing "frontend" work before it was even a term (ie. html tables for layout), and it's still the #1 thorn in my side. Even with all the tools available, developing a functional, aesthetically pleasing GUI is not an easy task. Plus, organizing your code so it's not a 15-nested-div mess with inline CSS just to make the damn thing look right. It's probably why most of my personal projects have a CLI, and that's it.

whostolemyhat 10y ago

Would you rather have less documentation and fewer tutorials? I wouldn't call four links about a new library excessive.

ThePhysicist 10y ago

There's no need to actually use all these complex tools if you don't want to. We wrote a pretty large (>20kloc) React application with a simple require.js based build flow using a Makefile that invokes a couple of tools for bundling the JS and generating assets like CSS. We used our own resource loader framework based on jquery (Redux didn't exist at the time) and a simple routing library (director.js). Still works like a charm! In my opinion, the important thing in frontend development is to know which tools and libraries to adopt and which ones to ignore. As a platform, I find JS+HTML5 really appealing and I'm happy that there are many ways to use and creatively remix these technologies, so I don't see the large churn in the ecosystem as a disadvantage but rather as proof that browser-based JS works very well as a platform to develop applications on.