How is this churn any different to other languages at the height of the popularity? Every other web programming language seems to have it's defining framework (whether it be a collection of quality packages or entirely first party code). From Rails to Django to Symfony to MVC, plus not forgetting that each language also has a popular "slim" framework also.
I see no reason why that would differ in the JavaScript world - whether it be front-end or back-end. Angular's changes may have burned a lot of developers but it could just be teething problems - learnt some critical lessons on the first round and resolving them before it's too late. I fully expect to see a solid MVC framework on the backend, whether it's Sails.js or something else that comes along.
idk; I've been focusing on all things javascript for the past two years, and I can relate to the "alienation" the author is describing. I mostly write vanilla (or +underscore) and AngularJS, and it feels like you have to constantly compare things, because so many of the workflows don't feel right.
AngularJS scales really well on gigantic applications, and it felt like there was going to be some stability from the corporate-world, but now it's gone.
Frontend code is so hard to maintain well (compared to backend), and now it's going to cost companies millions of dollars to migrate: retraining, migration, unit-testing, QA
The stability will still be there - the first evidence of breaking changes was at ng-conf back in January, when Vojta presented about di.js. In addition, Angular 2.0 won't come out for over a year (I'd bet on 1.5 years from now given the tendency for timelines to slip - 1.3 was originally supposed to come out a year ago), and Angular 1.x will be supported for 1.5 years after that. That's at least 3 years of active development in 1.x. Meanwhile, the development ecosystem will probably have finally adopted Web Components and ES6 as the norm for development, and so it would give the perfect opportunity to evaluate options to migrate to then.
Web Components looks hugely promising as the path for independent components - essentially what Angular directives were meant to be in the absence of such browser technology.
Check out http://dailyjs.com/ some time. Granted, it's devoted to all things JS (not just frameworks), but the number of libraries and microframeworks and plugins for frameworks is absolutely astounding.
I don't remember ever seeing anything like this level of churn, and I've been programming since the early nineties. Not with Java, not with Python, not with anything.
Someone above mentioned rolling their own stuff with vanilla JS (which provoked an immediate invocation of Greenspun's tenth rule). My sense is that a lot of people start out this way and say, "Lo, a library! Github!"
One hopes that the cream rises to the top, but I'm drowning in milk.
Good question. I guess here, and Twitter? ugh. There's nothing "centralized" for cutting edge javascript development (hopefully not an oxymoron..), so I consume a few different places daily. I don't feel like I'm missing out on things that's for sure.
One cause of the syndrome is relying on HN as your temperature gauge of technologies. A lot of the reason I keep up with HN is as a heads-up on what half-formed l33t technology will next become my problem.
Frontend JS is so hard to tame, and it feels like everyone has such varied and strong opinions on it. I'm with the author on continual shake-ups in frontend dev, but maybe with better support for DOM stuff, and framework agnostic dependency stuff, we might have gotten somewhere just as some of the rug got pulled out.
Sigh... with AngularJS 2, I'm shuddering at all the unit tests that will have to be rewritten.
Well said Breck! As a front-end dev it feels like a hurricane of new libraries and frameworks all the time.
Two years ago I decided that the best course of action would be for me to really dig into HTML and CSS, and ive been learning vanilla JavaScript as well, and that combination has worked and will continue to work. Im leery of anything I couldnt write myself, but if I can take an existing library and expand on it and make it my own that saves me time and I know I wont have to worry about compatibility changes down the road.
That was the vision of OOP, too ("Software ICs") and we all know how well that turned out. Even Unix is not really the big success story here -- one might say that even something like 'awk' is already stretching the paradigm, never mind common fellow travelers like Perl or Emacs. Never mind most graphical interfaces.
I know, this will probably evoke a "No true Unixman" response, maybe even with pointers towards the Plan 9 highlands, but the truth is that a) connecting stuff is hard and b) a good connection is often a prime feature itself.
Especially the latter will result into a plethora of modules of its own, for nearly all possible combinations of component modules. The end result is even more "frameworks". Sure, they're going to be modular frameworks, but I don't really know whether that's going to help the developers who live in the uncanny valley of mostly knowing what's there and how it connects.
A "fat kernel" with lots of "satellite modules" might be a viable approach, too. Just like with most programming languages (i.e. not C or JavaScript), where you've got plenty of useful stuff in your standard library, and some package manager for the rest.
But hey, if the JavaScript ninjas finally figure out how to properly combine software components, that would be better for all of us. I just wouldn't bet on that.
I agree that fragmentation is a problem, but don't understand why the solution to that problem should be smaller, fragmented libraries instead of larger, complete frameworks. Isn't that the same problem described in combining all the tools with small market/mind share? In my experience, far more problems arise from the interaction of separately authored modules versus the interaction of modules designed to work together. Not to mention that there will be far more blogs and SO posts about a larger framework.
I came to say the same. If you multiply the number of dependencies, owned by different people, having different interest, you multiply the chances of having to catch up with a problematic update.
On a more general pov, the debate between "integrated design" and "modularized" design has been going on for decades. We know the advantage of both. The problem right now is that angular made a desition to break compatibility in a major way while their framework was barely becoming mainstream. Let's not make it a bigger problem.
People that invested in the .net framework, or in the unity framework, did not make a blunder. All we need is an equivalent in the front end js world.
So there seem to be 2 separate issues this post is addressing.
1. A lot of JavaScript frameworks are being released
2. JavaScript frameworks are being updated too fast.
His biggest example, the Angular 2.0 split, is of the second one, but he seems primarily concerned with the first one.
I can see the first one being a problem primarily for developers keeping their skills up to date. The fact is that once you've put a decent amount of code down into an application, you're not going to be constantly switching frameworks. Maybe do it once, but otherwise the applications that are already built will stay on a stable foundation. So for developers working on a single or stable set of applications (not client work), this shouldn't effect their actual work. There may be an issue of skill decay if employers are constantly looking for the latest and greatest, but outside the Silicon valley bubble, I still see a lot more jQuery and Backbone job postings than Ember or React.
As for the issue of frameworks lacking stability, I frankly don't see that. Yes Angular is making big breaking changes. But otherwise? Let's look at the other 6 biggest front end libraries/frameworks.
jQuery has been fairly stable for a few years now, with minimal breaking changes.
Underscore has been very stable, albeit growing with competition/help from Lo-Dash
Knockout and Backbone have evolved slowly while remaining small and very small respectively.
Ember has a very clear process for moving their framework while allowing actively developed applications to stay up to date in a reasonable way.
React is still pre 1.0 and that's something you should know going in.
Basically if you started a project with any of those technologies (or angular for that matter) at some point in the past 3 years, you've probably had a pretty easy time in adjusting as the library specific concepts have changed.
I just don't see the idea of "Frameworks are evolving too quickly" as being particularly compelling. There's a lot of information out there. Yes if you want to know it all and always be using the newest shiny thing, it will probably be too much. But none of this is preventing anyone from actually building useful things today.
I'd say the Angular 2.0 split actually fits your first point (A lot of JavaScript frameworks are being released) rather than your second as essentially, it is a new library that shares only the name. The way I see it, Google is deprecating Angular 1.0 and creating a new library which will also be called Angular (2.0) but might as well be called something else. This bungling is rather typical of Google open source projects and I agree with the author on being aware of corporate sponsorship. I'd add to that, especially of Google, whose track record in this space (front end) is abysmal and whose track record in general as far as developer technologies is mediocre at best.
It shares more than just the name. The Angular rewrite was unavoidable if they had any hope of integrating seamlessly with web components. They also remove a lot of the concepts that people lambasted Angular 1.0 for and end up with a much more elegant framework. It seems they were damned whether or not they wrote Angular 2.0 - people would either bitch about the current framework for being convoluted in places or bitch about the new one for having breaking changes.
I don't see anything else that it meaningfully shares with Angular 1, certainly nothing that warrants keeping the name the same. What people are bitching about now is that Angular is essentially deprecated and a dead project: in other words, Google's spectacular failure at maintaining the project. That applies to both Angular 1 and 2 now, as it's clear to me and plenty of other devs that Google is simply not serious in this space (not to mention that Angular 1 wasn't all that great to begin with when used for anything but simple apps). I think it'd be foolish to choose Angular 1 or 2 at this point, knowing that there will be literally no support from the creators. Other frameworks do this as well, just not on such a short timescale.
> What people are bitching about now is that Angular is essentially deprecated and a dead project: in other words, Google's spectacular failure at maintaining the project
You keep using the term "Google" as though it represents a single, unified entity aligned on all fronts. Angular was never an official initiative within Google and its usage within Google is actually pretty limited. It's a Google framework in name only. It grew organically out of one small team's (who happened to work at Google) desire to simplify the rewrite of a very large legacy web app (DoubleClick). It's no more "Google Angular" than Bootstrap is "Twitter Bootstrap", which was another project that started within large, recognizable company but wasn't officially initiated or mandated by said company. I'm sure Google employees are sick of people lumping them into one big group and making blanket statements such as the ones you made in your comment.
> I don't see anything else that it meaningfully shares with Angular 1
Then you haven't been paying attention. Angular 2.0 still has dependency injection, directives, two-way binding, scopes, routing, and more. Directives are being renamed to match more common terminology and scopes are now just implied but these are improvements, not removals.
> I think it'd be foolish to choose Angular 1 or 2 at this point, knowing that there will be literally no support from the creators.
This is just FUD. The creators have said they will continue supporting Angular 1.0 well after Angular 2.0 is released; they even hired a few people recently to do just that. And there are core contributors out there who don't work for Google who will likely keep supporting Angular 1.0 for as long as it makes sense to. It's open source, after all. And to say that Angular 2.0 will receive "literally no support from the creators" is simply trolling.
Whether or not the creators are mainly Google based or not, it doesn't change the fact that their support is unreliable and untrustworthy. It's not trolling for me to express my opinion as such. If they're so quick to abandon Angular 1 (about 2 years since the stable release), they're likely to do it again. This isn't a technology issue, it's a trust issue. All this so they can create a more "elegant framework" that's likely to be more of the same. Also, just because the 2.0 release uses general concepts and design patterns that 1.0 also happens to use (DI, routing, two-way binding, etc.) doesn't make it an upgrade. That's akin to saying they're both Javascript, so they must have something in common. Ridiculous.
"Prefer dedicated libraries to monolithic frameworks", this is the money quote for me.
I got burned a long time ago when I wrote a large personal project using ExtJS (~1.2 i think). Breaking changes, coupled with a kitchen sink mentality soured me against large frameworks.
It's vanilla JS with a few small very targeted libraries to fill in the gaps from now on for me.
This only refers to frontend JavaScript and reflects the opinion of a dev who hasn't been using JS all that long. Angular was never that great a framework, it's popularity was by and large because it came out of Google. It's far too tightly coupled to the DOM and was therefore destined to have problems as HTML and browsers evolve.
Npm is stable, Backbone is stable, Node is stable, Gulp is great, and devs like myself who have seen trendy frameworks come and go (Batman.js and jQuery templating come to mind) are still using the same great composable tools that were better designed from the start.
Backbone (and my favorite, Spine) are built on more loosely coupled components and can be used on applications which have no DOM, such as Canvas games or native mobile apps. Browser fragmentation has been an issue since the dawn of JS -- and these days the JS ecosystem extends far beyond the browser.
Take a look at the mature tools for front or backend that major companies rely on and be glad that the open-source nature of JS produces so many options and rapid evolution.
When it doesn't work, that usually means you have to learn implementation details like the digest cycle, which flies completely in the face of having these abstractions in the first place.
Which is exactly why I always hated ASP.Net's page/control lifecycle.. it was nice for windows-ui developers, but really poor when you had to do something custom. Same for MS's Ajax Toolkit. MS is finally learning these lessons. So should everyone else.
If you have simple modular tools that do something well, and you can string them together in a productive way, it's easier to replace certain pieces.
* backed by Google
* MEAN
* plenty of media/blog coverage
* seductive examples (that don't reflect best practices)
My personal gripe is with the last point. A lot of the appeal is in the two-way binding -- which is often the first thing to go out of the window once scaling becomes a problem.
Also, I have no idea why the author thinks Browserify and Angular go well together. They don't. At all. Browserify is great on its own, but there's not really any "blessed" way of using a module system with Angular (and like jQuery Angular 1.x is tightly coupled with the global scope).
Regarding seductive examples. I recently found out, that most of the examples even example apps are lacking best practices, and in many cases even basic security measures. Good example make a e-commerce app using x and x technologies, and then disclaimer that this app is just to show how fantastic framework x is. Many frameworks js, php name it have disastrous examples, which are oversimplified for the sake of understandability, and then all hell breaks loose when someone finds out that, for example, by default csrf policy, or authorisation is not implemented correctly or not implemented at all.
Yes. This was actually an even bigger problem when I started with AngularJS because the real documentation was woefully incomplete, so there was no obvious way to learn about best practices at all (except that everyone apparently agreed that the examples weren't following them).
I haven't seen two-way binding go out the window with scaling.
It's still the number one selling point and greatly reduces development time in both small and large applications.
The only thing I've seen is that in bigger projects, if there are locations where huge amounts of binding might take place (such as drawing, tables, etc...) you don't use two-way-binding in that particular place.
And in any case many of the popular frameworks (Ember, backbone etc... ) also use two-way binding, they just don't support two-way binding on simple js objects.
And for that many of the bigger frameworks (
> The only thing I've seen is that in bigger projects, if there are locations where huge amounts of binding might take place (such as drawing, tables, etc...) you don't use two-way-binding in that particular place.
Sounds like two-way data binding went out the window then...
> It's far too tightly coupled to the DOM and was therefore destined to have problems as HTML and browsers evolve.
Maybe in the sense that the APIs will have to change as browsers evolve. But isn't there also some benefit from staying tightly coupled with the DOM? I know that React claims the fact that they are loosely coupled with the DOM is a benefit, but I'm not sure I really understand how this is inherently an advantage.
I wonder if we need any JavaScript framework at all, given how far JS has come in recent years, yes, I use an MVC framework currently for the apps I'm building but I'm writing more and more of my apps these days using nothing but vanilla JavaScript(ES-6 to be exact) and the dom apis, and I'm not depending upon any framework. (well, I use traceur but only because ES-6 support is not fully baked in to all browsers). IMO the frameworks that are all out there today are simply too big and try to do too much for you. The only libraries I use from time to time are underscore, d3 and moment.js.
This. A lot of the frameworks are doing things that can sort of be done with vanilla JS now — personally I’m waiting on Object.observe to become more widespread.
I'm finding that in many cases the old adage holds true: "You're always using a framework. Either you're using an existing framework, or you're building your own." (paraphrased)
Sure, if legacy browser support is not a concern and you don't need to support bleeding-edge features (i.e. unstable APIs), you can go a long way with vanilla JS. But at some point any large system needs abstractions in order to stay maintainable. And if you don't use existing abstractions, you'll have to come up with your own abstractions.
Of course the other option is to simply not build large enough systems to require abstractions.
That said, I do prefer smaller libraries, too. This is why I see React not being a full replacement for all of Angular as a feature rather than a limitation.
I only ever began considering Express as a framework when it dropped the vast majority of its features (mostly middleware) in 4.x, too.
Well, a custom framework might evolve when you write everything using just JavaScript, but I've found that when such a thing does happen, it suits your needs perfectly. Even if I screw up, I'll at least know where to look when I'm debugging :)
"Any sufficiently complicated collection of libraries contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a full framework"?
That sounds about right :) . However, you need a great degree of discipline (greater compared to other languages IMO), to write good JS. JS enforces almost nothing, so it's up to the programmer to design an application architecture that suits her, so it might not be as ad-hoc in real life applications after all.
This works ok if you're a single developer working alone on a project. This becomes very difficult in a larger group where you have some turnover and everyone has different backgrounds. Having a framework that makes a lot of the decisions for you greases the wheels to productivity. Give engineers an inch to bike-shed, they'll take a mile when choosing the paint color.
I think alot of the devs today have grown up with all this frameworks on top of other frameworks. The problem is you lose power with every layer of abstraction. It's the price you pay for it. They also abstract at too low a level, especially since browsers have caught up. They don't need provide a new custom ajax for instance, XHR as implemented in the browser works quite well without imposing an arbitrary syntax on top. So I think people have moved increasingly to vanilla. We've come full circle with the opinionated frameworks and some people are frustrated and where do we go now?
Web components are the most promising development, because the preferred approach in sw development has always been isolation/separation of concerns. This is pretty much the opposite of the JQuery style. In theory you can separate using JQuery but in practice still in 2014 you cannot look at source in any moderately complex web app and understand what's going on. Ultimately, its going to have to be a DOM/JS mix (Those aren't going away for a long time) but they never got it quite right. The web component frameworks are the best thing going for the future.
IMO they should be declarative, that is - in the HTML - but programmable, and that's the way things have been heading. So in 10 years we'll still have the DOM and JS (although it would be interesting to have more languages easily usable in the browser). As Polymer evolves it (or some equivalent) will make it into the browser.
This was my first reaction as well. I've tried using React but the designer in me hated having views inside my controllers. So I've ended up writing vanilla js, and a helper MVC framework: https://github.com/techlayer/espresso.js which borrows a bunch of concepts from React but is really just a tiny helper lib.
Yeah, I agree. I lost faith in Angular (Even the 1.x). From now on I'll be using React for the view and a mix of amazing smaller libraries for the rest.
By using small libraries – components with a dedicated purpose and a small surface area – it becomes possible to pick and mix, to swap parts of our front end stack out if and when they are superceded.
This is the problem with front-end dev in a nutshell. Everybody is mixing and matching their own solutions which makes it impossible for an ecosystem of higher level, reusable components to emerge. Compare this to iOS, for instance, where I can go pick and choose from a huge online library of prebuilt components and be fairly confident I can just "pod install" them and go. I'm not a fan of Angular but it was a good thing for there to be something like a de-facto SPA framework standard. I can only imagine how upset business owners that invested heavily in Angular 1 apps are feeling now.
If web developers are serious about mounting a challenge to the rising tide of native apps, they need to build some consensus and agree on some durable foundations. In the end elegance and novelty count for nothing if you don't have a healthy, stable ecosystem upon which businesses can depend. It's sad to think that the freedom that makes web dev so appealing may also turn out to be its fatal weakness.
Compare this to iOS, for instance, where I can go pick and choose from a huge online library of prebuilt components and be fairly confident I can just "pod install" them and go
I believe this is the one of the main motivators behind web components
I haven't built anything non-trivial with web components but I do like where they're going with them in principle. The biggest problem I see with WC is that they require native browser support to really function properly and I'm not sure it's really in Apple's or Microsoft's best interest to support them. AFAIK Apple hasn't made any indication so far that they will support the WC spec.
Microsoft already supports some of the WC standard and Apple will as well since it's being put into WebKit. Polymer is a great polyfill though it does have some performance issues (0.5 is much improved at least).
I think the biggest problem with WCs is they are standardizing best practices from 2011/Angular early days. Things have moved on and mutable two-way state that binds to a stateful DOM is no longer state of the art.
Having worked with web components over the past few months, yes this. I can mix and match polymer, x-* elements, brick components etc with ease. I don't have to care how a given component is written or what its dependencies are. It's definitely the future.
I can drop a jQuery calendar into a React component with minimum fuss. I think the interoperability issue only comes with components from large frameworks.
Honest question - I'm a react newbie and one thing that isn't immediately obvious is how to drop a DOM-manipulating jquery library into a React component. I'm sure I'm missing something really simple here, but do you know anywhere that's documented by any chance?
This is actually more than just web components. iOS and Android have shared application architecture, tools, and navigation between screens. On the web, we'll never have "one true" solution to these problems, but the animosity towards attempts to provide holistic solutions on par with our native brethren sure isn't helping.
If you want to evaluate anew and put together dozens (or hundreds) of tiny modules on every new project, and maintain/evolve that collection over time, fine. But we don't need to tell people that something is deeply wrong if they want a full front-end stack that evolves as the web changes. Nothing is wrong with solutions that track best practices and evolve to incorporate more common problems.
People who paid attention to Rails upgrade issues over the years saw issues with heavy frameworks that abstract a bit far from the input & output.
Simple libraries often mean less maintenance headaches, more flexibility, and better productivity over the long term. YMMV of course ;-)
Exoskeleton looks like a promising microframework replacement for Backbone.js - http://exosjs.com/
---
Edit: re: downvotes. I know, sometimes it hurts to hear there are other ways that may be more optimal. Been there. Developing software is hard sometimes but it's a craft :-)
The upgrades have been historically been quite painful. Especially from v2 to v3.
Perhaps it's better now that the api has stabilized a bit. I've been using node.js & some Sinatra lately.
Upgrades tend to be smoother & due to less monolithic libraries. Also, the app startup time & TDD cycle tends to be faster with slimmer libraries.
It's also nice to be close to http vs the ambiguous controller methods & complicated route files.
Plus ActiveRecord is slow, especially with collections. The business logic can often be implemented in simple functions, resulting is less abstraction overhead.
True, v2->v3 was hard due to escaping-by-default, but that was a long time ago. v3 to v4 was trivial and v4 to v5 looks to be similarly easy.
Also, I find business logic sql libs written by typical devs tend to be unreadable and much buggier than AR code. They start clean, but once some other devs make some edits, they end up a jumble of sql concatenation nightmares (even if you use prepared statements, and especially if you've ever switched sql dialects). Given the choice, I think I'd rather see them written as stored procedures. At least that enforces decoupling.
I agree with your other points -- less code is more better.
Can someone more invested in the SPA/rich internet application JavaScript state-of-the-art explain to me what is unappealing with the Dojo toolkit[1]? Of all the frameworks I've seen, it's appeared to have the most consistent and sustained developing, documenting, and extending efforts, over the past six years or so.
But I'd rather be programming iOS any day, so maybe my tastes in client-side application programming are very out-of-step.
Where I work we decided to avoid using libraries and frameworks, because decisions taken at that level was do not give us the flexibility to deal with the problems that we face.
The main issues we found were:
1. Change of behaviour between versions, (e.g. the way a frameworks integrate with a page)
2. Reliance on functionality being supported into the future
3. Customer expectations
4. Browser support
That said, it is true that a frameworks gives you the ability to put together an app in a few weeks. However, when you know that what deal with with something that needs to be maintained for years than knowing what does each piece of your code is far more important.
It's possible to do the same with a framework - it is also likely that frameworks and various libraries will be more performant and account for cross-browser issues. For example, I am not going to handcode JS logic with generating SVG for a graph - I'm going to use d3.
Well, sort of. It's possible if you're willing to take on maintenance of that library if/when they abandon it, and be able to dive into the guts to track down bugs or weird behaviour.
As a good example, we're on the verge of ditching JQuery.
Here's the rub though - code will not (likely) live forever. That's just the reality of software engineering.
I always have to dive into the guts of a library to figure out bugs regardless - I feel like that's essential for a software engineer to become well versed in, regardless of whether the work is in frontend or backend.
The cost of not producing at a fast enough rate is something almost no business can afford, especially in the startup world. The speed at which companies have to move are always on full thrust because if they don't move fast enough, then it costs sales, reputation, and gives competitors more of an opportunity for market entry.
Homerolling your own framework/library can be a dangerous operation, and you lose the benefits of the lessons that others have learned in maintaining open source frameworks/libraries.
Seems relatively accurate to me. I understand the lean towards tiny fragments, there is less upfront investment / easier learning curve; this reduces risk. Perhaps with time we will see intermediaries emerge between light libraries and heavy frameworks - eg combinations of the former into subsets of the latter, suited for less general development.
open source has won, we are innovating at faster and faster speeds than ever before, and the best innovations eventually bubble up to the top, bad ideas get peer reviewed out and thrown away before the whole world depends on them, this is amazing!
I for one am perfectly able to track all this innovation within my specialties (enterprise web dev) across multiple language ecosystems, and if I miss something, someone in my monkeysphere will make me aware of it, all of this fuss sounds like hot air to me.
Maybe because you're primarily a front-end developer? If front-end is not your fulltime job it's really hard to keep up with all the new frameworks and changes.
Agreed. I'm an enterprise dev who tries to keep a finger on the pulse but it can be quite difficult. I take my eye off the ball for 6 months and it turns out grunt is no good?! etc etc.
I completely agree with this post that there is churn fatigue. Part of that is in libraries, but an even bigger part of it is in the tooling that people use to build JavaScript applications.
It's easy to see all of these new things flying by, combined with changes to JavaScript itself, and feel completely overwhelmed. To be honest, over the past two years, even as a maintainer of Ember, I have experienced very serious hype fatigue.
This is a large part of the reason behind Ember's philosophy of finding and implementing strategies for stability without stagnation. On the one hand, people (including us) are tired of the constant barrage of new tools and techniques. On the other hand, it would be terrible to get beaten by a competitor that discovered a wonderfully productive new solution. The Ember team has spent the last few years honing a process for dealing with these conflicting desires.
That process involves:
* six-week release cycles, so every new change is incremental and adds value on its own
* canary, beta, and release channels (just like browsers), so that people will more appetite for churn can help test out features, and get them stable by the time they ship as part of a final release
* SemVer, so upgrading across final releases is relatively painless and the biggest part of our community can take advantage of the improvements as they roll out
* having each member of the core team build apps that we care about and maintain, so that we can feel the competing costs of maintenance and keeping pace with the latest and greatest first hand
The core ideas come from shipping browsers, which have had to deal with requirements of very strong stability with an increasing desire to "go fast". The pace of new browser features has been so good, in fact, that they have been used as an argument in favor of completely breaking things and starting over.
Ironically, the browser instead shows us that if we want to avoid stagnation, we are going to have to have strategies for bringing people along. Stability without stagnation is not a paradox; it's a recipe for success.
Additionally, in this case wycat's points are highly relevant to the topic at hand; the article is about churn, and wycat talks about how he addresses that problem in the context of a JS framework.
The last time I talked on Hacker News about Ember was in the comments about Ember 2.0. Before that: months ago. Most of my recent comments have actually been about Rust, not JavaScript at all!
telemarketer is, IMHO, clearly tongue-in-cheek, so don't take it personal, please. I found it funny because I fail to see how the tips pertain to JS, while they are worthwhile nonetheless - and I hope that was the commenters intent, instead of aggrevating anyone (e.g. for mentioning ember without it adding anymore insight than an argument of authority. edit: although, anecdotal evidence is welcome.)
It can be difficult to not self-promote when you feel strongly about the utility and quality of something you work on.
And, we being somewhat to relatively smart people, can forgive the unmasked market-speak to appreciate the value of the personal experience wycats is sharing.
FYI: Yehuda and Tom talked to us about "stability without stagnation" and other philosophies behind Ember 2.0 in episode 131 of The Changelog: http://thechangelog.com/131
If the new tools and techniques were actually good, they would be enough for a while, and people wouldn't feel the need for even newer tools and techniques the next week.
This should be an obvious and automatic hype-temperer, but for some reason it isn't.
Interesting that the same problem (high churn) leads to two polarly opposite conclusions - i.e. the article suggests going with many specialized libraries, whereas Ember is on the camp of incorporating the latest and greatest into a single framework when it makes sense.
My opinion is that some types of features are better off bundled in a ready-to-go package. For example data binding and ajax almost always go together and just plopping a CDN link to Angular is a lot easier than installing NPM, setting up a file watcher and who knows what else to get React's JSX running (and you still need to go decide what you're going to use for AJAX).
Other less "core" types of features are better off as standalone libraries because their depth of usage can vary from not being used at all to requiring very domain-specific features (e.g. accounting.js is a good example of this). I don't agree with the author's premise that micro-libraries are easier to swap. I'd be very doubtful if anyone were to claim that it's trivial to convert a React codebase to Knockout, for example. You'd likely be hard-pressed to swap even things like moment.js because you probably chose the library based on it being better than its alternatives to begin with.
But having these types of features be standalone libraries does provide some benefits, e.g. being able to opt-out of a breaking release in a more granular fashion, trial-and-error-oriented development, etc.
Good zeitgeist. I feel compelled to give my $0.02 as I was quoted in the blog as someone who "frankly feels completely overwhelmed." However, my criticism will be more from a programmer's perspective not so much a "web application developer" perspective.
Re: the chaos/churn in Javascript, forgetting for a minute the buzz-words of Backbone.js, React.js, Ember.js, Gulp, Angular etc. - they seem all to be a fight about MVC, traditional vs. single-page app vs. isomorphic.
I fail to see how improvements in these tools actually push us to create novel projects. While one can nit-pick about React.js rendering performance in its internal "DOM diff" model or Flux's "data flow architecture" in improving code readability, but they are just buzzwords to me like words-play in a post-modern novel or art that arrange concepts in their idiosyncratic way in an arbitrary aesthetic way; although sometimes the rearrangements can be beautiful, they are ultimately shrines to themselves and their creators and subculture.
Subculture because everyone wants something of their own and ignore interoperability. Although the data model are the same whether you're a single-page or isomorphic, there is no community standard to define standards to define your data models a la J2EE annotations or code-generated one's a la Google Protobuf. Same thing with single app controllers, no standard like RESTful web service spec that's universal and interoperable like between .net/Java/Python etc. that can be applied to say, Sail/Backbone/Ember/Angular.
Postmodern because they are always self-referential to the "Ember.js"/"Node.js" way of doing thing - when they all do the same thing which is rendering HTML elements on the web browser in 2014, much like Visual Basic rendering forms on Windows 95 desktop in 1997. Never mind all the touts about performance, architecture, when the users won't care about the diminishing return of shaving off some microseconds of your AMD JS module loading or the beauty of your invisible architecture.
IMHO, instead of a race to the bottom to the most "efficient" and "beautiful" stack to render HTML, I care more about the ideas that push the web as a medium, e.g.,
An alternative direction to head is back to the future: take the web for what it is and try to simplify AJAX interaction, rather than relearn all the hard lessons of client/server programming from the 80's, but in a hobbled browser sandbox.
One of my main problem with javascript frameworks is having to drift away from the original server HTML. Not everybody wants to go the whole way down the Single Page Abbit hole. It's not only a question of speed or SEO.
I think many devs are both backend & front-end craftsmen, and as so build the backend first and then wish to 'grow' their frontend part on that foundation. Or ideally wish they could. Instead they have to fork the project into 1). the Good Ol' server HTML part 2). the API SPA part.
No matter how close angular or react (with jsx) stays to HTML, you still need to rewrite the whole view to comply with it's templating needs. There's no incremental evolution there, and worse : having to duplicate and sync maintenance on both ends, breaks the DRY principle which is fundamentally bad - since you end up with 2 sources of truth.
Pre-rendering the view with react on node (even if your on rails or whatever) may be a solution I don't know yet. Another take I guess would be to render your server html files with a template which complies with their JS counterpart. Yet another take would be to use HTML as the API instead of JSON - which is proven to work quiet well.
Anyways, just to conclude I think devs would feel more confident if they could rely a little more on the servers end while the frontend finds its ways and stabilizes a little.
Exactly. Rewriting views is something I really don't want to do. Example: I'm building pages server side and using AJAX PATCHs to update data on the server. The server responds in JSON with a html attribute contaning the very same HTML Rails partial used to create the page. This spares me from having to build a SPA (which for many reasons is not OK in this project) or two different views, one Ruby and one *.js which would be unbearable (as you wrote).
I looked at intercooler supeficially with the hope it could be a foundation to standardize my AJAX calls (I did something myself but it still fluid). I'm not sure I like the way it puts so much information in the attributes of the DOM elements actions are bound to, but I'll keep reading. I prefer doing those stuff all in JavaScript and minimize the impact of frameworks on the DOM. It's still no time to commit to any of them. Let's wait until the dust settles.
An alternative direction to head is back to the future: take the web for what it is and try to simplify AJAX interaction, rather than relearn all the hard lessons of client/server programming from the 80's, but in a hobbled browser sandbox.
For an even more retro approach, perhaps some things are just better written as desktop apps. I know they're out of vogue at the moment, but I've been having good experiences with writing a JavaFX app lately. Particular points to note:
* I wrote my own online updates engine, that can be used to implement Chrome/Web style silent background updates, but which can also give control to the user over which version of the app they use. Users can downgrade at any time if a new version is buggy or just not as good as the previous version. It's very small, simple and easily integrated. It supports threshold signed updates so it's also suitable for high security apps where a hacked web server could be critical. It's called UpdateFX, check it out.
* JavaFX has a tool that creates native, bundled installers on each platform (dmg, exe/msi and deb). The user does not have to install JVMs or get any Ask Toolbar crap on their system. You remain in total control over JRE upgrades.
* UI is specified with an XML dialect called FXML, it's quite intuitive and anyone who knows HTML can pick it up quickly. But there's also (unlike with the web) a competent visual designer. You can style UI with a dialect of CSS and it's very easy to match the Twitter bootstrap look, native looks can be done too.
* Data binding is easy, the UI is OpenGL/Direct3D hardware accelerated, you can trivially apply effects like drop shadows or blurs and animate them, the API is clean, the entire framework is open source and the developers are responsive.
* Because it's not a web app, support for offline or flaky internet connections is second nature.
If your users can tolerate the initial download then it's a much more pleasant and robust development experience. If your users are the type who can't wait, you might want to stick with the web.
I will say, a well done client/server app is much more difficult to implement robustly than a web app. And, horror of horrors, users usually expect you to implement... undo!
Higher expectations are the major issue: undo being the canonical example. The general problem of distributed system data synchronization is another: things tend to demo well enough on a local development instances, and then fall to pieces in the unreliable field. Showing synchronization status, merging changes in a semantically correct way, useful UX affordances around all this, etc. is all very difficult work.
Of course it all depends on the domain and architecture of the app in question, so counter-examples and exceptions are easy enough to find.
You always have the option of simplifying by writing the app in the "web style" where it simply refuses to run if it can't connect to the server (if there even IS a server).
Of course, people might indeed think that's lame and sucky whereas they'd forgive it for a web app. This is one reason I made my app visually look like a web app e.g. no menu bars and a bootstrap/web style button/popup aesthetic. If it looks like a duck, people are more forgiving if it quacks like one sometimes too :)
I'm not sure that is true, a lot of apps use web technologies on the inside. The more interesting part is that most seem to choose native not because of the development story but because they need to reach some special API or really want to keep the UI very close to examples from the platform manufacturer. It is actually a problem to go native when you have to develop multiple versions of each application which might totally lose any advantages the native coding experience has over html+js.
The improvements in these tools aren't supposed to push us to create novel projects. They're supposed to get out of our way. Some do better than others, and some paradigms can be more helpful than others. It makes sense that we have competing ideas and competing frameworks to implement those ideas.
Some projects get a bit flashy and buzzwordy, it's true. Bacon.js [0] always sticks out in my mind as a prototypical example, though I think it's tongue-in-cheek.
I try not to let that flashiness get in the way, though. The fact is, Bacon.js is useful to me, when I try to make beautiful and efficient code to render beautiful and efficient HTML. Their homepage doesn't change that. React's performance is impressive, and may be important to me; ditto with Flux and code readability. And the theories underlying those libraries (DOM diff and unidrectional data flow) are important too, so I know why I should expect them to be better.
To me, it is not at all alarming. But it might be due to my inexperience in dealing with truly huge code bases.
No matter what framework, in the end it's all JavaScript. So even if I develop a flashy app using a nice fat framework, it is still going to run unless JavaScript itself is changed.
That said, I can build an app in Angular today, and when something flashier comes out, I can code new features/modules to my app using that.
I think the main problem is about fixes. Invariably, something is going to go wrong in the future with whatever framework you use. Either security related or else. Then your version of {{framework}} won't be supported anymore and you'll have to:
- fix it yourself
- give up: turn off your app
- ignore: let people deal with the issue/be vulnerable
If your version of {{framework}} is supported, likely all you'll have to do is wait for a patch.
My stance has been to take a more static view of an applications development life cycle. So you're on an Angular 1.x app, Angular 2 is coming out in a year, your project will be launched or is already launched and you're concerned with switching.
Stop, right now, just let it go, take a step back from the bleeding edge and see that you've got all the JavaScript libraries and tools you need to put together any application you could imagine. If your imagination is big enough then you'll be hand writing your own additions in no time. So long as your applications runs on the major browsers latest-1 without issue there isn't a reason to upgrade. If you're writing a project there isn't a reason to make a framework jump, and if Angular 1 to 2 is that different, consider it a framework jump. Why feel bad about not knowing your way around when you go from one framework to another, would you feel the same going from Drupal to Wordpress? They are both CMSs, both PHP, both extended far beyond their initial goals. Angular 1 will go into maintenance if Angular 2 is that different, development will slow, and eventually you'll upgrade to Angular 3, which is incompatible with Angular 2, but after years of having a working application.
I've gone from Angular, to Kendo, to Ember, to Backbone. If you want to make an 'investment' in knowledge of front-end development learn the plain JavaScript, read through the framework you're using. Walk through the execution, that will allow you as a developer-for-hire to pickup the newest shiny on a new team with less issues.
Web development has always had this pace, whatever tool or setup you commit too, the next week someone will call you an idiot for using it. Ignore them, make something maintainable, nothing in the new framework is ever mission critical, just nice to have.
I completely agree with this. Make sure you know the ins and outs of what's out there, but don't just follow trend blindly. Especially with a large team, or internal eco system.
I make a habit out of using smaller frameworks that gets the job done, and only that. Anything else or beyond, we code ourselves, or re-use from a different project. Or we just stick with older technology because we know it works. Sure, our productivity might initially be lower, but at least we save ourselves the pain of "the next big thi—oh wait, something new arrived let's switch".
Exactly... I worked on a project a couple years ago, and decided to use a beta version of bootstrap as the baseline for the project... I cloned the repo, merged the pieces into my project, and kept a copy of the docs at-that-time for reference.
The site still works great... the codebase is fine. It was before some later changes to bootstrap 3, so it isn't current with the released version, but it still works, and did better so than v2. The same goes for most things involving open-source tools. You can go through migration cycles, or accept and limit the scope of how you use it.
I always applied the same arguments for using Mono in places as a practical reasoning. So what if new development stopped/dropped or rolled.. as long as what I'm doing can keep running.
Your best bet is to keep your codebase modular so much as possible, and it makes it easier to replace certain pieces.
Today, I really like react + yahoo's flux implementation. There are some weird corner cases I've had to deal with, it's still nice. It really just depends on your needs.
The whole "use lots of little modules" idea is great on the surface, but when you have to build large applications with small teams, I find it fails:
- There are always multiple choices for each piece of functionality you need to address, and personality clashes over which is the "best".
- Security is a whole lot harder to nail down with more moving parts. Go with Angular, you have this: https://code.google.com/p/mustache-security/wiki/AngularJS. Similarly, Ember: https://code.google.com/p/mustache-security/wiki/EmberJS. Even though these frameworks aren't 100% secure (although Angular comes pretty close), you can be more aware of the pitfalls. The more independent modules you have to keep track of in your app, the more difficult it becomes to track security flaws.
- Some seemingly unrelated components just don't end up playing nice with each other, and this can be hard to determine ahead of time.
I feel sorry for those stuck in web development. Native apps always were and still are the way to go. Appstore/Play and soon Windows 10's inevitable blastoff to mass popularity will bring a popular appstore to all 3 major platforms.
As the article states, there was a time a few years ago that js-all-the-things appeared interesting and unstoppable. To me it appears in 1 year when Win10 arrives, people will have better spent their time honing skills for native apps.
Webapps as people envision them (universal applications) will die- returning to their original intention. Document sharing and simple data collection/retrieval.
Blame Eich and Mozilla for that. They insisted on pushing no bytecode for the web. Wanting us to rely on Eich's JS + rest of the webstack monstrosity requiring ugly hacks.
I don't see (comparatively) a lot of people targeting the Windows 8 app store that's been available for 2 years already. Most Windows deployment is either ad-hoc exe's or centrally administered msi's. What's changing with Windows 10?
Win10 and it's (likely) XP/7 popularity level is a dark horse for native apps, and looming blow for the webapp movement. Which I believe has gotten a very long free-pass thanks to the most popular platform not having a cohesive appstore ready (on a popular OS).
Win8 IMO is almost irrelevant, the marketshare isn't there to add a MS Store option for me or many others. The corporations haven't and won't hop on. Everyone is (IMO rightly) focused on iOS/Android/web at the moment. Agreed on MSIs, but I'd add the customizable corporate frontend stores should be more powerful and slick than the current method (same appstore for MS desktop and mobile). It's possible once enterprise moves to the MS Store that MS mobile devices make major inroads.
For consumers, I think they'll rejoice at Win10, upgrade to it and by default go to the MS Store for security reasons alone. Not to mention auto-updates, same apps as on MS mobile etc.
I'm not pro-MS, I'm actually anti-all-for-profits and a Mozilla fanboy. I just disagree with Eich on a bytecode for the web, he blew it as far as the web being the prime delivery mechanism for apps is concerned. The webstack sucks, it had to go. Too late now.
I understand my view isn't popular at the moment. Especially among webdevs who are most likely to be reading this HN post. Those people have invested heavily in the webapp dream with their time, skills and careers. Anything to the contrary that it was a great idea is going to get downvoted. Regardless, I think this is an accurate reading of the foreseeable future.
Your prediction relies on a windows app store somehow making the web irrelevant which is amazingly unlikely and counter to every trend of the last 20 years. I suspect you have some emotional investment in the Microsoft ecosystem that is coloring your perspective.
My prediction is that your prediction is dead wrong. Nothing will stop the web, certainly not your app store dystopia, and certainly not the way Microsoft would run it.
I never spoke in absolutes, as you are. I said it was a blow to the webapp movement. Webapp movement defined here as a universal application deployment.
Presuming about my intentions or feelings towards the MS ecosystem is ridiculous. I had courses on VB6 in the late 90s, that's the closest and most exposure I've ever had to their ecosystem. I do wish I knew C# now that .Net is merging with Mono though. I see no shame in that. I don't hate MS anymore than I do Google, Apple, Oracle or ANY for-profit. For-profit means not-in-my-best-interests.
"Nothing will stop the web" sounds way too much like the idiotic quote, "always bet on JS". I'm not betting on JS with Eich, but I'm not against the web. Certainly my HN post of what I think will happen, won't affect that outcome.
I'm with (I believe) most everyone in supporting webapps being the universal delivery mechanism for apps in the future. Where did I say I wasn't? I also think there was a limited window of opportunity for this to take off. That window roughly being 2004-2014. Today, native apps are still on top.
Webapps will continue on in some form. But with Apple and Google already having appstores, will a popular version of Windows with an appstore be the closing of that door? That door being defined as webapps becoming the dominant application delivery platform. Yes, I think so.
But as of today, I fully believe webapps were/are hobbled during their glory years by the webstack, the web needed a bytecode.
If someone merely looking at circumstances and speaking on them bothers you so much, you are likely someone who speaks only to persuade others to your viewpoint. I'm not trying to persuade you and don't care where you stand. Frankly, I'm more than likely aligned with your views on webapps. I just personally find the webstack inconducive with the goal.
Action needed to be taken at a high level (likely at Mozilla, to make the webstack legacy and introduce a new bytecode standard), in a window of opportunity while the last major player (MS) was essentially out of the appstore business. I don't see it happening in time now. We'll see, but I predict it is you who has an emotional investment in the webstack.
Isn't half of newer windows apps/widgets are just html wrappers, something similar to smart desktop or how they called it in win95/98? Haven't used windows for longer than it needs to switch on IE8 for more than 2 years.
I work on both apps and the web. My preference and long-term bet is definitely on the web - app stores are mostly a tool for locking customers in; they're superficially attractive to both customers as devs, but in the long run they're also too restrictive for both and too tied to the interests of the app store producers - the Apple app store for example has been used to effectively ban alternative browsers, force Google apps to be second class citizens on the store, stop Amazon from selling ebooks with a buy button in their app, etc, etc - all actions which are in the interests of Apple, but not of customers or developers. That's before you get into the problems of rewriting your stack n times because the different platforms want to force you into using their stack to develop with and constantly work to make creating a cross platform product infeasible, with n increasing each time a new device is announced.
For all the faults of web development, I also prefer it over having to work within the blessed stack chosen for me by the OS vendor, and being forced to migrate every few years as they decide their old stack isn't worth maintaining (secretly I wonder if this constant churn is not also useful to them on some level, it stops app devs every considering other platforms, they're running just to stay still). In contrast web development means you can choose your own tools, you are not limited to using javascript if you don't subscribe to this latest fad that all logic must be in the front-end written in javascript (which never appeared interesting and unstoppable to me at least), and adhere to the original interfaces of the web which was so dumb and simple it was incredibly powerful:
Simple text files (markup, styles) sent over the network to the client, which interprets them in a predictable way to show your UI and data (the predictable part has improved much over the last decade).
I do agree with you though that not having a bytecode for the web is a severe restriction on front-end development, and means that I prefer doing backend web work and using js in a limited way for ajax etc, not trying to use it to generate entire documents/UIs. Personally I find JS is fine for limited tasks, but not for writing apps in without quite a lot of pain. I expect that to be addressed at some point soon though, either by asm.js (not optimal), or something like Nacl. Till then, it's bliss working in whatever tools I want on the backend, even switching out tools if I want to, without the end user even knowing that I'm using a different stack - to them what is important is the app, not what it is written in - that is as it should be, and not something you see on other platforms. That's the attraction of web development for me, and one that native development will never equal.
I disagree that webapps will die - I think they'll just evolve and eventually will become universal applications based on HTML. Javascript will die, but not the web. However that is really a political question about how hard OS vendors will push users towards native apps (where they make money both from sales and more importantly from lock-in).
Will OS vendors continue to dominate computing? I think that's a more interesting question, and one we'll see play out over the next few decades. The web may yet reduce native platforms to a set of badly debugged device drivers.
Good god, let's hope this dystopian future you speak of doesn't actually come to pass. Can you imagine having to launch a separate native app for Hacker News, Facebook, Github, Amazon, Ebay, etc, all of which go far beyond "document sharing and simple data collection/retrieval"? I think you are grossly overestimating the usability of having so many desktop applications and glossing over the pain in the ass it is to develop multiple versions of said applications just to be cross-platform.
> Can you imagine having to launch a separate native app for Hacker News, Facebook, Github, Amazon, Ebay, etc
Best I'm aware, a lot of these apps exist already. The step we've yet to reach is "having to launch" instead of merely being able to launch. We probably will for some of them, though.
Speaking for myself, the dystopian present and near-future has me a lot more worried than a hypothetical future with apps: I've lost count of the number of websites which used to work fine on a 1st gen iPad and which now either refuse to work on grounds its browser is too old (e.g. Github), or outright frequently crash its browser owing to out of memory errors due to excessive use of javascript (e.g. most news site).
> Best I'm aware, a lot of these apps exist already.
Very few people use them, however.
> I've lost count of the number of websites which used to work fine on a 1st gen iPad and which now either refuse to work on grounds its browser is too old (e.g. Github), or outright frequently crash its browser owing to out of memory errors due to excessive use of javascript (e.g. most news site).
The situation isn't that great for native apps either. Most times, you're lucky if an app has targeted more than just one platform. And try running modern native apps on the 1st gen iPad; developers leave old tech in the dust regardless of which platform their targeting.
I will agree that web apps need to get better in general and work within the constraints of the browser, and that news sites should have as little complicated javascript as possible (or at least sensible fallbacks), but that's not a reason to throw the baby out with the bathwater. For a wide swath of applications, the web is the only truly ubiquitous deployment target and when done right (Netflix, Amazon, Facebook, Hacker News, etc) web apps can reach a much larger user base for same development time than native apps can.
227 comments
[ 2.9 ms ] story [ 271 ms ] threadI see no reason why that would differ in the JavaScript world - whether it be front-end or back-end. Angular's changes may have burned a lot of developers but it could just be teething problems - learnt some critical lessons on the first round and resolving them before it's too late. I fully expect to see a solid MVC framework on the backend, whether it's Sails.js or something else that comes along.
AngularJS scales really well on gigantic applications, and it felt like there was going to be some stability from the corporate-world, but now it's gone.
Frontend code is so hard to maintain well (compared to backend), and now it's going to cost companies millions of dollars to migrate: retraining, migration, unit-testing, QA
sigh...
Web Components looks hugely promising as the path for independent components - essentially what Angular directives were meant to be in the absence of such browser technology.
I don't remember ever seeing anything like this level of churn, and I've been programming since the early nineties. Not with Java, not with Python, not with anything.
Someone above mentioned rolling their own stuff with vanilla JS (which provoked an immediate invocation of Greenspun's tenth rule). My sense is that a lot of people start out this way and say, "Lo, a library! Github!"
One hopes that the cream rises to the top, but I'm drowning in milk.
Sigh... with AngularJS 2, I'm shuddering at all the unit tests that will have to be rewritten.
Two years ago I decided that the best course of action would be for me to really dig into HTML and CSS, and ive been learning vanilla JavaScript as well, and that combination has worked and will continue to work. Im leery of anything I couldnt write myself, but if I can take an existing library and expand on it and make it my own that saves me time and I know I wont have to worry about compatibility changes down the road.
For past 4 years, there is NPM, and there is people trying to explain why you should build your software with modules instead of frameworks.
I know, this will probably evoke a "No true Unixman" response, maybe even with pointers towards the Plan 9 highlands, but the truth is that a) connecting stuff is hard and b) a good connection is often a prime feature itself.
Especially the latter will result into a plethora of modules of its own, for nearly all possible combinations of component modules. The end result is even more "frameworks". Sure, they're going to be modular frameworks, but I don't really know whether that's going to help the developers who live in the uncanny valley of mostly knowing what's there and how it connects.
A "fat kernel" with lots of "satellite modules" might be a viable approach, too. Just like with most programming languages (i.e. not C or JavaScript), where you've got plenty of useful stuff in your standard library, and some package manager for the rest.
But hey, if the JavaScript ninjas finally figure out how to properly combine software components, that would be better for all of us. I just wouldn't bet on that.
On a more general pov, the debate between "integrated design" and "modularized" design has been going on for decades. We know the advantage of both. The problem right now is that angular made a desition to break compatibility in a major way while their framework was barely becoming mainstream. Let's not make it a bigger problem.
People that invested in the .net framework, or in the unity framework, did not make a blunder. All we need is an equivalent in the front end js world.
1. A lot of JavaScript frameworks are being released 2. JavaScript frameworks are being updated too fast.
His biggest example, the Angular 2.0 split, is of the second one, but he seems primarily concerned with the first one.
I can see the first one being a problem primarily for developers keeping their skills up to date. The fact is that once you've put a decent amount of code down into an application, you're not going to be constantly switching frameworks. Maybe do it once, but otherwise the applications that are already built will stay on a stable foundation. So for developers working on a single or stable set of applications (not client work), this shouldn't effect their actual work. There may be an issue of skill decay if employers are constantly looking for the latest and greatest, but outside the Silicon valley bubble, I still see a lot more jQuery and Backbone job postings than Ember or React.
As for the issue of frameworks lacking stability, I frankly don't see that. Yes Angular is making big breaking changes. But otherwise? Let's look at the other 6 biggest front end libraries/frameworks.
jQuery has been fairly stable for a few years now, with minimal breaking changes.
Underscore has been very stable, albeit growing with competition/help from Lo-Dash
Knockout and Backbone have evolved slowly while remaining small and very small respectively.
Ember has a very clear process for moving their framework while allowing actively developed applications to stay up to date in a reasonable way.
React is still pre 1.0 and that's something you should know going in.
Basically if you started a project with any of those technologies (or angular for that matter) at some point in the past 3 years, you've probably had a pretty easy time in adjusting as the library specific concepts have changed.
I just don't see the idea of "Frameworks are evolving too quickly" as being particularly compelling. There's a lot of information out there. Yes if you want to know it all and always be using the newest shiny thing, it will probably be too much. But none of this is preventing anyone from actually building useful things today.
You keep using the term "Google" as though it represents a single, unified entity aligned on all fronts. Angular was never an official initiative within Google and its usage within Google is actually pretty limited. It's a Google framework in name only. It grew organically out of one small team's (who happened to work at Google) desire to simplify the rewrite of a very large legacy web app (DoubleClick). It's no more "Google Angular" than Bootstrap is "Twitter Bootstrap", which was another project that started within large, recognizable company but wasn't officially initiated or mandated by said company. I'm sure Google employees are sick of people lumping them into one big group and making blanket statements such as the ones you made in your comment.
> I don't see anything else that it meaningfully shares with Angular 1
Then you haven't been paying attention. Angular 2.0 still has dependency injection, directives, two-way binding, scopes, routing, and more. Directives are being renamed to match more common terminology and scopes are now just implied but these are improvements, not removals.
> I think it'd be foolish to choose Angular 1 or 2 at this point, knowing that there will be literally no support from the creators.
This is just FUD. The creators have said they will continue supporting Angular 1.0 well after Angular 2.0 is released; they even hired a few people recently to do just that. And there are core contributors out there who don't work for Google who will likely keep supporting Angular 1.0 for as long as it makes sense to. It's open source, after all. And to say that Angular 2.0 will receive "literally no support from the creators" is simply trolling.
I got burned a long time ago when I wrote a large personal project using ExtJS (~1.2 i think). Breaking changes, coupled with a kitchen sink mentality soured me against large frameworks.
It's vanilla JS with a few small very targeted libraries to fill in the gaps from now on for me.
Npm is stable, Backbone is stable, Node is stable, Gulp is great, and devs like myself who have seen trendy frameworks come and go (Batman.js and jQuery templating come to mind) are still using the same great composable tools that were better designed from the start.
Backbone (and my favorite, Spine) are built on more loosely coupled components and can be used on applications which have no DOM, such as Canvas games or native mobile apps. Browser fragmentation has been an issue since the dawn of JS -- and these days the JS ecosystem extends far beyond the browser.
Take a look at the mature tools for front or backend that major companies rely on and be glad that the open-source nature of JS produces so many options and rapid evolution.
When it works - works fine. When it does not work you are completely helpless.
If you have simple modular tools that do something well, and you can string them together in a productive way, it's easier to replace certain pieces.
* backed by Google * MEAN * plenty of media/blog coverage * seductive examples (that don't reflect best practices)
My personal gripe is with the last point. A lot of the appeal is in the two-way binding -- which is often the first thing to go out of the window once scaling becomes a problem.
Also, I have no idea why the author thinks Browserify and Angular go well together. They don't. At all. Browserify is great on its own, but there's not really any "blessed" way of using a module system with Angular (and like jQuery Angular 1.x is tightly coupled with the global scope).
It's still the number one selling point and greatly reduces development time in both small and large applications.
The only thing I've seen is that in bigger projects, if there are locations where huge amounts of binding might take place (such as drawing, tables, etc...) you don't use two-way-binding in that particular place.
And in any case many of the popular frameworks (Ember, backbone etc... ) also use two-way binding, they just don't support two-way binding on simple js objects. And for that many of the bigger frameworks (
Sounds like two-way data binding went out the window then...
Maybe in the sense that the APIs will have to change as browsers evolve. But isn't there also some benefit from staying tightly coupled with the DOM? I know that React claims the fact that they are loosely coupled with the DOM is a benefit, but I'm not sure I really understand how this is inherently an advantage.
Sure, if legacy browser support is not a concern and you don't need to support bleeding-edge features (i.e. unstable APIs), you can go a long way with vanilla JS. But at some point any large system needs abstractions in order to stay maintainable. And if you don't use existing abstractions, you'll have to come up with your own abstractions.
Of course the other option is to simply not build large enough systems to require abstractions.
That said, I do prefer smaller libraries, too. This is why I see React not being a full replacement for all of Angular as a feature rather than a limitation.
I only ever began considering Express as a framework when it dropped the vast majority of its features (mostly middleware) in 4.x, too.
How about:
"Any sufficiently complicated collection of libraries contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a full framework"?
;-)
Web components are the most promising development, because the preferred approach in sw development has always been isolation/separation of concerns. This is pretty much the opposite of the JQuery style. In theory you can separate using JQuery but in practice still in 2014 you cannot look at source in any moderately complex web app and understand what's going on. Ultimately, its going to have to be a DOM/JS mix (Those aren't going away for a long time) but they never got it quite right. The web component frameworks are the best thing going for the future.
IMO they should be declarative, that is - in the HTML - but programmable, and that's the way things have been heading. So in 10 years we'll still have the DOM and JS (although it would be interesting to have more languages easily usable in the browser). As Polymer evolves it (or some equivalent) will make it into the browser.
Sounds like React. WCs templates aren't programmable that's a DSL that is specific to Polymer.
This is the problem with front-end dev in a nutshell. Everybody is mixing and matching their own solutions which makes it impossible for an ecosystem of higher level, reusable components to emerge. Compare this to iOS, for instance, where I can go pick and choose from a huge online library of prebuilt components and be fairly confident I can just "pod install" them and go. I'm not a fan of Angular but it was a good thing for there to be something like a de-facto SPA framework standard. I can only imagine how upset business owners that invested heavily in Angular 1 apps are feeling now.
If web developers are serious about mounting a challenge to the rising tide of native apps, they need to build some consensus and agree on some durable foundations. In the end elegance and novelty count for nothing if you don't have a healthy, stable ecosystem upon which businesses can depend. It's sad to think that the freedom that makes web dev so appealing may also turn out to be its fatal weakness.
I believe this is the one of the main motivators behind web components
If you want to evaluate anew and put together dozens (or hundreds) of tiny modules on every new project, and maintain/evolve that collection over time, fine. But we don't need to tell people that something is deeply wrong if they want a full front-end stack that evolves as the web changes. Nothing is wrong with solutions that track best practices and evolve to incorporate more common problems.
Simple libraries often mean less maintenance headaches, more flexibility, and better productivity over the long term. YMMV of course ;-)
Exoskeleton looks like a promising microframework replacement for Backbone.js - http://exosjs.com/
---
Edit: re: downvotes. I know, sometimes it hurts to hear there are other ways that may be more optimal. Been there. Developing software is hard sometimes but it's a craft :-)
Perhaps it's better now that the api has stabilized a bit. I've been using node.js & some Sinatra lately.
Upgrades tend to be smoother & due to less monolithic libraries. Also, the app startup time & TDD cycle tends to be faster with slimmer libraries.
It's also nice to be close to http vs the ambiguous controller methods & complicated route files.
Plus ActiveRecord is slow, especially with collections. The business logic can often be implemented in simple functions, resulting is less abstraction overhead.
Also, I find business logic sql libs written by typical devs tend to be unreadable and much buggier than AR code. They start clean, but once some other devs make some edits, they end up a jumble of sql concatenation nightmares (even if you use prepared statements, and especially if you've ever switched sql dialects). Given the choice, I think I'd rather see them written as stored procedures. At least that enforces decoupling.
I agree with your other points -- less code is more better.
But I'd rather be programming iOS any day, so maybe my tastes in client-side application programming are very out-of-step.
[1]: http://dojotoolkit.org
1. Change of behaviour between versions, (e.g. the way a frameworks integrate with a page)
2. Reliance on functionality being supported into the future
3. Customer expectations
4. Browser support
That said, it is true that a frameworks gives you the ability to put together an app in a few weeks. However, when you know that what deal with with something that needs to be maintained for years than knowing what does each piece of your code is far more important.
As a good example, we're on the verge of ditching JQuery.
I always have to dive into the guts of a library to figure out bugs regardless - I feel like that's essential for a software engineer to become well versed in, regardless of whether the work is in frontend or backend.
The cost of not producing at a fast enough rate is something almost no business can afford, especially in the startup world. The speed at which companies have to move are always on full thrust because if they don't move fast enough, then it costs sales, reputation, and gives competitors more of an opportunity for market entry.
Homerolling your own framework/library can be a dangerous operation, and you lose the benefits of the lessons that others have learned in maintaining open source frameworks/libraries.
Yes. Only the code you wish wouldn't!
(seriously. I'm maintaining complex logic in ant. AUGH MY EYES)
I for one am perfectly able to track all this innovation within my specialties (enterprise web dev) across multiple language ecosystems, and if I miss something, someone in my monkeysphere will make me aware of it, all of this fuss sounds like hot air to me.
It's easy to see all of these new things flying by, combined with changes to JavaScript itself, and feel completely overwhelmed. To be honest, over the past two years, even as a maintainer of Ember, I have experienced very serious hype fatigue.
This is a large part of the reason behind Ember's philosophy of finding and implementing strategies for stability without stagnation. On the one hand, people (including us) are tired of the constant barrage of new tools and techniques. On the other hand, it would be terrible to get beaten by a competitor that discovered a wonderfully productive new solution. The Ember team has spent the last few years honing a process for dealing with these conflicting desires.
That process involves:
* six-week release cycles, so every new change is incremental and adds value on its own
* canary, beta, and release channels (just like browsers), so that people will more appetite for churn can help test out features, and get them stable by the time they ship as part of a final release
* SemVer, so upgrading across final releases is relatively painless and the biggest part of our community can take advantage of the improvements as they roll out
* having each member of the core team build apps that we care about and maintain, so that we can feel the competing costs of maintenance and keeping pace with the latest and greatest first hand
The core ideas come from shipping browsers, which have had to deal with requirements of very strong stability with an increasing desire to "go fast". The pace of new browser features has been so good, in fact, that they have been used as an argument in favor of completely breaking things and starting over.
Ironically, the browser instead shows us that if we want to avoid stagnation, we are going to have to have strategies for bringing people along. Stability without stagnation is not a paradox; it's a recipe for success.
(we talked a lot more about the nitty-gritty technical details in the previously discussed Ember 2.0 RFC: https://github.com/emberjs/rfcs/pull/15)
That's not the tone we go for on HN.
Additionally, in this case wycat's points are highly relevant to the topic at hand; the article is about churn, and wycat talks about how he addresses that problem in the context of a JS framework.
And, we being somewhat to relatively smart people, can forgive the unmasked market-speak to appreciate the value of the personal experience wycats is sharing.
This should be an obvious and automatic hype-temperer, but for some reason it isn't.
My opinion is that some types of features are better off bundled in a ready-to-go package. For example data binding and ajax almost always go together and just plopping a CDN link to Angular is a lot easier than installing NPM, setting up a file watcher and who knows what else to get React's JSX running (and you still need to go decide what you're going to use for AJAX).
Other less "core" types of features are better off as standalone libraries because their depth of usage can vary from not being used at all to requiring very domain-specific features (e.g. accounting.js is a good example of this). I don't agree with the author's premise that micro-libraries are easier to swap. I'd be very doubtful if anyone were to claim that it's trivial to convert a React codebase to Knockout, for example. You'd likely be hard-pressed to swap even things like moment.js because you probably chose the library based on it being better than its alternatives to begin with.
But having these types of features be standalone libraries does provide some benefits, e.g. being able to opt-out of a breaking release in a more granular fashion, trial-and-error-oriented development, etc.
Re: the chaos/churn in Javascript, forgetting for a minute the buzz-words of Backbone.js, React.js, Ember.js, Gulp, Angular etc. - they seem all to be a fight about MVC, traditional vs. single-page app vs. isomorphic.
I fail to see how improvements in these tools actually push us to create novel projects. While one can nit-pick about React.js rendering performance in its internal "DOM diff" model or Flux's "data flow architecture" in improving code readability, but they are just buzzwords to me like words-play in a post-modern novel or art that arrange concepts in their idiosyncratic way in an arbitrary aesthetic way; although sometimes the rearrangements can be beautiful, they are ultimately shrines to themselves and their creators and subculture.
Subculture because everyone wants something of their own and ignore interoperability. Although the data model are the same whether you're a single-page or isomorphic, there is no community standard to define standards to define your data models a la J2EE annotations or code-generated one's a la Google Protobuf. Same thing with single app controllers, no standard like RESTful web service spec that's universal and interoperable like between .net/Java/Python etc. that can be applied to say, Sail/Backbone/Ember/Angular.
Postmodern because they are always self-referential to the "Ember.js"/"Node.js" way of doing thing - when they all do the same thing which is rendering HTML elements on the web browser in 2014, much like Visual Basic rendering forms on Windows 95 desktop in 1997. Never mind all the touts about performance, architecture, when the users won't care about the diminishing return of shaving off some microseconds of your AMD JS module loading or the beauty of your invisible architecture.
IMHO, instead of a race to the bottom to the most "efficient" and "beautiful" stack to render HTML, I care more about the ideas that push the web as a medium, e.g.,
WebGL (http://www.chromeexperiments.com/webgl/),
Web Audio API (https://chromium.googlecode.com/svn/trunk/samples/audio/samp...),
Web Real Time Collaboration (https://togetherjs.com/ http://www.webrtc.org/)
This is what I'm trying to accomplish with intercooler.js: http://intercoolerjs.org/
One of my main problem with javascript frameworks is having to drift away from the original server HTML. Not everybody wants to go the whole way down the Single Page Abbit hole. It's not only a question of speed or SEO.
I think many devs are both backend & front-end craftsmen, and as so build the backend first and then wish to 'grow' their frontend part on that foundation. Or ideally wish they could. Instead they have to fork the project into 1). the Good Ol' server HTML part 2). the API SPA part.
No matter how close angular or react (with jsx) stays to HTML, you still need to rewrite the whole view to comply with it's templating needs. There's no incremental evolution there, and worse : having to duplicate and sync maintenance on both ends, breaks the DRY principle which is fundamentally bad - since you end up with 2 sources of truth.
Pre-rendering the view with react on node (even if your on rails or whatever) may be a solution I don't know yet. Another take I guess would be to render your server html files with a template which complies with their JS counterpart. Yet another take would be to use HTML as the API instead of JSON - which is proven to work quiet well.
Anyways, just to conclude I think devs would feel more confident if they could rely a little more on the servers end while the frontend finds its ways and stabilizes a little.
I looked at intercooler supeficially with the hope it could be a foundation to standardize my AJAX calls (I did something myself but it still fluid). I'm not sure I like the way it puts so much information in the attributes of the DOM elements actions are bound to, but I'll keep reading. I prefer doing those stuff all in JavaScript and minimize the impact of frameworks on the DOM. It's still no time to commit to any of them. Let's wait until the dust settles.
https://groups.google.com/forum/#!topic/intercooler-js/FyPBo...
You might want to jump in on the thread and we'll see if we can coordinate a syntax you find amenable to your style of programming.
Java/Clojure with Nashorn works easily (you need JDK8 though).
I couldn't get anything working w/ Go other than Otto, a JS interpreter written in Go, which is too slow.
For an even more retro approach, perhaps some things are just better written as desktop apps. I know they're out of vogue at the moment, but I've been having good experiences with writing a JavaFX app lately. Particular points to note:
* I wrote my own online updates engine, that can be used to implement Chrome/Web style silent background updates, but which can also give control to the user over which version of the app they use. Users can downgrade at any time if a new version is buggy or just not as good as the previous version. It's very small, simple and easily integrated. It supports threshold signed updates so it's also suitable for high security apps where a hacked web server could be critical. It's called UpdateFX, check it out.
* JavaFX has a tool that creates native, bundled installers on each platform (dmg, exe/msi and deb). The user does not have to install JVMs or get any Ask Toolbar crap on their system. You remain in total control over JRE upgrades.
* UI is specified with an XML dialect called FXML, it's quite intuitive and anyone who knows HTML can pick it up quickly. But there's also (unlike with the web) a competent visual designer. You can style UI with a dialect of CSS and it's very easy to match the Twitter bootstrap look, native looks can be done too.
* Data binding is easy, the UI is OpenGL/Direct3D hardware accelerated, you can trivially apply effects like drop shadows or blurs and animate them, the API is clean, the entire framework is open source and the developers are responsive.
* Because it's not a web app, support for offline or flaky internet connections is second nature.
If your users can tolerate the initial download then it's a much more pleasant and robust development experience. If your users are the type who can't wait, you might want to stick with the web.
I will say, a well done client/server app is much more difficult to implement robustly than a web app. And, horror of horrors, users usually expect you to implement... undo!
Yes people have higher expectations from native apps, it's true.
Of course it all depends on the domain and architecture of the app in question, so counter-examples and exceptions are easy enough to find.
Of course, people might indeed think that's lame and sucky whereas they'd forgive it for a web app. This is one reason I made my app visually look like a web app e.g. no menu bars and a bootstrap/web style button/popup aesthetic. If it looks like a duck, people are more forgiving if it quacks like one sometimes too :)
This is effectively what the mobile marketplace has decided. Native mobile apps are thriving while mobile web apps struggle to keep up.
Some projects get a bit flashy and buzzwordy, it's true. Bacon.js [0] always sticks out in my mind as a prototypical example, though I think it's tongue-in-cheek.
I try not to let that flashiness get in the way, though. The fact is, Bacon.js is useful to me, when I try to make beautiful and efficient code to render beautiful and efficient HTML. Their homepage doesn't change that. React's performance is impressive, and may be important to me; ditto with Flux and code readability. And the theories underlying those libraries (DOM diff and unidrectional data flow) are important too, so I know why I should expect them to be better.
[0] https://github.com/baconjs/bacon.js/
No matter what framework, in the end it's all JavaScript. So even if I develop a flashy app using a nice fat framework, it is still going to run unless JavaScript itself is changed.
That said, I can build an app in Angular today, and when something flashier comes out, I can code new features/modules to my app using that.
Stop, right now, just let it go, take a step back from the bleeding edge and see that you've got all the JavaScript libraries and tools you need to put together any application you could imagine. If your imagination is big enough then you'll be hand writing your own additions in no time. So long as your applications runs on the major browsers latest-1 without issue there isn't a reason to upgrade. If you're writing a project there isn't a reason to make a framework jump, and if Angular 1 to 2 is that different, consider it a framework jump. Why feel bad about not knowing your way around when you go from one framework to another, would you feel the same going from Drupal to Wordpress? They are both CMSs, both PHP, both extended far beyond their initial goals. Angular 1 will go into maintenance if Angular 2 is that different, development will slow, and eventually you'll upgrade to Angular 3, which is incompatible with Angular 2, but after years of having a working application.
I've gone from Angular, to Kendo, to Ember, to Backbone. If you want to make an 'investment' in knowledge of front-end development learn the plain JavaScript, read through the framework you're using. Walk through the execution, that will allow you as a developer-for-hire to pickup the newest shiny on a new team with less issues.
Web development has always had this pace, whatever tool or setup you commit too, the next week someone will call you an idiot for using it. Ignore them, make something maintainable, nothing in the new framework is ever mission critical, just nice to have.
I make a habit out of using smaller frameworks that gets the job done, and only that. Anything else or beyond, we code ourselves, or re-use from a different project. Or we just stick with older technology because we know it works. Sure, our productivity might initially be lower, but at least we save ourselves the pain of "the next big thi—oh wait, something new arrived let's switch".
The site still works great... the codebase is fine. It was before some later changes to bootstrap 3, so it isn't current with the released version, but it still works, and did better so than v2. The same goes for most things involving open-source tools. You can go through migration cycles, or accept and limit the scope of how you use it.
I always applied the same arguments for using Mono in places as a practical reasoning. So what if new development stopped/dropped or rolled.. as long as what I'm doing can keep running.
Your best bet is to keep your codebase modular so much as possible, and it makes it easier to replace certain pieces.
Today, I really like react + yahoo's flux implementation. There are some weird corner cases I've had to deal with, it's still nice. It really just depends on your needs.
- There are always multiple choices for each piece of functionality you need to address, and personality clashes over which is the "best".
- Security is a whole lot harder to nail down with more moving parts. Go with Angular, you have this: https://code.google.com/p/mustache-security/wiki/AngularJS. Similarly, Ember: https://code.google.com/p/mustache-security/wiki/EmberJS. Even though these frameworks aren't 100% secure (although Angular comes pretty close), you can be more aware of the pitfalls. The more independent modules you have to keep track of in your app, the more difficult it becomes to track security flaws.
- Some seemingly unrelated components just don't end up playing nice with each other, and this can be hard to determine ahead of time.
As the article states, there was a time a few years ago that js-all-the-things appeared interesting and unstoppable. To me it appears in 1 year when Win10 arrives, people will have better spent their time honing skills for native apps.
Webapps as people envision them (universal applications) will die- returning to their original intention. Document sharing and simple data collection/retrieval.
Blame Eich and Mozilla for that. They insisted on pushing no bytecode for the web. Wanting us to rely on Eich's JS + rest of the webstack monstrosity requiring ugly hacks.
Win8 IMO is almost irrelevant, the marketshare isn't there to add a MS Store option for me or many others. The corporations haven't and won't hop on. Everyone is (IMO rightly) focused on iOS/Android/web at the moment. Agreed on MSIs, but I'd add the customizable corporate frontend stores should be more powerful and slick than the current method (same appstore for MS desktop and mobile). It's possible once enterprise moves to the MS Store that MS mobile devices make major inroads. For consumers, I think they'll rejoice at Win10, upgrade to it and by default go to the MS Store for security reasons alone. Not to mention auto-updates, same apps as on MS mobile etc.
I'm not pro-MS, I'm actually anti-all-for-profits and a Mozilla fanboy. I just disagree with Eich on a bytecode for the web, he blew it as far as the web being the prime delivery mechanism for apps is concerned. The webstack sucks, it had to go. Too late now.
I understand my view isn't popular at the moment. Especially among webdevs who are most likely to be reading this HN post. Those people have invested heavily in the webapp dream with their time, skills and careers. Anything to the contrary that it was a great idea is going to get downvoted. Regardless, I think this is an accurate reading of the foreseeable future.
It's not accurate at all though.
My prediction is that your prediction is dead wrong. Nothing will stop the web, certainly not your app store dystopia, and certainly not the way Microsoft would run it.
Presuming about my intentions or feelings towards the MS ecosystem is ridiculous. I had courses on VB6 in the late 90s, that's the closest and most exposure I've ever had to their ecosystem. I do wish I knew C# now that .Net is merging with Mono though. I see no shame in that. I don't hate MS anymore than I do Google, Apple, Oracle or ANY for-profit. For-profit means not-in-my-best-interests.
"Nothing will stop the web" sounds way too much like the idiotic quote, "always bet on JS". I'm not betting on JS with Eich, but I'm not against the web. Certainly my HN post of what I think will happen, won't affect that outcome.
I'm with (I believe) most everyone in supporting webapps being the universal delivery mechanism for apps in the future. Where did I say I wasn't? I also think there was a limited window of opportunity for this to take off. That window roughly being 2004-2014. Today, native apps are still on top.
Webapps will continue on in some form. But with Apple and Google already having appstores, will a popular version of Windows with an appstore be the closing of that door? That door being defined as webapps becoming the dominant application delivery platform. Yes, I think so.
But as of today, I fully believe webapps were/are hobbled during their glory years by the webstack, the web needed a bytecode.
If someone merely looking at circumstances and speaking on them bothers you so much, you are likely someone who speaks only to persuade others to your viewpoint. I'm not trying to persuade you and don't care where you stand. Frankly, I'm more than likely aligned with your views on webapps. I just personally find the webstack inconducive with the goal.
Action needed to be taken at a high level (likely at Mozilla, to make the webstack legacy and introduce a new bytecode standard), in a window of opportunity while the last major player (MS) was essentially out of the appstore business. I don't see it happening in time now. We'll see, but I predict it is you who has an emotional investment in the webstack.
Don't. They get so much for free that other developers have to work on hard (flexible data binding, easy portability and trivial deployment).
> They insisted on pushing no bytecode for the web. Wanting us to rely on Eich's JS + rest of the webstack monstrosity requiring ugly hacks.
I fully agree here. The whole "JS is not that bad" mindset is firmly ingrained in people's minds, which is a shame.
For all the faults of web development, I also prefer it over having to work within the blessed stack chosen for me by the OS vendor, and being forced to migrate every few years as they decide their old stack isn't worth maintaining (secretly I wonder if this constant churn is not also useful to them on some level, it stops app devs every considering other platforms, they're running just to stay still). In contrast web development means you can choose your own tools, you are not limited to using javascript if you don't subscribe to this latest fad that all logic must be in the front-end written in javascript (which never appeared interesting and unstoppable to me at least), and adhere to the original interfaces of the web which was so dumb and simple it was incredibly powerful:
Simple text files (markup, styles) sent over the network to the client, which interprets them in a predictable way to show your UI and data (the predictable part has improved much over the last decade).
I do agree with you though that not having a bytecode for the web is a severe restriction on front-end development, and means that I prefer doing backend web work and using js in a limited way for ajax etc, not trying to use it to generate entire documents/UIs. Personally I find JS is fine for limited tasks, but not for writing apps in without quite a lot of pain. I expect that to be addressed at some point soon though, either by asm.js (not optimal), or something like Nacl. Till then, it's bliss working in whatever tools I want on the backend, even switching out tools if I want to, without the end user even knowing that I'm using a different stack - to them what is important is the app, not what it is written in - that is as it should be, and not something you see on other platforms. That's the attraction of web development for me, and one that native development will never equal.
I disagree that webapps will die - I think they'll just evolve and eventually will become universal applications based on HTML. Javascript will die, but not the web. However that is really a political question about how hard OS vendors will push users towards native apps (where they make money both from sales and more importantly from lock-in).
Will OS vendors continue to dominate computing? I think that's a more interesting question, and one we'll see play out over the next few decades. The web may yet reduce native platforms to a set of badly debugged device drivers.
Best I'm aware, a lot of these apps exist already. The step we've yet to reach is "having to launch" instead of merely being able to launch. We probably will for some of them, though.
Speaking for myself, the dystopian present and near-future has me a lot more worried than a hypothetical future with apps: I've lost count of the number of websites which used to work fine on a 1st gen iPad and which now either refuse to work on grounds its browser is too old (e.g. Github), or outright frequently crash its browser owing to out of memory errors due to excessive use of javascript (e.g. most news site).
Very few people use them, however.
> I've lost count of the number of websites which used to work fine on a 1st gen iPad and which now either refuse to work on grounds its browser is too old (e.g. Github), or outright frequently crash its browser owing to out of memory errors due to excessive use of javascript (e.g. most news site).
The situation isn't that great for native apps either. Most times, you're lucky if an app has targeted more than just one platform. And try running modern native apps on the 1st gen iPad; developers leave old tech in the dust regardless of which platform their targeting.
I will agree that web apps need to get better in general and work within the constraints of the browser, and that news sites should have as little complicated javascript as possible (or at least sensible fallbacks), but that's not a reason to throw the baby out with the bathwater. For a wide swath of applications, the web is the only truly ubiquitous deployment target and when done right (Netflix, Amazon, Facebook, Hacker News, etc) web apps can reach a much larger user base for same development time than native apps can.