101–110 of 250 posts
Expectation: - "Hey, look, this can SOLVE ALL THE PROBLEMS" Reality: - "Hey, look, this actually BRINGS IN A WHOLE LOT OF OTHER PROBLEMS too!" :sad:
Earlier quoted context omitted.
What an odd and arbitrary list. SASS support over LESS over PostCSS over CSS in JS? Component boilerplate generation is required for production? Hot module replacement is required for production? Everyone using React is looking for an isomorphic solution? Docker support?! I think the point of the project is to acknowledge that React requiring transpilation to use is 100% accurate and there needed to be a transpilatio…
> SASS support over LESS over PostCSS over CSS in JS? Well yes, because any CSS in JS solution (in PostCSS) is just plain bad for a myriad of reasons. That would leave you with SASS vs LESS and SASS is massively more popular and supported.
PS. Already in /src/App.js , and wow live reloading without gulp or browersync , it is so simple to get started! Thank you!
Earlier quoted context omitted.
This right here is why I actively suggest not using webpack. It's Grunt 2.0 all over again and not worth the mess. IMO it's the worst choice Facebook could have made for this toolkit, as it breeds some awful habits.
Could you give me some detail on these "awful habits" you mention? As a webpack user, I'm genuinely curious.
It's config heavy for very little benefit.
> Having just attended EmberCamp a week ago, I was excited about Ember CLI. Ember users have a great “getting started” experience thanks to a curated set of tools united under a single command-line interface. This is one of the best things about Ember. `ember new`, `ember serve`, ember generate component my-component`, `ember build`, `ember deploy`, `ember install`. It's opinionated but it lets you get productive rig…
Currently playing around with the idea of a React app for building React apps.
Basically, it's an admin for specifying routes, models, components, database schemas, views, stores, reducers, etc. They are defined declaratively and serialized. Then can be feed to either a build step or a bootstrap that can load create the app dynamically.
Each type of thing that can be edited has its own dedicated UX.
Not much built yet but I'd be curious if anyone else has similar ideas / solutions.
Earlier quoted context omitted.
> The problem is that when frameworks develop these CLIs they tend to think only about the CLI users and it becomes larger and larger a requirement Well there are two ways to modify an Ember project: create a bunch of files in various places by hand, or run `ember whatever` and have it done for you. The CLI is the preferred way of doing it for a lot of (good) reasons but if you want a new component running `ember g m…
> I don't understand your point? What's a 'normal web technology'? https://html.spec.whatwg.org/multipage/
I mean, you're commenting on a thread about JS libraries that enable you to write awesome single page apps and saying you... don't want to write JS?
If I get you correctly then I used to be like you. "Eww, javascript". Then I was forced to use Ember for a project where I work and it is amazing, nothing that the app does could even remotely be done with HTML or even a bunch of jQuery spaghetti.
Earlier quoted context omitted.
We think ES6 is not the problem here. It’s just a language, and arguably a better one than ES5. The problem is the low level tooling around it. This is what we’re trying to fix with this project. Hopefully you’ll give it a go, and maybe it will give you just as much enjoyment as using tags. If not, please let us know how we can improve. It’s not linting/transpilation/bundling that’s bad, it’s that it’s hard to do the…
I think the problem is that React is developed as more of a Node/JavaScript project than as a web project. You see this in stuff like depending on `process`, a thing that exists in Node but not on the Web. So the Web is a compilation target; not the platform that React is developed for. From there it's easy to think about everything in terms of JavaScript, and not making the Web the intended target for usage.
However I do wish the React team would pick between ES6 classes and `React.createClass`. I think I remember the main React tutorial was rewritten in ES6 at one point, but then switched back. I've read arguments both ways, but I suspect they ES6 is still too much of a barrier to entry.
People who aren't up to speed with ES6 will still be shaving a lot of yaks before actually jumping into React.
Earlier quoted context omitted.
> I don't understand your point? What's a 'normal web technology'? https://html.spec.whatwg.org/multipage/
So you want to write HTML for a living? Ok, that's cool. But things have moved on a bit since then. I mean, you're commenting on a thread about JS libraries that enable you to write awesome single page apps and saying you... don't want to write JS? If I get you correctly then I used to be like you. "Eww, javascript". Then I was forced to use Ember for a project where I work and it is amazing , nothing that the app do…
They are saying that they aren't going to make the CLI a requirement and I hope that's the case, but my concern is that "use the CLI" is going to become the quick answer.