I am not a professional developer - I'm just a self-taught amateur in the field, and I followed the trends with quite some delay. My history with javascript goes back to when I was 14 years old and randomly opened files on my C:/Windows/ directory (it was Windows 98), until I found some intriguing .js files. I learned PHP, C and python, but came back to Javascript and follow his evolution from a scripting language to a full-stack tool - first, I played with Jquery a Jquery / XSLT stack, then made a little videogame using Websocket and Gulp and browserify , then recently learnt some Angular, Ionic and Vue, all based on Webpack.
I'm having though about what tool to use as a task manager. Especially, I tends to think most of the tools used these days are inefficient - hard to configure, needing a thousand plugins to work, which often create incompatibilities between versions,... And more importantly (I may be wrong here) but how come none of them are checking which dependencies need to be rebuild?
Last time, I was launching my test in a typescript project using npm test and got really frustrated. I realized the whole project was compiled every-time I changed a tiny detail in my test files. Having developed in C, I found that really inefficient and wrote a makefile to address that.
Now the bad side of make is that it's kinda hard to make it work with modern javascript tools (tsc explicitely adviced me to use a .tsconfig file instead of the CLI). Another example is there is no official CLI tool to compile a .vue file into a render() function.
Now my question is is there a modern tool that doesn't require me to rebuild, compile, minify, uglify my whole project and lose 30 seconds every time I add a commas in a file? and what's wrong with make?
I would take any idea or correction about that matter with gratitude :)
I don't know the exact nature of your project but I don't think there is a single tool for all the things you want to achieve. That's why we have the term "javascript fatigue".
Currently Webpack is the closest thing we have "one ring to rule them all" in terms of module management in development environments for javascript projects.
Now my question is is there a modern tool that doesn't require me to rebuild, compile, minify, uglify my whole project and lose 30 seconds every time I add a commas in a file? and what's wrong with make?
Since you mention you are familiar with webpack, maybe you can checkout its hot module replacement feature. Here is its description straight from the developers' website:
Hot Module Replacement (HMR) exchanges, adds, or removes modules while an application is running, without a full reload. This can significantly speed up development in a few ways:
Retain application state which is lost during a full reload.
Save valuable development time by only updating what's changed.
Tweak styling faster -- almost comparable to changing styles in the browser's debugger.
It is a sad fact that with each tool comes extra cognitive load. To reduce it, maybe you can:
follow certain patterns and habits in your workflow
have basic setups or boilerplate projects for frequent ones
check out the best practices
take advantage of cheat sheets and API docs
checkout source code before searching on the internet, It maybe less time consuming and less confusing than searching on the internet
try to master few vital tools for your projects
Following the works of developers who move the community forward maybe helpful for staying up to date with technologies, usually they gave speech and write articles.
It may look a lot of work when you see them listed one after the other but you will see it is more rewarding and less time consuming in the long run.
Please remember that, it is a common problem among developers, even the best ones suffer from it. That is why we have these tools in the first place. Good news is that, with every passing day dust is settling and tools are getting better, more mature and more stable.
For more on hot module replacement:
https://webpack.js.org/concepts/hot-module-replacement/
Related
I want to start leveraging http://webcomponents.me W3C standard which is now supported by all major web browsers.
I researched the internet and so far I found following frameworks:
Stencil - Created by ionic. All ionic components use this framework/compiler in order to build native supported web components.
lit-element - Created by Google and is part of Polymer framework.
SkateJS - Don't know how is behind this but it is in top 3 popular web components framework.
Can someone give me advice or opinion which framework is best?
If you want to build:
Fast
Easy-to-debug
Cross-browser
Framework-agnostic
web components you could also consider using framework :
http://vanilla-js.com/
As I've been working with native vanilla JS web components for the past 4.5 years as my main subject, I would like to add my opinion as a seasoned web developer with almost 30 years of experience.
As with all development tooling, these tools share a common problem. Either they
evolve - forcing you into an undesirable update loop, keeping you busy with stuff that's long-finished just to keep the tooling fresh and secure,
or they just "die" - check SkateJS e.g. The last commit on that repo is now 3 years old and open issues from 2019 exist that haven't even been commented on. The latest release is from 2017!!
This is not only true for authoring tools like the three suggestions you mentioned - this is also true for the whole build stack tooling.
Last year I took a dive to see what kind of modern build tools would be nice to work with for authoring web component libs. When doing the research, I stumbled upon Snowpack and Vite.js. We started out with Snowpack, but at the time it still seemed to have a number of stability issues, so we decided to switch to Vite.js. Last week I decided to give Snowpack another shot, only to find it deprecated in favor of Vite.js:
Stuff like this happens way too often, and while tooling should help you get stuff done faster and better, more often than not you find yourself dealing with the shortcomings of the tooling, incompatibilities with addons when updating the main library, security issues... rather than focussing on doing your business coding.
This is also true for popular tools like Storybook.
Once you start relying only on ECMAScript itself, and the browser API, you'll learn that most things like e.g. routing for SPAs are quite easy to develop yourself.
You probably won't need a build stack any more very soon. We have widespread support for HTTP/2, making bundling undesirable anyway, so just work with native ES modules. Not using a build tool and not bundling also has the huge benefit of not having to generate and rely on maps any more; let alone the fact that it immensely improves the development experience by keeping turnaround times in no-matter-how-complex projects in the ms realm. Code-you-write-is-code-that-runs - how amazing is that? No third-party-black boxes when your debugging leads you into code that would take you years to understand.
Instead of CSS preprocessors, work with native CSS and custom properties - native CSS nesting is coming to browsers as well.
To go fully build-less, there's unfortunately still some bits and pieces missing, but those are in progress. The most important ones are:
CSS Module Scripts <- We have these now. HURRAY :)
HTML modules
JSON modules (Stage 3)
Some libraries are already picking up on this, e.g. ficus.js.
Background
Starting on a new vue.js (2.0) project. I've worked with vue-cli in other projects (vuejs-templates/webpack) and found the build process difficult to grasp when doing any kind of changes.
On top of that, webpack is infamous for its lacking documentation, therefore it turned out to be a lot of work even to achieve minor tweaks to the build process.
In general, I believe I understand both webpack and vue-loader. I'm still having a hard time getting the full picture of vuejs-templates/webpack though.
Question
I'm considering rolling my own webpack config for this app, but I'm concerned I'll eventually end up with a build process as big as the current vuejs-templates/webpack.
My plan was to work my way up from vuejs-templates/webpack-simple and not overcomplicate things too much.
What I have in mind is a config / build process situated somewhere in between vuejs-templates/webpack-simple and vuejs-templates/webpack.
I'm interested to see how others (with perhaps more experience that I have) feel about vuejs-templates/webpack. Wonder if it will just get harder to use as the project grows or if it will all make sense eventually.
Does it make sense to roll my own webpack config / build process or should I just suck it up and use vuejs-templates/webpack?
After about a month of working with Vue, vue-cli & webpack, I figured out the following:
1. Roll-your-own boilerplate
This feels a lot like re-inventing the wheel. There's more than meets the eye: writing up all the config, loaders, picking a folder structure & setting up tests takes a considerable amount of time.
You'll be frequently shifting focus from developing your app to tweaking the build. There will be many small things you need as you develop, but the pain will be considerably reduced by using vue-loader from the start.
To sum up: this is a very big decision & you'll need to be ready to invest a considerable amount of time in it to be fully set up.
If your setup is so custom that you have to roll your own boilerplate, then be sure you'll have to redo a lot of the work that's been done already in templates/webpack. If you must, don't hesitate to get some inspiration from the current templates/webpack boiler, there are some neat tricks that you might want to use in your boiler. You could also start from the simpler webpack template and work your way up from there.
2. Fork templates/webpack
If you plan to redo some of the folder structure and perhaps change some of the core libs, it's a good idea to do your own fork of templates/webpack instead of starting from scratch.
It's not going to be easy at first, but as you begin to comprehend the structure & tools involved you'll realize the initial frustrations were well worth it.
As a bonus, you can install it through vue-cli and easily re-use it for other projects:
vue init username/repo my-project
3. Tweak templates/webpack
Sometimes you won't know in advance how your boilerplate will look like. In that case, I've realized it's fine to start with templates/webpack and do small changes along the way.
In that case, it's going to be hard to move it to it's own repo and install it via vue-cli. My recommendation is to take notes on whatever changes you do to the boilerplate (or add a #hash or smth to those commits).
That way, when you start your next project you can follow approach #2 and use it via vue-cli.
Conclusion
I think many of the issues you'll have with changing templates/webpack are also bound to pop up while doing it from scratch. It's probably because of Webpack's poor documentation (hey, Webpack 2 is looking better!) and the ridiculous amount of tools you need nowadays to build a JavaScript project.
Use templates/webpack and don't look back, the time you'll spent understanding it and vue-loader is waaay below the time you'll spend setting up your own boilerplate.
I recently started working with a large code base with many (15-20) js requests per page. I'm tasked with optimization and performance improvement of these sites.
I've been using tools like Google's PageSpeed and Yahoo's YSlow in conjunction with WebPageTest.org's tests to determine a baseline speed of the site and area of improvement. I'm curious if there are some standard or best-practice solutions for concatenation and minification of JS and CSS files.
I watched: http://www.youtube.com/watch?v=30_AIEhar-I and the first 20 minutes were really good at hammering mod_pagespeed as a good target.
I'm currently considering mod_pagespeed with a YUI compressor and perhaps a sprite generator on top of it all.
What are some good tools that I may have missed or things that I should be concerned about with my current build?
Edit: It should be noted that this is one page of many (possibly hundreds) and the site receives a new build every two weeks so being able to automate this concatenation and minification is a must, I can't just do it once and call it good.
Edit 7/30/2012 -
I spent some time looking at different tools, it's hard to say which ones are the best but at this time, not very many people use mod_page speed.
Closure is more widely used for certain, but even that is lacking. It seems the optimal way to do this is to just use a plugin with YUI.
There are other places that suggest Packer but it seems that many believe the smaller file sizes are eliminated by the necessity to unpack them on the client machine. This stackoverflow response is a good read regarding these types of tools.
Google's Closure Compiler is quite nice for concatenating and minifying JavaScript. It has the added bonus of linting your code for you when you compile, it will remove dead code, and it can also perform compile-time type checking if you include type hints in docblocks.
In certain cases, the dead code removal feature gives Closure a huge advantage over other minifiers... for example, think of cases where you include a library, but only use about 10% of the functionality. The other 90% can be removed if you compress the library along with the rest of the project.
As for CSS, YUI compressor is probably your best bet if you want something fancy. Otherwise, you could just concatenate the files together using cat and take the hit of a few extra bytes from whitespace.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am a java-programmer and a few months ago I discover frontend programming with javascript and html, and it is absolutely cool. So here is a js newbie's question.
Is there any IDE, default workflow or maybe best practices for javascript libs development? I didn't mean coverage and unit testing or something like this. I mean is there any tools or techniques which should I use while developing html control with some js-logic, for example? Should I write small test page in text editor and open it in dozen of browsers pressing F5 each minute and watching at browser's console or maybe there is some magic IDE which will on button press reload all browser instances and collect reports from browsers?
JavaScript Fundamentals
Be sure that you know the language. JavaScript is a bit tricky in this regard: you can easily think that you understand the language, but there are weird things that can sneak up on you. I highly recommend JavaScript: The Good Parts by Douglas Crockford. He also has some talks on Youtube with the same name that are definitively worth watching.
JSLint
Integrate JSLint or a similar tool in your workflow. It is a style checker and static analysis tool for Javascript and helps catching subtle bugs.
Avoiding F5
Check out live.js:
Just include Live.js and it will monitor the current page including
local CSS and Javascript by sending consecutive HEAD requests to the
server. Changes to CSS will be applied dynamically and HTML or
Javascript changes will reload the page. Try it!
Browser Developer Tools
Get familiar with them. I personally strongly prefer Chrome's developer tools over Firefox/Firebug, but regardless which one you choose, learn how to use the debugger.
Node.js
You should also be aware that you don't have to test Javascript logic in your browser: you can use it as any other scripting language using node.js.
As a seasoned programmer here are the steps you should follow for JS lib production.
Separate the UI from the application logic. In this case create one component for the application logic that is completely separated from all API access. API access, which means DOM and WSH and Node.js, should be separated out. I go so far as to use different files to force and ensure separation.
Create UI environments to access your logic. Have a production UI control for access by your audience and also a separate internal UI control for your sandboxed development. For example I have written my application at http://prettydiff.com/ to work from commandline, and from a browser. I have also written access methods to the application access similar to the published HTML but different for my own development for more rapid unit testing. In a sandboxed UI can use a recursive setTimeout to refresh the page in intervals for automated test plan verification as you are writing and saving code.
Focus on availability and distribution. People can get my libraries directly from my website, Github, and NPM for Node. I have a regimented process where by I upload code to the site during a production release and then perform a quick verification in the browser. If the release did not break the application then push to Github and then push this exact same location to NPM.
Distributed access to code operation is even better. Its nice having rapid and even automated access to libraries online, but being able to access unit testing via request is even better. I can remotely unit test my application's code by accessing code samples online directly by telling my application request a code sample via URI. This means that not only is my static code available for distribution and testing, but so is its operation.
Good documentation is everything. I will never even bother to examine a lib if the documentation is weak. I am not talking about code comments, though these are important. I am talking about end user documentation. I want to be able to read documentation and know everything about the subject. Node.js became popular because even before the codebase was stable it's documentation kicked ass. Get other people to QA your documentation before they QA your code. Without stunning documentation your lib is less than worthless to me.
Know your mission. Each and every lib should have a clear, simple, and well stated purpose. If this is not established then the lib is not ready for release. If an enhancement confuses the lib's purpose then it may be time to divide one library into multiple smaller libraries. Focus on precision, clarity, directness, and only the sole stated mission of the lib.
Independence is vital to adoption. I don't like libs dependent upon other libraries or frameworks. Its great that your jQuery library may be the best thing since slice bread, but I won't be looking at it. Independence means greater portability and freedom it mix and match it with other libraries that you are not aware of.
Style is important. This is touchy subject, but style is important. Keep the logic in your lib as simple and declarative as possible. If your code is absolutely declarative in nature then your algorithmic patterns are awesome. Avoid use of the new keyword unless you are an experienced JavaScript badass and severely limit use of this keyword as it will fail you in future maintenance operations. Do not algorithmically build out large strings with concatenation and continually watch the execution speeds of your code. Because even trivial changes to style or seemingly minor enhancements to the logic can destroy execution efficiency I put a timer on all my UI controls. In your development use profilers, such as Chrome's web tools to track down long operations in JS execution.
Be open about your failures. Software is never perfect and other developers will always respect this. If you encounter a bug before anybody else then be open about the existence of the bug. If it will take more than a week to get the solution out then don't delay notification. Notify your users immediately so that they are aware. I recently rolled back a major enhancement to the logic of my diff algorithm because additional unit testing showed heavy slippage. I rolled back the same day I made a decision the prior release or two was flawed and was open about the rollback. If you want people to contribute to your code base or provide bug reports then openness is critical.
I know you may have explicitly said that you didn't mean unit testing, but that is precisely the way I recommend you write javascript libraries.
If you're a Java developer, you may be familiar with jUnit. If so, qUnit may be more natural to you. Otherwise, I recommend you take a look at Jasmine or Mocha. While I prefer Mocha, my experience with Jasmine has generally been better for in-browser development thanks to the awesome Jasmine-Jquery plugin.
If you're writing qUnit tests, take a look at IntelliJ IDE which allows you to execute tests in addition to providing code coverage.
If you're developing on the browser, take a look at LiveReload. It'll watch files for you and auto-refresh your browser - great for instant feedback.
For browser compatibility, I would recommend you just get it to work on one first reasonably before worrying about the others. Check in from time to time to see if you find issues. See if jQuery can abstract some of that mess for you. Otherwise, take a look at Adobes BrowserLab.
i work at the digital department of a public broadcaster, together with two other frontend developers. We're currently looking into improving our Javascript workflow and build processes. Stuff like packaging, minifying, versioning, etcetera.
In an ideal scenario, we would have a global repository for all Javascript-related libraries (like jQuery) and stuff we build ourselves, that can be easily included in lots of projects and versioned.
All of our backend developers use Maven for this process with their Java code. I'm wondering if people have experience with Maven and Javascript, or maybe with other tools that might be good (or better) for the job. And in general if people have good resources about setting up workflow / build processes for frontend and javascript development.
We use Hudson (http://hudson-ci.org/) to continuously build/integrate our Python (Django via zc.buildout), R and several other types of projects. Whenever someone checks in code to the central VCS, a build is triggered and the test suite(s) will run. The build and test status is shown on a central screen in the office.
Hudson not only builds and tests, but also checks for coding style and syntax errors using pep8 and pyflakes, amongst others. Javascript is only checked with jslint at this point, but we may unit-test that in the future using something like xpcshell (more info).
** edit **
Go straight for Jawr, keeping rest in answer for alternatives
** edit **
First of all there's Ruby's rake which in theory can be used through jruby and in theory can be configured and run in the POM.
There's also Jake, but not sure if the latest Rhino supports CommonJS.
Whilst writing this awnser, I just came across Jawr which looks really interresting and there seems to be maven support/plugins.
The last option you already know about is dynamic loading using for example RequireJS or LABJS.