11–20 of 200 posts
It is good to see that the community is open to introspecting and improving even further
Dan Abramov wrote a brilliant post here, IMO. So much here. Unix Philosophy, yes please. Considering the cognitive load of tool options and configuration knobs, and the impact of the JS ecosystem for beginners. "A tool should work with (almost) no configuration." Amen. "Mind your output" from tools (errors must be helpful and sort the important from the unimportant); I've felt this pain and have abandoned tools at th…
I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…
Really curious what is actually wrong with "crude bash scripts for building"? I had experience with both types of projects - the ones with home made crude build tools (in Python, not bash), and the ones with modern javascript build pipelines. The first build never broke. The second build would break every couple of months for no obvious reason without us touching the project structure.
The problem is opportunity cost. The rest of the tools in the market (Webpack, Rollup) are offering heavier benefits like automatic code splitting, dead code elimination and such things.
Very nice points here. I've always been struck at how the JavaScript community never really adopted the Rails ideas of convention over configuration and optimizing for developer happiness. While it's easy to roll one's eyes at the marketing lingo, these principles do truly make Rails a charm to use. Right now, even setting up the most simple Webpack-Babel-Node config requires writing a whole lot of config and set up…
While I agree the package management in JS could have been better, most other too-much-config problem is just because of the variety of problems and the variety of potential solutions.
I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…
Earlier quoted context omitted.
Es5 only? Jeez that would be an immediate dealbreaker for me with any potential employers.
Well, for those of us from the 2000s era of web dev ES5 wasn't such a deal breaker. It isn't very concise, but ES5 isn't so bad either. ES5 to ES6 isn't what Java is to Python. It's more like what Python 2 is to Python 3.
There are some coding styles that are popular in esnext that just aren’t practical in es5 because they would be too verbose and not “read” very well.
I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials. It is good to see that the community is open to introspecting and improving even further
I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app,
I seen it uses npx(not sure when this tool appeared) it also used tons of dependencies, in the end I created my app from scratch using only the TS compiler package and the react client library, no extra tools, magic, 1 month old tutorials that are outdated already, no install latest tool of the month etc.
Earlier quoted context omitted.
Well, for those of us from the 2000s era of web dev ES5 wasn't such a deal breaker. It isn't very concise, but ES5 isn't so bad either. ES5 to ES6 isn't what Java is to Python. It's more like what Python 2 is to Python 3.
This is interesting. Today, when people say ES6, I feel like they actually mean esnext, as once you accept a transpile step from TypeScript or Babel, you might as well get the benefits of new language features in your codebase. I wonder how many people mean es2018 when they say es6, complete with some pretty dramatic code style shifts, including a tendency towards classes, async/await, and composition-first nameless…
This is why coffeescript was a godsend. It produced very efficient code too, simpler and faster at runtime than the ES6 replacements.
I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those im…
At Blockvue we have also had a lot of success going back to basics with vanilla js. Doing a large SPA in vanilla js is actually a charm these days and the result is extremely lightweight and fast. The SPA concept is sort of new, but if you really commit to not doing any server side page generation the result is so easy to manage. This also allows us to focus on having a fast crystal-based API backend to power our SPA…
I'd bet any of us could find a ton of weird and unintuitive things your app does, as well as it probably being slow to load, hard to use and brittle, in that you'll regularly put out an update that inexplicably breaks something for a day or two.
Add on top that massive extra expense of doing a pure SPA compared to the ease and simplicity of developing a mixed server/front side app, I have no idea why anyone sane ever signs off on a SPA.
And that's before we even get onto the vastly better tooling and development environments that server-side languages have.