“The Universe is under no obligation to make sense to you.”
The universe may be under no obligation to make sense to us, but our tools are.
 - http://intercoolerjs.org/examples/index.html
 - http://intercoolerjs.org/2016/05/19/back-to-the-future.html
Back when I was using just jQuery and maybe Backbone or KO the tooling was simple but an incredible amount of rigor was required to keep the code maintainable. A big part of my job right now is providing a dev environment where people don't get fatigued -- most of the tech decisions I make are geared towards ease-of-use by backend devs. Sure, the toolchain is relatively complex, but it's a fundamental part of why I'm able to do that.
Not saying you're wrong. I'm not even saying what you're doing doesn't matter. In theory it should work as you described. But I'm saying in reality you may be too into what you're doing that you don't realize what others think.
I've had a few people who were in your position in my past job, and they seemed to believe what they are doing is indeed better for the team (and so did the managers, that's why they were working on it in the first place!), but from an actual "user" point of view, they didn't help at all but made me a very dissatisfied developer. The thing is most people don't officially complain about it because they don't want to be seen as a loser who "can't move fast enough".
But here's what REALLY happens while you're thinking everyone's benefitting from your work:
As a developer, less code WITHOUT knowing what's going on underneath is the worst feeling ever. That's one of the biggest criticisms on rails. But that's a different story since rails actually provides huge benefit as a result (and people know that it isn't going anywhere so it's worth learning)
When we come to JS land, there's no clear "10X" benefit to adopting these technologies. Sure there are incremental benefits but they don't justify learning every new packaging tool / framework every couple of months. I shit you not, a lot of companies have gone from grunt to gulp to webpack (and who knows what's next) just because they're the cool new tool that's "better" than the other. Some may say I'm lying just to exaggerate, but I am not. They do this because they want to "attract new developers who are looking to work with latest technology".
But in my opinion that's the stupidest thing a product building company should do. You're better off attracting great developers by building a product that's so compelling that developers want to contribute no matter what the stack is. I'm sure Snapchat had no problem attracting top talent in LA when all they had was a shitty mobile app that they didn't even bother making pretty.
Lastly in most cases, only a few people on the team are responsible for taking on these framework migrations. Which means the rest of the developers just become "users" and are left feeling like some passive idiots who just follow the "early adopters". As a result the developers fall into two categories: 1. People who don't want to feel left out and pretend they like the tool and keep following (and this feeling of "following" feels really shitty if you are not a "follower" kind of person); 2. People who complain how these "upgrades" are totally unnecessary and as a result treated like "old school" by the people of group 1.
Step back and think about how much efficient web development has become for 90% of developers (Not for you, who already are on board and an expert in adopting one new edge tool every month). To be clear, I know how to use all these tools (grunt, gulp, webpack, etc.) but whenever I need to build a quick prototype I just use plain old html/css/jquery. You could say you could use things like Yeoman to set up things quickly, but that's not the point.
Not at all. The reason I accepted that gig was because the team previously had a complex SPA written with what the above poster would consider simple tools -- and they were extremely unhappy with it. It took too long to add features, to modify things, to grok the control flow, to hunt down bugs. And that's not to say the app was poor quality: for the tools used everything was fairly idiomatic and organized. They hired me because they thought things could be better, and I thought they could too.
> As a developer, less code WITHOUT knowing what's going on underneath is the worst feeling ever.
Do you write all your code in assembly? The whole reason we use tools is because we don't want to think about what's going on underneath. React/Redux are simple by design and both incredibly easy to reason about. Webpack is a little more complicated by nature (most build tools are) but even then the core API is very simple -- just define a chain of compilation tools to process files of a given type.
> in adopting one new edge tool every month
I'm not sure where you get this impression from. The last major change to my standard stack was Flux -> Redux, and that was almost a year ago (and a relatively simple migration). Apparently you enjoy being crumdugeonly, but please have some faith that some of the web development community know what they're doing and care very deeply about the same things you do -- namely, crafting maintainable software.
> I need to build a quick prototype I just use plain old html/css/jquery
Sure! Pick the right tools for the job. Those are the right tools for a demo, the wrong tools for a long-lived SPA which needs to be maintained/extended by a team of engineers.
In a long-lived application, early team members will need to learn the new tech and later team members will need training in the old ways to work on your now-archaic tech stack (that you couldn't upgrade because of version incompatibilities). They'll also need custom-built dev systems that come with the project (because some of the tools are no longer available in those versions or at all). You won't be able to use new tools without first backporting them. You may have to deal with potential security issues in code that is no longer supported even though you don't even need that code, because it's there in the dependencies.
In fact, in some cases the use of lots of dependencies might actually be better for quick prototyping (because they let you do so much with so little development) that you don't have to maintain and extend than for long-term projects. It's a tradeoff. Either way has benefits and drawbacks.
For example, there's tons of libraries provided via CDN so you can link them in script tags. That's as far back as I can think in terms of JS tooling. Bower still exists. So do grunt and gulp. jQuery is still releasing new versions, so is angular 1. I assume backbone and knockout still exist.
I don't really see how Intercooler is any better than vanilla jQuery; you've just offloaded explicit promises and event assignment into custom HTML attributes that don't translate to any other framework. After doing some reading, it looks like you were frustrated with Angular's AJAX calls...did you try one with jQuery?
 - http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
 - https://en.wikipedia.org/wiki/HATEOAS
There's a sliding scale of what counts as "necessary" to different developers. For example, the first entry in the intercooler.js examples is a "Click To Edit UI" that doesn't escape HTML in user input. For many websites, that probably doesn't matter all that much, but for developers that care about script injection, they might go for a different solution that makes that sort of problem harder to introduce. That exposes the underlying complexity though, since using string concatenation to generate HTML is no longer a safe option.
If the rendering was still done on the client using `userDisplayTemplate`, I'd guess that the response to the save web service call would be a JSON object. The server would then need to know that the user object it returns should have HTML strings as its properties, rather than just a plain text. Possible, but the complexity doesn't go away.
There are some good practical and theoretical reasons for doing this:
"THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
 - https://opensource.org/licenses/MIT
I can find a lot of "no code necessary" apps that do the same in angular/react/whatever.js
I think this is obvious if you read the docs, which I encourage you to do:
> web development itself is inherently complicated.
> We are trying to build applications that run right in a dozen browsers
> look good on thousands of different devices
> load fast enough for impatient commuters in the subway
> and are still accessible enough that blind people can use them.
> The Cambrian explosion of tools you see around you
> is what rapid progress looks like when it’s not
> controlled by an Apple or a Microsoft.
> At the same time, web developers are closing security
> vulnerabilities all over the place.
> If this evolutionary process frustrates you [...]
In addition nodejs has become arguably THE introductory web development language and as such offloads many complex but necessary tasks to its third party libraries in order for beginners to develop efficiently. This means security features ranging from CSRF to ORMS to CORS etc are taken out of the domain of developers and into that of typically un vetted third party libraries, becoming a vulnerability in and of itself.
Ironically, as we introduce more expressive power in the browser (an untrusted execution environment) to support SPAs, we are actually introducing more security issues:
These are the crazy years.
HTML5 is responsive and semantic by default. If you work with it rather than against it, you'll have incredibly rich documents that support users very well on a wide variety of different devices at no additional effort on your behalf.
If you stick to only enough CSS3 as to actually style HTML5, not redefine it, then CSS is extremely easy to maintain, too.
ES5 is implemented in all major browsers and its simple parts are very simple to learn. OOP and FP vie for the hearts and minds of developers with terrifying sparks and flames, but we've built entire empires off of procedural programming. Your choice of programming paradigm will likely have zero impact on your project's success.
All of the difficulty we have is when we try to buck these strengths. You don't need a task runner if you aren't running tasks to translate Haml and SCSS and CoffeeScript to HTML5 and CSS3 and ES5.
I'm not saying there isn't value in doing those things. I have my own convoluted process that I am constantly tweaking. But they are by far not the default. If you want to say that Web development is inherently complicated, you must talk about what is at its core. And the core of HTML5/CSS3/ES5 is not complicated. You can write it with a plain text editor. You can load it in any browser. You can serve it from any web server in their default settings. We fundamentally choose to complicate these things.
The functionality of 99% of all websites I see these days can be replicated with simple DB calls, string concatenation and a handful of straightforward progressive enhancement libraries on the client side. Some developers simply choose complexity.
The fundamentally complex aspects of web development aren't solved by the stuff people are fatigued by anyway.
Yet this is what everyone does and what romaniv means. We have good tools for applications that people use for static content.
Here's my reasoning: As someone looking for a Web Dev job, your static site built with Handlebars or server-rendered HTML won't impress anyone. Build it with React/Redux/Immutable and suddenly you get more interviews or at least more hits. This has happened to me.
Therefore, when those people finally get employed they'll just keep building with the tools that got them the job and never think if they really need them. If you switched a complex React app to a server-rendered Node/Rails/Django one, how much more less work would you have to do?
I'm yet to see these non-trivial interfaces to data that justify megabytes
sense (e-mail client (but not that much, and can be just fine without any JS
whatsoever), text processor or spreadsheet, chat), but those are rare.
OK, let's put charts and graphs aside. What do these business applications of
the server side?
You must not have seen the flame fest about PHP on the rest of HackerNews!
TL;DR: We have mostly used the same tools for years. People feel that React or Webpack are the new hype tools for cool kids, but React is there since 2013 and Webpack since 2012. A lot of companies still use Angular 1 (released in 2010, almost 7 years ago).
I'm working on software that was started in 1999, this isn't unusual.
The best teachers I've ever had took things that many people label as "inherently complicated" and made them clear and simple. More often than not complexity arises from insufficient depth of understanding not from something intrinsic to the subject matter.
"these new tools are very much a good thing. ...
They will make you a happier ... developer."
I object strongly to being told what will make me happy. The current tool set does not (other than React). I am glad they make someone happy.
- A sane approach to locking that's built in and impossible to forget.
- Deterministic installs.
- Basically enough stability that "delete your node_modules and npm install" is never a necessary solution to anything (I've had tons of instances where I've had to do this with npm).
I'm glad there's a lot of people working on open source projects. I wish they'd publish more documentation about use cases and UNIFIED (not piecemeal) deployment configurations, though. After all, your toolset has valid and relevant use cases... right?!?!
But as I'm trying to control page transitions in SPA using react-rotuer v4 I have a feeling that I basically re-implement subset of a browser ... poorly.
Then why do they not do that? Every "modern" web application loads slow as hell, works decently only in Google Chrome, ruins the functionality of the back button, and eats 100% of your CPU. I've seen blogs, blogs, that do this sort of stuff.
Even if it is a very high percentage, say 90%, we are still left with millions of high quality applications. You may have to do some work to find them, but it's no apocalypse.
Whenever participation in some dynamic becomes immensely widespread (in this case, building web apps) the average quality of each instance always drops. This is a well understood phenomenon that is not unique to web applications.
What matters is the scale at which you plan to build your project. If the project is only ever meant for one person to use, then it's practically trivial. But being on the Web, you expose yourself to a much larger potential market, so I think it's easier for estimates to get blown out of the water. Desktop applications scale horizontally be default. Web applications scale vertically by default . So if there is some "difficulty", then it is in that most Computer Science degreed people  first train in single-user, runs-on-a-desktop programming, so that is what they are initially familiar with. But it's a difference of starting point, not a difference in overall difficulty.
There is a cultural issue that a lot of companies continue to treat the Web as a sub-standard platform, a lot of engineering teams continue to treat "The Front End" as an after thought, and they continue to hire only junior developers who have only ever written programs for themselves. This is not to knock Jr. Devs. We all start somewhere. But there are a lot of companies that expect way too much out of someone with 0 to 5 years of experience because they don't expect enough out of the Web as a platform.
Other than that, concerns like accessibility, internationalization, cross-platform compatibility, they're all easier across the board on all platforms today than they've ever been on any of the platforms. I don't think there is any argument to be made there.
 Hence the desire to make SPAs. A good SPA scales horizontally as well as any desktop application.
 Myself included in this group.
I can't see how that's not a MASSIVE difference. That's adds a whole extra layer of complexity.
There is virtually nothing in web apps that is easier, almost by very definition. What web apps made easy was deployment. Please name one other thing that's easier than in a desktop app. HTML wasn't even designed for apps.
I just cannot comprehend how you can believe what you wrote. I really haven't written many desktop apps, but generally speaking when I did in say VB6 or Silverlight, they have been trivial to make compared to a web app of identical complexity.
Cross-form-factor compat is infinitely easier in HTML. If you think HTML is bad, try getting the same Qt app to run on a 4k desktop screen and a smartphone.
And contrary to popular belief, HTML was indeed originally designed for applications. Why do you think it has the form and input elements? Why do you think HTTP has OPTIONS, POST, PUT, PATCH, and DELETE? If it were just about document delivery, GET would be enough.
Mutli-user systems are significantly easier on the web. What you mention as a boon for the desktop is only a boon if you're only interested in supporting one user at a time.
You rightly mention deployment is easier. That's no small thing. I've seen entire departments grind to a halt for entire days, once a month, because they sucked at deployment.
What you are talking about being easy belies your values in what an application should be. If you valued different things in your applications, then you'd find the desktop system to be more difficult than the web. And that's why I say they are not fundamentally more or less difficult than each other.
Indeed, the original draft for HTML did not include forms or input elements. While HTTP had POST, PUT, and DELETE, those were supposed to be used for uploading new content or replying to newsgroups. In particular, the semantics for POST were quite different: “Creates a new object linked to the specified object. The message-id field of the new object may be set by the client or else will be given by the server. A URL will be allocated by the server and returned to the client. The new document is the data part of the request. It is considered to be subordinate to the specified object, in the way that a file is subordinate to a directory containing it, or a news article is subordinate to a newsgroup to which it is posted.”
While these features were added quite early in the development of HTML and HTTP, respectively, they certainly were not part of the original design.
For questionnaires and guest books. It was only later discovered that this
allows to have an application that runs server-side, but is displayed on
> HTML was indeed originally designed for applications. [...] Why do you think HTTP has OPTIONS, POST, PUT, PATCH, and DELETE?
What on earth do HTTP verbs have to do with what HTML was designed for?
The market for all types software is huge and we only ever hear from a very small section of it. It's why I don't take the concept of programming-language-oriented "communities" too seriously. There is a huge body of dark-matter programmers out there--probably 90% in any particular language--who do not participate in the meetups and conferences and discussion forums. They just work and then go home at the end of the day to do something completely unrelated to programming.
Chances are most of your users don't care about you using ES6 or TypeScript. They're not checking to see if your code is minified, uglified, bundled, code-split, or whatever. What matters to most users is their experience, not yours.
By your reasoning for backend, frontend sucks because I could probably find Open GL wrappers for every language used on the backend and make a front end.
Backend really is relatively simple because usually language X has a few really good libraries/frameworks you can pick up. Js is Node.Js. Python is Django or Flask depending on what you want to do, Elixir is usually Phoenix, etc.
Wow! That sounds cool! When do we start doing that?
Now, seriously, the complexity of the problem is enough you don't need to pile up more complicated tools on top of them that become, too, problems to be solved. We have tools to manage micro-dependencies we create because we have the tools to manage them. Then we invented tools to bundle micro-dependencies because we didn't want the browser to request 300 separate functions in 300 separate http requests and soon we'll unbundle them and let the browser request them because the individual request itself becomes cheap enough...
I get we are talking about "web applications" that have routes, don't re-render pages and don't hit the server for full pages. If this reminds you of what we were doing with Visual Basic in the early 90's minus using HTTP to get JSON data from a server, it's because this is a solved problem. What it feels like is that we are trying to re-do it with the wrong abstractions.
Show me the "business value" proposition for NOT using Elm (http://elm-lang.org/) over the expletive-deleted soup of modern JS web "app" development or shut up.
We have become complexity junkies and this article is a junkie rationalizing the habit.