I’ve been using ES6 modules in Ember.js development for two years now. Using Ember CLI is simplified down the dev process extreamly. The whole dev app development is so simple and fun with Ember. I don’t understand why people cry about it, the solution is exist, they should just use it. Thats all.
The Controversial State of JavaScript Tooling
131–140 of 160 posts
Re: The Controversial State of JavaScript Tooling
#132It's interesting how none of the JS/tooling fatigue discussions mention Ember, which has one public-facing tool.
So true. Ember is the antidote right now for the frontend land. - MVC (Backbone's big thing) - Two way binding (Angular's big thing) - Components (React's big thing) - SSR like the others now (FastBoot) - High performance with the Glimmer Engine (should beat react in theory) - Books. - dedicated package repository (emberaddons) - actually community driven - stable + mature (+ seamless upgrade paths) - and many more a…
Yep. Ember is the best solution out there at the moment. There is a trend, that silently more and more serious dev team switching to Ember. Ember never had hype period. It works and it is really matured. With Ember you can focus to your product and you don't worry any more about tools. I think most of the Ember dev is just smiling when they see these debates, because for us everything work and we ship day by day with a very high level of developer happiness. :)
Re: The Controversial State of JavaScript Tooling
#133Interesting how the industry has come full circle. Static linking and dead code elimination is a problem we solved in the 1970s for compiled languages. Has the time come to adopt a proper linker for the web? Google's Closure Compiler has supported dead code elimination [1] since 2009, but the feature imposes some unpalatable restrictions. It never supported popular libraries like jQuery. The process is also rather sl…
An interesting thing is how that applies to transpiled languages like ClojureScript. There are a lot of efficiencies gained by using ClojureScript with Google Closure. Even react is faster with Reagent.
Re: The Controversial State of JavaScript Tooling
#134Something that's been concerning me about the current approach to web development in particular is the accumulation of unacknowledged -- and increasingly unmeasurable -- technical debt. I'm not sure that's precisely the right phrase, but here's what I mean: we all (should) know about technical debt in our own projects, but we also know that every project accumulates technical debt. When we build our projects on top o…
I think if anything you're being too kind here. The way dependencies are typically handled in the Node/NPM ecosystem is horrendous, and this has serious negative implications for the stability and longevity of almost any project built within that ecosystem today. Unfortunately, modern web development is led, at least in publicity terms, by people who think phrases like "move fast and break things" and "living standar…
The Node / NPM system is fantastic. Even my design colleagues use it on a daily basis, and for them, 'npm install' just works. Interesting that Microsoft have adopted a very NPM style with their new .NET Core project.json files.
Re: The Controversial State of JavaScript Tooling
#135The web community is flooded in negativity because it was swamped by kids with overly idealistic, unrealistic, and heroic ideas about what the web was going to be post-Facebook. Those people then realized that the web is, like all things, both real and imperfect. So now they're upset. This is all part of growing up. People who have been involved with the web for a while are not in any way more jaded then before. They…
If this has a grain of truth in it, the 'older crowd' need to lead by example, stop shaming 'kids' for their age, and prove why their old products are better.
Re: The Controversial State of JavaScript Tooling
#136Earlier quoted context omitted.
> But we've reached a point where modern web applications are pulling in dozens of dependencies in both production and development toolchains, and increasingly those dependencies are themselves built on top of other dependencies. Um, take ANY non-trivial application, written in any language, and then follow the chain of its dependencies all the way down to the kernel, and shriek in horror. JS is not unique here, the…
Sort of kind of. I deal as a consultant for large corporations where down-time is a no-no. Think secondary market-makers, institutional investors, healthcare insurers. Not quite rocket control systems or firmware for dialysis machines but five-nines is a given. Bugs happen everywhere. That's an axiom. You can decrease the risk of it with formally verifying the system (see: SPARK for Ada), but they'll occur. The diffe…
Thanks for the insight.
FWIW we use Angular where I work, without any JavaScript build tooling (only for SASS), and it's actually fine. So taking proven solutions that have been around for a couple of years in the front end world is not a bad idea, if you want to just Get Things Done.
At my last place we used React with all the latest hotness, and had ongoing issues with complexity and devs having to keep up with all the new tech.
Re: The Controversial State of JavaScript Tooling
#137I think the javascript ecosystem has a fundamental difference from all other languages/communites that came before it: it is universal. Hence I think a lot of the debates raging about the right tools come down to different people using it for different purposes. I doubt that everyone can consolidate on just one set of tools, because in javascript-land "everyone" means something different than other places. How can a…
This is definitely part of it. JavaScript tooling encompasses back end, front end (progressive enhancement inside server generated web pages), front end (large single page apps), and a bunch of language flavours (ES5, ES6, ES7, TypeScript, JSX, to name a few). So it's understandable the tooling ecosystem is large and diverse, and that plumbing it all together can result in premature hair loss.
We're using ES5 with AngularJS at work, and it's like a breath of fresh air ;)
Re: The Controversial State of JavaScript Tooling
#138The problem with hypermodularization is that it takes time to make a decision on what module to use for every task. If you have to to do this with 100s of modules, you're wasting a lot of valuable time. Does anybody know a quick way of making the right decision? NPM is like a crowded graveyard nowadays (or like .com domain names - where all of the good module names have been taken along time ago and now all the best…
> I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only one of these, it seems to me, is likely to be consistently related to the quality of the module.
Don't keep us in suspense. Which one?
Re: The Controversial State of JavaScript Tooling
#139Something that's been concerning me about the current approach to web development in particular is the accumulation of unacknowledged -- and increasingly unmeasurable -- technical debt. I'm not sure that's precisely the right phrase, but here's what I mean: we all (should) know about technical debt in our own projects, but we also know that every project accumulates technical debt. When we build our projects on top o…
More simply put, stability is not valued in the front-end world. It's interesting to compare the dominance of Microsoft in the enterprise world where IT runs the show was established largely due to stability. IT is run by managers who can get fired if instability costs the company money. In the front-end world managers can't keep up with the changing landscape and therefore cannot make stability based decisions (in t…
It's a bit ironic to praise Microsoft for stability in this context, when they probably have had a major role of causing instability in the web front-end world for more than a decade.
Re: The Controversial State of JavaScript Tooling
#140Earlier quoted context omitted.
> I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only one of these, it seems to me, is likely to be consistently related to the quality of the module.
Don't keep us in suspense. Which one?
The find/fix rate is one I look for.