My team maintains an old coffeescript+knockout UI, of which we're slowly replacing pieces with modern React code. The project has a complicated build system, but we've been able to hook create-react-app into it and inject the bundled files into the main app. This works, but rebuilds are costly.
How can I improve our development experience by editing whatever we can inside the browser, rather than waiting for a full rebuild on each change?
In some cases we can just use the CRA dev server which is great, but we often rely on styling and code from the rest of the app so working on each component in complete isolation is difficult.
Thanks!
For CSS you can always use your browser's dev tools to change styles until it looks nice, then you copy from dev tools to your app and only have to rebuild once.
For JS you could use Hot Module Replacement (HMR) as a webpack plugin (not included in CRA, you will have to eject).
Related
I was wondering how you would go about managing .SCSS files when a project has launched. For example I manage a number of websites & use the power of SCSS while building them.
However once a project has launched if I'm required to make a small edit currently I just ftp to the minified .css file and tag the extra few lines to the bottom... Bad I know!
Then when it comes to a larger change to an existing project the .scss files are rendered unless as the .css is ahead of the .scss therefore re-compiling the .scss will overwrite smaller chnages that have taken place.
The only way I could think to go about this would be to create an _updates.scss file and tagging all the small updates into this file. However this will take much longer than the current ftp'd changes.
What would you recommend?
I'd suggest still using Sass, it seems a waste not to after you've used it this far too for building the majority of the styling. It sounds like less of a Sass vs CSS issue (once on live) but more of a poor workflow.
If it seems slow editing once it's on live, consider an improved workflow - Use Git for version control (or similar), and possibly setup deployments, along with Grunt/Gulp to make Sass watches and recompiling a little easier to once it's all setup (sometimes it's a good idea to extend the functionality of these task runners to lint and minify code). Then you can stay up to date (using Git), make required changes and then you can deploy the compiled stylesheets. I use this simple workflow for a lot of projects, big and small and it's very efficient. Keeping an efficient level of maintainability for codebases is essential i think, and the first place you can improve this is your workflow. (see above)
I'm planning on learning SCSS, but not sure if it's only meant to help the dev, or that the server of the website I'm making should also have knowledge of that.
It's going from SCSS -> CSS, so the server shouldn't notice anything ?
SASS/SCSS is a language that has features allowing the author of CSS to keep track of properties within CSS in a more organized fashion. It also allows variables and other things which are not part of the CSS language. This is done by compiling the language into plain, regular CSS.
So a program is needed to translate/compile SASS/SCSS into CSS and that's easily installed on your computer or server. Other than doing the compile, it doesn't mean anything to the server at all.
It's an aid for the developer, not the server. To the server, it's just text it serves along with the HTML, javascript and other things.
Great choice to start learning SCSS. You can do either. You can use a server middleware to auto compile your sass when it changes, or, do it yourself with a compile tool and serve the resulting css file along with any other assets you may have.
I checked one of application built with the Meteor web framework http://demo2.telescopeapp.org it loaded huge JS file, about 2.6Mb (minified, unzipped).
I also created an empty app, and it also loaded about 1.2Mb JS (non-minified, unzipped).
Is there a way to make client side JS for Meteor Apps small? Let's say less than 500kb?
With meteor 1.1.0.3, the default app's bundled js weighs in at 329k. It's pretty substantial without adding anything yourself. A few things to keep in mind:
Meteor doesn't ship HTML - it's rendered via js.
Meteor's intent is to pay an up-font cost to load the application, but not have to go back to the server after it's running.
Version 1.2 will allow you to separate meteor-platform into some of it's component parts, so you could include fewer parts of meteor by default (e.g. if you didn't want to ship with jquery or mongodb).
So the answer to your question is a pretty straightforward - in order to reduce your code size you need to include fewer packages and write less code.
It's worth mentioning that meteor currently doesn't have a way to selectively load a portion of your app (it's on the roadmap for a future release). For some apps, you can reduce your overall size by separating it into smaller portions and serving them on different subdomains. The canonical example is separating the user and admin portions, rather than bundling them together.
Our team works with many websites that use Sass/Compass to compile and minify CSS.
Working with this current setup is great when you have all of the files stored locally and your development workflow is setup. However, when you push the site live and a few days down the road are asked to make a change, it's not a huge deal, the local files are there and you just have to compile and push up again.
But if you are working with a site someone else pushed live and now need to make a small change requested by the client, you have to pull all the files down, setup the development workflow with Sass/Compass and make the changes then compile and push up again.
This process is extremely time consuming when you have to make 20 small changes in a day.
It would be ideal to only have to:
pull one file down,
make the change,
push it live and somehow the server complies it.
I haven't been able to find a solution and I also am not an experienced server side developer, so I'm asking you guys if you have a better development workflow setup that allows for all of this to happen and yet, makes it easy to make small changes in the future.
Little information, but I think it would have to do to use partial file css several are not generated to compile.
I'm writing a small Mobile Web Application to get started.
So far so good, however I'm considering optimizing performance server-side.
After read about server compression and caching, I'd like to implement fingerprint of static resources. Basically, both W3 Mobile Web Application best practices and Google performance guide recommends it.
I'm using Grunt as the main tool to switch from development to production.
Found that Grunt got two plugins that can help me achieve that :
https://github.com/testdouble/grunt-asset-fingerprint
https://github.com/sapegin/grunt-fingerprint
However, I'm not sure how to update the html file to update link matching updated fingerprinted assets. Should i use some template variables ? I'm not a Grunt expert, use it only a few times for simple task so that might be the template system I have to dive in.
Anyway thanks by advance
If you're not too comfortable writing your own grunt tasks and would like to have asset fingerprinting as well as a ton of other features I suggest you look into Yeoman
http://yeoman.io
It'll set you up with a template for your webapp that just works. I've started using this quite a lot.