Angular 2 Final Released(angular.io) |
Angular 2 Final Released(angular.io) |
I can't find a benchmark or size comparision somewhere.
A very rocky road ahead, methinks.
Yet there is Polymer that just works, has a great ecosystem, awesome material design support and is a breeze to work with (+ its fast too).
Right now there was 2.0 announcement and new version really supports easy migration path unlike Angular 2.x.
To me, all these things put Polymer far behind the curve as something I'm interested in ever adopting.
Is bower less reliable than npm? (I do more python work than JS)
When it comes to performance it is great in Chrome. In other browsers not so. I hope v2 will be much better once they can get rid of the compatibility layer for other ever-green browsers.
It is much faster than Angular - somewhere around React performance. Polymer is picked up by big companies already whereas "no one"(big) is using angular 2.x for now.
People here seem to project a weird bubble around Angular/React.
> In other browsers not so. I hope v2 will be much better once they can get rid of the compatibility layer for other ever-green browsers.
Browsers get rid of it on their own - when they implement the standards, shims load when specific functionality is found or not.
There are also tons of components to pick from, someone is obviously building them. We are rewriting parts of RhodeCode UI in polymer right now and everyone is very happy about how that goes.
There are plenty of job offerings on polymer job channel and in the wild.
It just seems that HN folks are ignoring anything that is not called Angular/React because its not hyped enough :)
http://thenextweb.com/google/2016/05/02/youtube-getting-goog...
funny i just spent an hour yesterday upgrading to 3.0.0-rc.7
I see their quick start has been updated to use the final. https://angular.io/docs/ts/latest/quickstart.html <= great way to get started.
agree with other comments that RxJS is a tough library to learn but I love that they used it instead of re-inventing that wheel. It is incredibly powerful and solves a lot of asynchronous programming problems. you can see all of the methods visualized with marbles here: http://rxmarbles.com/
:-p
This might appeal to java full stack/backend engineers that need to once in while show case a nice and shiny GUI. It my experience, the combo of Angular with Bootstrap/Font awesome works just fine for that.
Very positive to have static typing through TypeScript as well. But also here I am quite biased for I never liked the concept that 'everything is just a var' ;)
Is Leftpad included?
TL;DR: Left Pad is a NPM package that was removed by it's author in protest. Apparently, a ton of other packages broke as it was a major dependency across the NPM ecosystem.
We also have a (community) react-native bridge, and of course all the awesome html5 stuff from Ionic.
NativeScript has a JavaScript<=>Java bridge on Android, and a JavaScript<=>Objective C bridge on iOS, like a cross platform version of Apple's ObjC bridge used in OS/X JavaScript for Automation [3] [4] [5] (but AFAIK Apple's ObjC bridge is apparently not available for developers to use as a framework, nor on iOS, nor of course on Android).
Unlike React Native's JavaScript engine, it runs in the UI thread, using V8 on Android and JavaScriptCore on iOS, and you can call all the platform specific APIs directly, subclass and implement Java classes and Objective C classes and protocols, call methods and functions, and pass objects back and forth, write your own plugins in TypeScript, JavaScript, Java, Objective C, etc.
[1] http://docs.nativescript.org/angular/tutorial/ng-chapter-0
[2] https://www.nativescript.org/
[3] https://developer.apple.com/library/content/releasenotes/Int...
[4] http://tylergaw.com/articles/building-osx-apps-with-js
[5] http://developer.telerik.com/featured/javascript-os-x-automa...
[1] - https://angular.io/docs/ts/latest/guide/template-syntax.html... [2] - https://angular.io/docs/ts/latest/guide/attribute-directives...
You cannot really compare these frameworks because Ember is far ahead of all. Super stable, matured, adopted the best practices, huge addon ecosystem, brilliant community, easy to learn, great documentation. Quite an obvious abd best choice. Life and development is just super easy and fast with Ember.
IDEs have to implement better support for NG2 but this will come over time.
There will be always limits for search engines on interpreting js.
It's important to IMMEDIATELY understand that the backend should not matter - so long as it returns JSON (or even XML i suppose) which AngularJS 1.x can consume with $http or $resource (or ng 2.x equivalent).
This is an advantageous pattern in my opinion because the front-end angular application is totally decoupled from the backend (we have separate code repos - and even separate developers) - you can keep the backend as Go, or PHP, or Python - or even a static JSON file with something like jsonserver. So long as the JSON is formatted appropriately and API does what angular expects - angular does not care!
Google itself has this to say:
https://webmasters.googleblog.com/2014/05/understanding-web-...
Have you tried to figure out the cause using Search Console?
The Angular team has made significant efforts to court them/cater to them, even employing a CSM, and two developer advocates. Those are just examples I've heard/interacted with in the wild, but I'm just a developer at a small company & not part of the Angular team.
At the risk of stating the obvious, the Angular router handles routing for the Angular frontend, the Go router handles routing for the Go backend (the initial page load, the AJAX calls made from Angular to get data...).
We use angular as an MVW for front-end We use django + django-rest-framework for back-end.
It's important to understand that "routing" in angular is a bit "synthetic" - it's not actually requesting much from the server after index.html loads (it only changes address etc as part of the routing). So the routing is totally separate on the front-end, assuming you are using a back-end to provide the data.
Breaking changes during alpha stage were expected, so I didn't have issues with it.
Most positive things I want to highlight:
1. Components are encapsulated and truly reusable (and without dependencies hell).
2. You don't need any "bridges" anymore to use 3-rd party JS libraries inside your Angular app. Nothing need to be "angularized" - twbs, D3, all just works out of the box. Maybe it's even most important part for me.
3. Idea of `(events)` and `[attributes]` is awesome, works really effective and makes code much more easy to read.
4. Performance is great.
5. Community is friendly and have a lot of fun and patience, even to newbies.
6. TypeScript gives a lot of bonuses with zero price - you don't need to learn anything (you can just rename js to ts and it will work) and additions to JS are simple and powerful.
7. Cool abilities like AOT-compilation, server-side rendering and tree-shaking.
Congrats to the all devs who are using Angular, congrats to the Angular team! :)
1. Typescript. If your team isn't familiar with it it's not trivial to get everyone on board. The up-front cost can absolutely be worth it in the long run, but there's some friction in the day-to-day work with managing type definition files and looking up esoteric lint-errors from the Typescript compiler.
2. RXJS. Canonical NG2 should use Observables, and rxjs is not a trivial library to learn the ins and outs of. Add to that that there's no clean way of doing testing with Observables at the moment (integrating with the rxjs testing schedulers is very finicky). This is doubly true if you're using ngrx (which you probably should).
3. Template language. I'm one of those who don't think it's a very good idea to bring a new DSL into html. I'd much rather do it the React-way of bringing HTML into JS instead of relying on a very complex compiler to do magic behind the scenes. This becomes a bit better with the template pre-compilation, but it's still new syntax that you need to learn and keep in mind. Some of which is not intuitive nor well documented (i.e. how pipes and parentheses work together).
4. It feels unfinished. This is to be expected since it's just on it's initial release, but the sharp edges do show up quite a lot. For example we very often have to do manual subscription and unsubscription of Observables in Components. This feeling also goes for quite a few of the community addons, such as the browser-extension. While I absolutely applaud their efforts, it's far from reaching the quality of e.g. the Ember-Inspector.
5. Sub-par debugging experience. When you get any errors there's a mile long stack trace filled with rxjs and zone.js garble, making it very hard to actually figure out what's going on. When there actually are custom error-messages they are not very informative, with you having to fundamentally grok how parts of NG2 works to even come close to understanding why it's not working (getting this a lot with the change detection).
6. Lack of documentation. I tried to stay very far away from Angular 1 since I found its documentation to be very low quality (probably a symptom of Angular 1 being poorly engineered as well). The NG2 docs are definitely better, but I feel like my mental model for reasoning about how things work was still very weak when I had finished going through the docs. There's some really huge gaps in there (testing) and a lot of the really complicated stuff that you will stumble over is only really documented in semi-old blog posts.
2) amount of boilerplate code for unit-tests (not e2e - everything is fine there);
3) some things were removed by performance reasons - I think would be smarter just rename them with prefix "slow". Sometimes it's more important to have some functionality than don't have it, even if your app is blazing fast.
This is encouraging. I always thought that looked aweful so it's nice to hear that it actually makes sense.
- input:
```
<foo [x]="y"></foo>
```
```
<foo (x)="y = $event"></foo>
```
Is this accurate? What is a good use case for Angular?
Of course, now you have A LOT of event handling in a client app on top of your middleware / micro-services, but I feel it is a helpful separation of concerns.
I suppose in my case it helps that I would rather do more of the app in Javascript, and less in Java. YMMV, substantially - I'm pretty sure I have a minority view at work :-)
We are working on a rewrite of a largish app (for a small team, anyway) at work. We already have a second, alternate, client app for our back end for a pilot project that we can now easily tackle with the new architecture. There were very few changes required on the server, just an alternate login method to automate an initial connection to a third party app (which then runs our alternate U/I in a frame), rather than an interactive SSO form.
We have a "Few Pages App", rather than Single Page App. By design, we reload a small number of alternate pages after a longish task, just in case (e.g. - resource leaks, whether from our own mishandling, or some library) - not because of known issues, mind you, but just out of my own paranoia that I would rather plan to allow for minor errors rather than requiring perfection.
In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?
>In Angular 1 the only way to use them without resorting into angular-XYZ libraries is to put them in a directive and use the link function to write all the logic and DOM manipulation. What's different in Angular 2?
Well, there is no $scope in Angular 2, so there is no need for link function ( which was used for linking scope and DOM)
Not very promising...
React on the other hand, I stumbled upon looking at the source of the Wall Street Journal the other day. It is everywhere now.
Granted, not open source, but definitely drives home the point that it is trusted in production environments.
If nothing else, Angular just stranded all their developers, while React has a huge head start on mindshare/plugins/tutorials/etc.
The HTML template in Angular 2 is stored in a string. This has several disadvantages:
1. Editors can't do syntax coloring.
2. Editors can't do auto-indenting.
3. Editors can't offer "intellisense" suggestions.
4. Editors can't match tags.
You embed variables in this template string like this: '<div>{{hero.name}}</div>'.
This means:
1. Compilers can't find typos or find syntax errors at compile time.
2. If you make a typo in the variable name you don't get a compile-time or run-time error, instead the value is simply not displayed!
3. Tools can't refactor (i.e., rename) variables embedded inside the template.
4. No intellisense for the embedded expressions.
You have to learn weird syntax such as ngFor whereas in React you just use a JavaScript for loop.
In React you embed HTML inside the TypeScript and VisualStudio treats both the HTML and the TypeScript as first-class citizens. You get compile-time checks and intellisense for both the HTML and the TypeScript code! You can even put breakpoint inside the template and step through loops whereas in Angular you can't step through an ngFor.
Note that some of the above may have changed since I last looked at Angular 2.
But when I look at how are built the sites I like and visit frequently, I'd say 95% of them are not SPA, they are classic sites where the server generate each page (sometimes with one or two Ajax requests)!
The Single Page pattern is great for desktop-like applications such as Gmail, it's obvious. But otherwise, I don't know... I think I still prefere the "feel" of classic websites.
As someone coming up to speed with frameworks like React and Angular 2 it feels like that all over again.
1. Typescript awesomeness: You can write plain JS or give type hints in Typescript. Typescript is awesome, because it is a superset of Javascript and compiles to Javascript. (Typescript > ES6 > ES5)
2. Modular code: It is is much easier to manage Angular code as it grows (compared to AngularJS). Components could be made independently and reused within other components using component interaction [1] (@Input, @Output)
3. Template Directives: .html template directives are available unlike ReactJS. A ReactJS vs Angular2 blog post online [1] argued that that putting HTML in Javascript is better than putting Javascript in HTML. I'd argue that template directives like ngFor, ngIf, etc are much simpler to understand. Also, it is easier to collaborate with a designer/half-developer who knows some html/scss and doesn't know Javascript than working in ReactJS where every collaborator has to know JS. This way, it is also easier for someone to gradually learn the framework. For me, template directives are a big win. If someone wants to construct templates with plain JS, that is still possible in Angular.
4. @angular/router is better than AngularJS routing and we don't have to use a 3rd party library (like ui-router was more popular in AngularJS than the angularjs router)
One thing that I have found annoying is that: UI libraries for Angular. Example: material2 (currently at alpha.8) [3] are not complete yet and lack several useful components. This can be a problem if you are looking to quickly build a complete, good looking UI. Hopefully, now with Angular 2.0.0 out; Angular team could focus on quicker development of material2, so we have all the AngularJS Material UI goodness with Angular.
[1] https://angular.io/docs/ts/latest/cookbook/component-communi... [2] https://medium.freecodecamp.com/angular-2-versus-react-there... [3] https://github.com/angular/material2
Specifically:
> Bug fixes and non-breaking features for APIs marked as stable
> More guides and live examples specific to your use cases
> More work on animations
> Angular Material 2
> Moving WebWorkers out of experimental
> More features and more languages for Angular Universal
> Even more speed and payload size improvements
> Semantic VersioningCompare the differences and consider the trade offs with complexity vs simplicity. It's worth a consideration.
I've been using Angular 2 in a major enterprise project since RC1. Even with some of the headaches between RC releases; all of the reasoning behind those changes is technically sound.
It's easy to write components and wire everything, and even small things like async validators are fluid and easy to implement.
I'm loving it, and while the entire build system is still a bit of a dumpster fire; we're doing great on things like testing, code coverage; etc.
There are a lot of problems with lazy developers hoping a blog will tell them how to do every little thing. The source code is on Github. If you can't get something working right; maybe go read the source code of the classes you are interacting with. I've found 99% of the time now that simply reading through the code gives me not only the transparency needed, but a clear path to a better solution. Kudos to them on the new forms; they're awesome.
Though next week's announcement...
Angular 2.0.1 RC 1
It's Change Log will read:
* Routing has been rebuilt.. all previous versions not compatible
* We decided to rename the NgModule decorator to NgYouMAD?
* All Internet tutorials no longer work... Good Luck relearning!http://smashingboxes.com/blog/choosing-a-front-end-framework...
https://www.developereconomics.com/feature-comparison-of-4-p...
https://www.developereconomics.com/comparison-4-popular-java...
Tried Ember.js more recently, didn't much care for it. I think I'm just not a fan of large frameworks.
Now mithril.js (http://mithril.js.org/) has finally lured me away from Backbone :)
Ionic 2 + Angular 2 seem to be the best choice, since I can basically write the app once and release for all three platforms.
React Native has the downside that React and React Native are two different things. Be aware that there is no such thing as React Native for the web. There's something in development right now, but nothing stable.
Truly native: I can't support three platforms as a single developer and I don't feel like outsourcing it.
I'll go with Ionic 2 + Angular 2, although Ionic 2 still has quite a few bugs. For example, the zoom attribute on <ion-scroll> doesn't work – which is critical for my app.
Sure, there are hacks and this reminds me on the discussion from the other day: https://news.ycombinator.com/item?id=12477190
Yes, it's all very hacky. But there's really no alternative I guess.
Getting Started with Angular 2
https://angular.io/docs/ts/latest/cookbook/a1-a2-quick-refer...
Did ng1 and react with JS before, react was more enjoyable but in the end it just doesn't compare.
Anyway, great to see the release :)
Devs must be in the thousands, but the users of their apps might figure in the millions :)
Seems few people know how to steward a free/open source software project that has lasted over 5 yrs.
Angular 2 in beta/rc was in many ways rapid iteration on top of experimentation to get the core APIs & developer experience right. They have finally reached a stability point where they feel completely comfortable with the framework they have ended up with as a result, thus the formal release of 2.0.
If you've actually paid attention to the development cycle of Angular 2, it was very fast - it turns out that Google moves much faster than most shops, which was seen in full display during alpha/beta/rc. However, that goes with the territory there, and the versioning did not lie. It is now following semver though, so we shouldn't be hearing of these problems anymore.
Cx documentation is written using Cx and it offers plenty of interactive examples and code snippets.
https://cx.codaxy.com/docs/widgets/grids
Disclaimer: I'm the author of Cx.
* I am a part of the UI Bootstrap/ng-bootstrap team - we worked on ng-bootstrap starting back in last August/September and have the benefit of two of our team members currently working on the Angular team.
I also really like Typescript and believe enforcing it is a good way to get general JS code quality up.
There's even a pull request to bring typescript into the mix. https://github.com/facebookincubator/create-react-app/pull/5...
I work daily on a large Angular app and a growing React app, and my React app, while being more pleasant to work with, is also much harder to keep standardised and clean. I'm also already experiencing perf issues because of not using immutableJS, which is quite annoying...
Both are similar in that they are component-oriented.
There are two important factors in my mind.
1. The ecosystem (as you mentioned). React has a clear head start here, but I expect Angular2 to make some gains over time.
2. Angular2 gives you a full framework, and as they say now, a whole platform. React is smaller and you rely on a bunch of other packages to get all the extra features you need. If you want a full solution, Angular2 gives you that.
This can be argued as a good thing or a bad thing. More flexibility with React, but also more things you need to figure out and make a decision about. With Angular2, once you buy in, you don't need to make all of those decisions.
In my particular circumstance, which is to migrate an Angular1 app to a newer framework over time (mainly for the server side rendering features), Angular2 provides a clearer path and offers some nifty features like component styles that allow a similar migration with CSS.
So did Angular 1, and then they threw it under a bus. Now developers have to either refactor for a whole new framework or get stuck with a legacy one.
Javascript ecosystem is becoming so hostile a project deprecates itself in favor of a clean rewrite and the migration path is an afterthought.
Will think twice before adopting google frameworks and tools.
Javascript ecosystem is in dire need of stability and trust.
But to contrast all three, I'll pick the area I'm most interested in - templating. The purpose of a framework is to render a dynamic view without the programmer having to wire up every state transition with a corresponding view transition. This is done by templating content with state, mediated by the framework. And how this is done affects the entire design of the framework and apps written on them.
Angular and Ember allows state and logic inside HTML. They figure out which state variables and corresponding templates go together and re-renders them automatically. The pro is that writing a modified version of HTML without too much code lets us have a dynamic app running in no time. The con is that there is a new language to study - with its own parser, control structures, scoping, and quirks.
React on the other hand lets us specify templates as Javascript functions which are run whenever the state changes. The pro is that there is no new language abstraction to learn; it re-uses Javascript. External DSLs especially are in an uncanny valley - they're not full-blown languages but have enough quirks to be bothersome. Language abstractions forces a virtual machine (the language parser/interpreter) to evaluate the code, and it is an opaquely magical layer that makes it hard to see the entire stack of abstractions during day-to-day programming. It also forces a separation between our view (written in the templating language) with the rest of our code.
The con of this approach is simply more code to write; the programmer has to anticipate and inform the framework of any state changes. With setState this isn't as bad a trade-off as we'd imagine. And MobX meanwhile brings an Angular like state abstraction to React - it watches over observables and automatically fires re-render.
The other big difference is that React is not opinionated. It is a very much a framework alright, but it for example doesn't ship with a router, nor does it prescribe a framework for organizing the code. Ember has so far done a great job here - I often wish I could combine the Ember ethos of backwards compatibility, great documentation, and a fanatic love for the existing users of the framework, with the way React approaches templating and composing components. I haven't had the chance to look at Angular 2, but for me, Angular 1 started the front-end revolution happen, and I'm curious what they have done this time.
Cx adds declarative data-binding, controllers and router on top of React and includes composable widgets and charts. It looks for a sweet spot between development speed and freedom to do whatever you want. Here's a quick example https://cx.codaxy.com/fiddle/?f=42vDn4I1.
Disclaimer: I'm the author of Cx.
> Angular and Ember allows state and logic inside HTML.
State updates do not occur in Ember templates. Templates specify the follow data from one component to another, as well as callbacks which are names of actions defined in a javascript portion of a component, or a parent component.
But it does not allow you to specify how state is updated within the template. In terms of Logic, there's just if statements & loops which is pretty conservative imo.
edit: rephrasing words
React expects you to do your development on some flavor of Unix, and really doesn't have a sane plan for Windows, so you lose VS.NET and its huge productivity gains. And it needs tools upon tools upon tools to set up, whateverify, transpile and pack the files you write into something that can display in a browser. Again, this all seems to want to run from a Unix command line.
I want to edit some HTML and Javascript, then reload the browser and see my changes. Angular isn't perfect, but at least it lets me do my thing without adding a bunch of extra hoops.
I think this was true six months ago but now there is create-react-app. You might want to try it out - you won't need to whateverify your code, you just need that one tool. Also it works on Windows.
https://github.com/facebookincubator/create-react-app
I want to edit some HTML and Javascript, then reload the browser and see my changes.
With create-react-app the browser will know you've made a change, and reload for you ;-)
Our projects compile from Typescript to ES6 and then ES6 to ES5 through babel. All of that takes place in webpack, and it was pretty easy to setup. We also all use Visual Studio Code and it's a joy to work with.
If you use something like hjs-webpack it gives you (hot-)reloading for code changes out of the box.
I've done both React projects with Python and C# apis. React is perfectly usable in VS.NET - are you aware of the Task Runner Explorer - https://blogs.msdn.microsoft.com/webdev/2016/01/06/task-runn... - hooks whatever you want into the build cycle, watches etc - once I discovered that, everything just clicked into place.
React would mean to rewrite your whole application as it has a totally different basic concept. Following the ng2 migration path you're able to migrate slowly.
With that, we could put a React component anywhere in our Angular app, and reuse Angular directives inside of React until we got around to rewriting them.
That ended up quite smooth.
I don't see what is a problem to just drop in React into `<script>` tag and use for single part of the page, gradually refactoring stuff.
1. as others mentioned its a fuller framework, mostly akin to using react with redux (or flux etc...) and a di framework. This also means that angular 2 third party components are probably easier to integrate.
2. Reactive Expressions, which angular2 uses in many places, is a joy to work with (though they might become maintenance hell later on I think). You can use RxJs with React of course, but it's easier when your framework is based on it
3. It uses string templates - which means that some things such as dynamic templates and per user customization of html would probably be much easier to do then in React.
4. It has Ionic - which is much much faster to develop for mobile with then react-native (though obviously there are important differences). It's unlikely that an Ionic like framework for react will gain traction with react-native to compete with.
The key with React is that you manipulate JS instead of HTML. In my experience, using JS to manipulate elements turns out to be easier and a much better experience than the conventional way of using templates.
Only downside is trying to hire Scala frontend devs.
This is patently false. Just use "templateUrl" instead of "template". This allows you to specify a file instead.
This is the way I always did it in angular 1 as well. I don't really understand why style guides & general practice recommend embedding html in the javascript though. It's horrible.
I'm sure 4 can be solved by editors, if it hasn't been already.
https://www.jetbrains.com/webstorm/whatsnew/#v2016-2-angular...
I do agree that I really really was a fan of the backticks for ES6 / react for templating. Avoiding the whole " vs ' escaping nightmare is something i've always looked forward to.
That seems like a very simple fix for them though, potentially.
edit: tone
Also with AOT compile, breakpoints inside templates are possible, so you absolutely can step through an NgFor :)
Edit: You can use external html files. Just look at their tutorial[0] using html-loader at the very end.
templateUrl: './app.component.html'
Your hacker biases are showing.
The sites where 95% of people spend most of their time (Twitter, Facebook, Instagram, etc.) are all built as single page "applications." Users expect rich interactivity from websites these days and are usually not tolerant of UI refreshes.
The comparison is not to "desktop" applications but to mobile apps. Users expect a mobile app level of interaction. Plus, if you're building mobile apps then it's a lot easier to just reuse those same APIs for a web app.
That being said, if your site doesn't have any interactivity then it does make sense to just render it statically.
The app may have been slower to load the first time (hopefully not by much) but from then on, they get the perception of instant feedback even if they have to wait a round trip for the backing data sometimes.
SPA frameworks make this sort of interaction very easy to design and reason about as a developer.
If you are going to argue that this is about "hacker bias" you will have to show user studies, not poll JS developers.
They're fantastic for forcing people to buy new hardware just to look at information :|
I've done of a few of these types, and now have moved onto mixed environments. Where most is rendered server sided, then only updates requested client side. Of course you're doing things twice for same queries.
Serious question: are people so touchy these days that you have to assure them that you are not being hostile before even saying something?
Of course all that goes away when your boss says you need to support JS-disabled browsers.
Well seeing as this release of angular offers some form of server side rendering, as well as Ember with fastboot, & being implementable in React or something like that. It's more approachable these days, there's some tweaking that's required, but very much doable.
Unless of course you're dealing with an interaction heavy UI.
In any event, if you're making a real Web application (as opposed to just a Web site that's primarily static content) the experience is much better.
Classic websites have CMS, things like Wordpress, and a ton of MVC frameworks that have been tweaked over the last decade, like Rails, Django, ASP.NET MVC, etc. When it wasn't a solved problem, a new one like this was popping up in the news every other week.
Now, that that's done, people are trying to do other things, like complex web apps...and so that's where the brain time is being spent.
React is super good to take control of a small piece of the page and build a complexe widget on it (can't speak about angular, I only used it twice without getting very far).
However, in b2b use cases where SEO isn't an issue, SPA frameworks are ideal for coordinating a static-site<->dynamic-api system.
Most websites and web apps have use AJAX to dynamically update certain parts of the site. Even though few sites would need to use it for everything, once you introduce good tools for dynamically updating the DOM and hire some Javascript developers, it's easy to say "Let's just use this approach to everything".
It's fair to say it's a lazy approach. I've built many SPAs that probably would have been better as static sites, and would have benefited from better SEO. But hey, we got then shipped fast.
I don't think that's entirely true, they allow for building experiences that weren't really possible with the previous model of rendering entire pages server side on every action but they aren't easier in all respect to that. If you site is mostly static data, it's probably still easier to use the older model. SPA frameworks start to make more sense when you want to build interactive pages with components that you want to individually update etc...
But they do add complexity that can't be ignored. that's why tooling and frameworks are hugely important as they smooth out that complexity.
Websites are static documents.
Web Apps use the browser as a runtime for a UI application.
HTML5, CSS3, and Javascript have matured to the point where they are very powerful and flexible. I don't always see the point of over-complicating things with frameworks.
All-told, it took 20 hours, 7 of which was me getting used to the intricacies of developing a full-screen "App" (no scrolling) with flexbox and implementing the designs. I'm good with vanilla JS, but there's no way I could have done all of the coding (three 'game' pages, three 'admin' pages) in less than two days.
I guess the point is, a framework that you know and are familiar with can halve the time you spend on a project. I find that to be especially true with Ember because of the CLI tools and all of the various addons.
Simplify server logic
Use less bandwidth
Very detailed, proved by numbers, objective and professional argument. That's how things should work.
It is funny that after the Rails driven success web devs had moving away from J2EE they are falling right back into the same traps - ultra complex bloated frameworks built on a terrible language.
Even if you consider JS a bad language, proper abstractions can change the face of it entirely. By your logic, assembly is also bad since it is absurd to write anything useful in it. IMO Elm is a step in the right direction.
Learning by rote is stressful since your mind has to retain effectively a bag of (to it incomprehensible) technical trivia. In contrast, first principles are compact and generative, and such a grasp also informs your intuition so you can actually make educated guesses and jump in the deep end when picking up a new stack. Same principles apply to learning programming languages.
The biggest headache in picking new stacks today is the current trend of technical neologisms, so a bit of initial squinting (for recognition) is required.
I agree with your annoyance with the UI libaries. It's been a PITA just to find a working datepicker. We eventually rolled our own starting with the source of an abandoned date picker project. Haha.
Source code here: https://github.com/ng-bootstrap/ng-bootstrap/tree/master/src...
Be aware, it is not perfect atm, especially around validation, but it is pretty much the only datepicker out there for ng2 in the open source world (not even Angular Material 2 has one).
I know it's supposed to be faster - I just am not finding people using this stuff in production seriously until now.
I don't want to clog up the angular group with these informal lines of questioning - obviously.
It basically uses the JQuery date picker and works quite well.
There is a lot of roughness around currently when it came to upgrades during the RCs - Angular 2 was far from full-fledged even during the earlier ones, and has come a long way in the course of their development. Testing has a massive gap in documentation/articles on how to do it right. There are also some pains such as some (IMO somewhat poor) opinionation in the Angular router, especially when combining with server-side routing - had some battles integrating the Angular 2 app with the full server-side app for work, in large part due to hapi's major deficiencies when it comes to delegating routing to a frontend only application. Setting up can be daunting, although I got a large boost from using https://github.com/preboot/angular2-webpack, a great starter pack largely maintained by a member of the Angular docs team. Not all of the benefits are easy to tap into currently, such as the fairly recent AoT compilation, which lacks any plugin support for any build system such as Webpack currently. I intended to write one & open source it, but I was assured by a member of the Angular team that it was on the docket to complete. Documentation also needs a lot of work to be more developer friendly, I have found senior developers making easy mistakes with Angular 2 because they are not familiar with how to structure everything while having to produce on difficult story work. Testing is also a sore point, especially with the need for the karma shim to be produced for each app.
That said, Angular 2 is a phenomenal upgrade over Angular 1 in the ease of structuring apps. It also avoids incorrectly munging everything into components, avoids imperative logic to construct DOM/components, and imposes opinionation & more modern tooling such as the availability of observables to more correctly manage app state & app flow. It is fast, and much easier to tap into optimizations than Angular 1, where one had to be able to work close to the source code in order to understand everything one can and cannot do. It also offers the flexibility to do everything one can do with React, including server-side rendering (with the ability to do so on platforms such as PHP, Java, Node, and .Net in the pipeline), web workers, service workers, and multiplatform apps via React Native or NativeScript.
Just curious if you are indeed saying that the built-in router allows you to do EVERYTHING you could do with ui-router (nested states / targeted views etc)? I was planning on sticking with ui-router-ng2 when we kick over to angular 2.
How about testing? Was that difficult moving test suites over?
Angular Router does allow nested states: - https://angular.io/docs/ts/latest/guide/router.html - https://angular.io/docs/ts/latest/api/router/index/Router-cl...
I don't quite recall what "targetted views" mean?
I love experimenting with ng-1: make a static HTML mockup; add a stub controller with a sample model and modify the HTML to insert the data and edit things as needed; add some event handlers with dummy actions. (add your REST calls later...)
All of the above can be done w/out any server or compile process - just keep reloading the page when you make changes (perhaps using something like python's SimpleHTTPServer module to serve files from your development directories). Once you get things about how you like them, start on the server side. This approach won't work for a page with a complicated workflow, but you can still prototype quite a bit for an initial learning experience.
You need to think hard about whether you really need a SPA for something complex, or whether you can go back to the server completely in some instances.
People who only take it up at the beta stage are obviously inferior, and hence denigrated as "beta men". And then there's the detestable wimps who go only for 'stable' versions, I suppose they must be "omega men", not even worthy of a mention in discussions.
Glad to know Real Programmers[1] still exist amongst us.
This is why I use React + Redux with some Webpack magic -- everything is encapsulated and composable from the ground up.
https://github.com/Microsoft/vscode https://github.com/Microsoft/typescript
this._settingsService.settings$.mergeMap(settings => {
this.settings = settings;
return this._weatherService.getLatestWeather(this._location, settings);
})
.subscribe(
weather => this.weather = weather,
error => this.errorMessage = <any>error
);Yes, the majority of code is still written by Evan, due to speed required. but we know that vue is heading in right direction.
material-ui's tutorials are really bad examples on this. They teach you to import from specific dir path inside material-ui. (e.g. import Pen from 'material-ui/lib/pen' or whatever)
Instead, they should recommend: import { Pen } from 'material-ui' since most of their exports are already in material-ui/src/index.js file (or some index.js file from package.json's main part)
But actully, the performance is not a question anymore, with the new Glimmer Engine 2 Ember will be the fastest framework, with full backward compatibility.
Something funky going wrong when jQuery's involved? Good luck stepping through that.
I put all libraries into a common bundle, which I blackbox in the browser debugger. This way only frames from my own code show up in the stack by default, and the debugger won't step into library code.
This also makes stack traces very easy to visually parse, as you can pretty much ignore all the ones ending in "... (common.js)".
Which is doubly shit.
Let us know if there's anything we can be doing better :)
For me it has the opposite effect, it makes everything sound less genuine. But hey, I'm just some guy, if people like it...
I find unnecessary clichéd phrases very annoying (e.g "going forward"). Maybe I'm alone in this. It's not because of pretentiousness or language puritanism, it's that it makes me feel that I'm reading something created by corporate PR or some other soulless entity with ulterior motives. My rule of thumb: if you have nothing creative to add, just be simple.
"Premature optimization is the root of all evil."
- Donald Knuth
So, I guess I'm saying that it allows for much shorter iteration times, ability to experiment with solutions in the production environment without requiring complicated server solutions.
Granted, that also lets me build experiences that weren't possible, because I can experiment more and have a faster feedback loop, but for me, it's because I can DEV better.
My favorite thing about ng2 components over ng1 would be the annotations. One annotation turns my component into a component. It links the html template, sets up the services, injects the other components and directives it needs in one simple annotation. In ng1, I remember it being cumbersome to set everything up.
To use a component in your existing app. You create a new ts file. Add an annotation. Write the template inline or in another file. Reference that ts class in your other components. That's it!
> A template may hold exactly one unnamed <router-outlet>. The router supports multiple named outlets, a feature we'll cover in future.
What I need time to get around to is the concept of controllers and how it works when we want to compose things together. For example, how to write a multi-select widget that exposes a clear API to the rest of the world (onChange), and encapsulates all other details within. Cx does deserve a deeper look, and I'll definitely give it a whirl some time. Also kudos for the extensive documentation you've so far written!
Here's an example of a complex lookup field in practice. https://github.com/codaxy/cx-starter-kit/blob/master/app/rou...
It's perfectly fine to add multiple bindings between lookup options and field's data. That works for multivalue fields too.
If you have any other questions I'm happy to answer in this thread https://news.ycombinator.com/item?id=12495728
The "React component inside of Angular directive" is fairly trivial and there's a million examples on the net. Just make a directive that calls ReactDOM.render on the element in the link function.
Angular inside of a React component is harder to google for, namely because there's so much misinformation saying its impossible.
It ended up being a variation of the discussion here: https://github.com/ngReact/ngReact/issues/80
(The code in the example isn't quite there...and its been a very long time since I did it, so I don't quite remember the tweaks I had to make).
But how did you get rid of the implicit anys when using JSX?
I used this compiler flag that forbids them and suddnendly nothing worked anymore. It seemed that almost everything returned any per default.
I use these typings: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/mast...
Then create my components like this:
interface Props {
}
interface State {
}
class MyComponent extends React.Component<Props, State> {
}
and everything is typed correctly (beside setState which is impossible to type exactly as of today)
They didn't just do this "because." There were sound technical reasons to do so. Angular made the correct decision, in my opinion, and decided to cut its losses immediately and right the wrongs within the framework.
Some services don't belong in JSX though - this is why you have the idea of stores in Flux/Redux/etc. Some data doesn't make sense to couple to the component hierarchy - doing so makes it very easy to create dependencies on the component tree, which decreases modularity, as well as has perf ramifications by increasing the DOM elements that get rendered unnecessarily by React. Some examples are data models, routing, and interactions with non-element DOM api (window.location, XHR, etc.). This also has a side-effect of increasing difficulty of testing what generally should be vanilla constructs not tied to various frameworks/libraries unnecessarily.
But you were talking about bootstrap components which obviously do belong in the component tree, so I'm confused by your response.
https://react-bootstrap.github.io/components.html#btn-dropdo... (click on show code)
vs
https://ng-bootstrap.github.io/#/components/dropdown (click on <>)
Source: Did some Java EE consulting here and there.
I'll be evaluating mobx for my next project, definitely, along with Relay. If I can maintain the same view-as-a-function-of-state approach of redux while writing less code, I'm sold.
function MyComponent(props: IMyComponentProps): JSX.Element { return <p>{props.x}</p>; }
For me, the power offered by Razor(cshtml) is too much to abondon.
interface Props {
bla: string
ble: number
}
export default function MyComponent({ bla, ble }: Props) {
}Not saying ng-2 is not an improvement, just that it's a big change to take in.
But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it. Loops on the other hand requires not just simple array iteration syntax, but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`).
This is my biggest complaint with adding logic to text templates; behind the apparent simplicity there is always an entire language.
All good, I'm probably tired (Australian time).
Maybe it's my inherit bias as an Ember user, but I'd argue Ember's templating language is alot simpler than you're suggesting
> But by logic I meant all sorts of control structures, which though looks light-weight at first, needs a large number of language elements to function. To name a few: variables, expressions (which in turn need operator precedence rules), scoping, and even composition if we count partials/templates with it.
Admittedly partials are a little weird, while I don't see them very often, it's still a fair point, however Ember templates don't deal with operator precedence as it doesn't have binary operators (entirely polish notation).
> Loops on the other hand requires not just simple array iteration syntax
Iteration doesn't have a blessed syntax, but instead utilises syntax that can be utilised by other components, and a better way to think of it is, the block inside the component is actually a function being passed to the component, which the component calls with every item of the collection.
> but also over hashes, and it also needs other constructs like filtering (`todo in todos | filter:search`)
It doesn't have pipes/filters, as that's easily expressed as a computed property in the js portion of a component. And I personally think scoping is pretty predictable imo.
Maybe you're just making a general remark about templates in general & i've read too far into it, then fair enough but in the case of Ember some of those don't apply, imo.
> behind the apparent simplicity there is always an entire language
Technically this is true, but I'm not sure why this matters, especially if it's trivial to learn? Because flip side of the argument, technically JSX is a different language to JS & HTML with even more complex semantics than a templating language because it carries the semantics of JS on top of it. You could make the same argument in favour of css over SASS/LESS, so I don't really see this as a big deal
SASS and LESS both add language semantics over CSS and suffer from the same problem. So does for example Jekyll's templating language. But in case of CSS, the language additions are a practical necessity - it lacks even basic abstractions, which the pre-processors provide.
So there - trade-offs.
I've written in more detail about this topic at http://www.jasimabasheer.com/posts/evolution-of-view-templat..., if you are interested.
I despair these days at the ridiculous number of command line tools you need to run, but once you've completely wasted 2 or 3 days of your life on these pointless things, cut and pasting command lines from setup instructions that give no indication what any of the flags actually mean, you can forget about them.
There were days when you just had to run an installer and then you were good to go. Or just get the latest version of the tools (and by tools I mean actual tools with a GUI and everything, gasp!) That's obviously really untrendy now.
But yeah, you can set it all up in VS to deal with the insanity for you. Good thing too, as the ASP.Net team have been drinking heavily from the command line insanity kool-aid.
And worse still, yes, that's the case for most people. Most people prefer using mice + GUIs. Why are we going back in time? Why can't we have tools that work as both GUIs and CLIs?
CLIs are great for automation (and keyboard obsessed users).
GUIs are great for discoverability and making it obvious to users what the 'normal' usage is.
It's absolute madness to go back to the days of CLIs.
JS is kind of a 'bad language' because:
1) It's missing some pretty important things. Try to determine if a value is a number. Seriously. Look into that mess. Or anything else. Doing simple type-checking is crazy, and we basically are resigned to 'best practices' - which is crazy.
2) Prototype chaining is a neat idea and has some merits - but in reality it makes things super-duper complicated. Ask 10 JS devs how it works and get 21 answers. That is bad.
3) Almost nothing is built in. You need to use a lot of 3rd party libs to do common things.
4) There is no such thing as 'JS' - ever browser, every version - you get completely different implementations. Maybe we can't blame 'JS' - but pragmatically, this means JS is a problem.
A minor issue is issues with packaging, encapsulation and scale, which is also a function of loose typing. When JS programs get complex, they get unruly, and you wish you might be able to do things in an OO language at that point.
JS is really light, and that has advantages - and I think it's the best language for a lot of async things - and UI's are inherently async - so that's good.
In 5-8 years JS might be 'stabilized' in terms of libs or de-facto standards and it will grow.
To anyone who's programmed in other, more established languages, I think it's clear JS has some weirdness that doesn't need to be there.
But I like it.
2) I felt the same way for a while, but recently I was working on something where I ended up really "abusing" the prototype system, and when you actually spend the time to learn it, it's not that bad! It's different, that's for sure, but it's not bad.
I like to think sometimes that if javascript came before C, would we still call many of these things "bad"? Would we call javascript's equality table "weird", or would it be C's that was the weird one? Would C be the star in a talk labeled 'Wat' where they laugh at the absurdity of 'a' == 97? So much of the stuff that people complain about in JS is because they have expectations from other languages. Sometimes those expectations are a good thing, but other times they are just different, and taking the time to actually learn how and why it's different can make you a much better programmer.
3) I genuinely like this about JS. There is no "one true way". The language is free to evolve, change, get new features, get new functionality, and easily "polyfill" old browsers outside of the release cycle. And that's important in JS because there is no one "authority". Keeping the stdlib small means that it's easier for new implementations to crop up, and it leaves the "niceties" to be developed by libraries. It's what allows libraries like ramada and lodash to be so powerful. They wouldn't be where they are today if the stdlib was more opinionated/complete.
4) But again I kind of like this. It does often make things more difficult, but at the same time it improves the ecosystem. I honestly believe that the fact that there are competing implementations is pretty much the only reason javascript (and in some ways, all dynamic languages) are as fast as they are today! Not only that but the fact that there are multiple competing implementations keeps most devs "honest". For the most part I don't need to worry about someone writing code that will run on version X on platform Y. I don't need to worry that the next "update" will require us to spend a week cleaning up removed functionality. It does lead to a lot of "crap" accumulating in the language, but over time that crap can and will be removed. JS is a fluid, constantly-evolving language, and because of that you tend target a point in time, not a "release", and the impressively awesome backwards compatibility means that while your older code might look outdated, it's not going to suddenly stop working.
I do agree that complex JS programs need much more tooling to be manageable, but it's working out very well in my experience. It's just different.
The fun thing watching the new world of Javascript is that overtooling is so built in to everything that nobody even realizes how many tools they're using. You can't even install this thing until you have the standard pile of javascript tooling in place. And it never occurred to them to even mention how to get said pile set up.
Once set up, this still uses all the same stuff. It just removes a few steps to produce the Big Red Button you press to run it all.
But then again, the thing about the overtooling is: I can't find anything in my React stack that is unnecessary or can be removed. And really, all it is is React, Redux and Webpack. I think the complexity of front-end Javascript development is blown a little bit out of proportion.
React could be replaced with Preact or Inferno.
Redux could be replaced with MobX or RxJS.
Webpack could be replaced with JSPM.
No thanks.
Isn't that hot reloading of components which they say is unsupported?
create-react-app set up all the build tooling, for a router the clear recommendation is react router, and for a flux implementation the clear recommendation is Redux. It feels like there's a well defined path for beginners. Over time you'll have to figure out how everything works, as is always the case, but you can learn more as and when it's necessary.
The bumps were more whether to use ES5 or ES6 (but then I found an official position in favour of ES6), and whether or not you need to use flux (although that was really just learning how flux worked, which wasn't wasted time).
The only uncertainty I have now is whether TypeScript will be necessary/useful in future, and if so how to integrate it.
It was very promising at first but typescript now has caught up with Flow best design decision: noImplicitAny, strictNullChecks.
Also, check on the "try typescript" website: typescript's JS output is almost left untouched. it's effectively a replacement for babel, if you only care for ES2015 stuff, and not some of the more recent stage 0 / stage 1 stuff.
The issue is that TS 1.8 doesn't support async/await in the browser until v2.0, but a ts -> babel transpile does the job nicely.
It was made for demos, proof of concepts, and beginners (at the beginning, maybe not anymore). I don't know how Angular CLI works, but if it works like Ember's, then there's no comparison. Ember CLI generates models, controllers, etc. any kind of thing and it enforces a file and directory structure that makes all Ember apps look the same.
I know a lot of work has been put in to angular-cli and it's been through a few iterations at this point, but I almost wish they would scrap the whole thing and fork create-react-app.
https://blog.jetbrains.com/webstorm/2016/04/angular-2-workfl...
it seems to me they in fact do support the embedded expressions?
Have you considered that part of the problem is the stack you use causes other people to be unproductive because it's not clear what all the tools you're using are doing?
Compared to this, typescript is actually dumb enough to require ts definition files to actually parse non-ts (js) files.
ES6 doesn't fix any of it, typescript fixes some of it.
https://babeljs.io/repl/#?babili=false&evaluate=true&lineWra...
Compare step 1 of http://www.ecma-international.org/ecma-262/6.0/#sec-isnan-nu... with http://www.ecma-international.org/ecma-262/6.0/#sec-number.i...
ng-bootstrap avoids problematic apis such as component-based modals, and makes use of the much more natural service-based approach to allow developers maximum flexibility. If a developer prefers a component-based modal, a developer can very easily build a lightweight component on top of it. However, having poor design built into such a third party library that is meant to be used for a large variety of cases is a terrible experience for developers, speaking as a consumer and as a library maintainer.
Extensibility is the key here, and we maximize for that while keeping the library as small as possible - bloat is bad, and that shouldn't be the default in general.
In fact from a peek at the source, the NgbModal class is built on a NgbModalWindow class which acts much like react-bootstrap's modal. So, ng-bootstrap builds the service based version on a component based version. If either library can be accused of bloat it ng-bootstrap for including the serviced based version when I might just want to use the NgbModalWindow directly. (Its not in the documentation, so I wouldn't actually use NgbModalWidnow directly in practice, even if I'd want to.)
Now, I've drunk the react cool-aid, so take my opionion with salt. But in my assesment while modals can be somewhat awkward in the declarative style, they aren't awkward enough to make me break my rule of avoiding imperative apis.
So, no, sorry, I don't eat that stuff. Bill Gates has built the most dangerous edifice and no amount of charity will save him from the Hell of digital beings.
And they said your angular 1 experience wouldn't carry over.
I've worked with AngularJS and React. After spending enough time with each framework that I'm "productive" with them and don't get constantly confused by what's going on, this is now by far the most important reason to me when adopting a framework. React(and Redux) just spoil you with an awesome debugging experience, and it's just painful for me to go back to any set of tools that takes some of that away. The rest of the points I've already "suffered" through with AngularJS, and it is my opinion that they are a rough, but surmountable cost. Having a poor debugging experience, however, just kills my willingness to work.
(For the record, AngularJS has some debugging aides - you can inspect scopes pretty easily given a DOM element. However, the watches and digest cycles, which do all the heavy-lifting, are pretty much opaque - you need to have a good understanding of how your watch expressions are compiled into watch functions and place conditional breakpoints deep within the framework in order to inspect why a certain watch is not being called/being called too many times)
I haven't found either of these to be the case. Is your experience recent? If so, will you expand on it? I like Angular 1(.5) quite a bit, but I'd be interested to hear more about a different perspective.
I remember posting an issue on stack overflow about an issue I was having on the first few pages of the guide, I realised I had misread the docs, and I answered the question myself. But that post is now my top voted question on SO, so I don't think I was alone on my experience with the Angular docs. Mind you this was 2014.
Compared with my experience with the Ember docs, the Ember docs & getting starting guide was way more readable & easier to follow. (also in 2014)
Other libraries and frameworks have multiple ways of doing things but most times the documentation would provide an example that could be considered the way to do things.
Thought that's a lot better than hunting down bugs in production.
To be brutally honest I think the only reason why this is on HN frontpage is because of its name. It's quite telling that they kept the name despite it being a totally different beast with (imho) an entirely different audience. No way they'd get this much support from the webdev community otherwise.
However I do see the potential, and one should not forget that this is just the first version, straight out of the oven.
Give it some time and I'm sure it will improve.
However, if you dislike the approach to templating, you will definitely dislike angular. This is one of those things that is controversial, regardless of which approach they had chosen.
I dread to go look at that code...
You just proved my point!
A) Even if you are correct - it's terrible. This is completely ridiculous that there's no basic check for extremely common and mundane type-checking. Moreover, it's the same issue for other types!
B) Worse: you're wrong.
isNaN('100') = false isFinite('100') = true
The string '100' would pass your check as a Number :)
Underscore uses:
"toString.call(number) === '[object ' + Number + ']';"
So noodle on that for a while: I'm assuming you're an experienced JS programmer and you can't test to see if something is a number! Embarrassed? It's ok. 9/10 JS programmers would get it wrong. I had to look it up! Which is my point - it's really bad!
2) Prototyping is not bad because it's prototyping - it's bad because it's really confusing. Point: nobody has - or will 'borrow' this idea form JS. Again - almost zero JS devs really understand how it works.
3) Again I disagree. There definitely should be a 'true way' for the most common operations. There should only be one 'true way' to test to see if something is a Number (!) - and for basic things like string operations - 'one true way' is better. For so, so many reasons.
4) "For the most part I don't need to worry about someone writing code that will run on version X on platform Y" - sure you do. You cannot use 'const' or 'let' in Safari/iOS. You can in Chrome. That's just the tip of the iceberg. There are dozens of such mismatches - and it's a fragmentation nightmare.
Now - I agree with your point about 'competing versions' hey, that's great. But they are 'not the same platform' - which is totally destructive.
(!isNaN('100') && isFinite('100'))
Negation (!) before isNaN()
(!isNaN('100') && isFinite('100')) === true
My check would treat '100' as a number, so if i did something like this it would break unexpectedly:
var num = '100'
if ((!isNaN(num) && isFinite(num)) === true) {
console.log(num + 10)
}
2) There are aspects of prototypes that JS makes much worse (mainly the whole "this" clusterfuck), but the base is pretty sane and easy to understand. But at that point i'm not even talking about javascript any more, so I guess you are right here too.
3) I still disagree with you here. Yeah, there should be a way for the stdlib to do simple low level things (like isNumber()), but for others "one true way" isn't the best. I'd love a better stdlib, but I don't want something like Go's stdlib. I'd rather the language define a "bare minimum" and let libraries take over the rest. Now, as with anything in life this should be taken in moderation, if there are massive gains to be had by including something, then it probably should be included.
Maybe this is stockholm syndrome setting in, but I'd rather have the choice of implementation of something in-language, because there are so many different engine implementations.
4) I was more speaking of things like a python library that only runs on 2.7, or a java application that only works on 6. For the most part, those things just don't happen in javascript. Yeah, you need to not use newer features until they roll out everywhere, but once they do, you are safe in using them for a pretty damn long time. In your example, you can't use const/let right now because safari is the last big holdout here. iOS 10 was just released, and with it Safari 10. In another month, i'd feel comfortable using const/let without transpiling it, and I won't need to worry about it again.
But another benefit of multiple different implementations is they are free to optimize for different things. For example, Espruino is a JS engine that runs on microcontrollers and is EXTREMELY low power. Chakra (Edge's engine) shoots for really fast startup speed. V8 is pretty much the king in terms of raw execution speed. Contrast this with the Java way of having a million settings, knobs, options, and flags in the engine to tune the system the way you want. Yeah, you can do that, but most don't because of the complexity and risk involved. And there is only so much that you can do while having to support every option in the same engine.
Like i said earlier, i'm not sure if it's stockholm syndrome taking effect, but JS is by far my favorite language, and despite all it's flaws, issues, problems, and mistakes, it's also the language i'm most productive in. And with ES2015+ it's only getting better. (although i'm dreading the time when modules start getting into implementations, and how they conflict with current solutions, that's going to be a NIGHTMARE in just about every way).
Every language has that. There are different JVM's, different C/C++ compilers, different python interpreters.
JS is not 'at any advantage' here - and again - the drawback is the ridiculous fragmentation we see across browsers - which is ... bad - at least compared to other languages.
For all it's issues, JS has mostly moved past that. It's pretty rare to see a javascript program or library (that's not just a tech demo) that only works on one implementation. Hell Microsoft released a node.js fork that runs on chakra, and to my surprise every single one of our node applications runs on it without a single change or hitch. (i haven't looked up if this is "normal" or if i got lucky though, so take it with a grain of salt).
Now obviously it's not perfect, and we should strive to be better, to fix these issues, but it's not like javascript is in some unprecedented scenario here. I actually think that the IE6 days have pushed JS to fix a lot of the problems that are plaguing other languages in this area.
With component-based modals, you end up with bad APIs for these use cases, as well as less control over your state.
Yes, if you build a component based api that supports multiple modals, resuing backdrops, lifecycle hooks, that api would suck and be a real pain to build a service version on top of.
A React component should not be trying to do all that, but merely produce the appropriate HTML for a modal dialog. That produced HTML can equally be used to build one-off "are you sure?" dialogs, a modal service, or what have you.
There's no way on earth we'd be arguing about such a ridiculously trivial thing for most other languages.
Nobody should have to look any of this up.
Yeah, we work around it ... but it drives me crazy. :)