I'm relatively comfortable with laravel, but know very very little about javascript and npm in general... just to set some context.
I am building an app where I now require a "library of forms" to be filled out. So I'm thinking that I should leverage the expertise of others, and take advantage of what appears to be quite an impressive bit of work, in the form of SurveyJS. https://surveyjs.io/Documentation/Library
I'm probably making a total dog's breakfast of these different concepts, so bear with me please.
So whilst I've got the npm thing running smoothly, I'm not sure I understand the whole webpack compilation thing (yet).
Can you explain to me...
My plan is to have a number of "surveys" defined suitably for the surveyjs "engine". The logic I'm seeing is laravel app eventually pulls "a survey" and passes it to a view to be "executed".
The surveyJs librarys will use that model amd provide the results back to the laravel app - I'll pickup the results in a controller and deal with them.
If this is a suitable approach, then what are these choices about? https://github.com/surveyjs
If I take https://github.com/surveyjs/surveyjs-php (because it's the closest thing I can find to php/laravel then first step is to install docker. I'm a little confused about why I would be installing more "infrastructure" when I'm actually looking for the libraries necessary.
I don't understand why what I'm thinking as a very clever bit of javascript seems to want it's own "infrastructure" - docker / webpacks / etc. And then there's still the whole laravel mix thing.
Thanks in advance.
The main repo has dists for several different js frameworks, the editor repo is just that - only the core surveyjs lib - and the other repos are sample apps, a base project template and extras you may not need.
JavaScript has become a whole ecosystem in and of itself: building with rollup, webpack, parcel, brunch, gulp? For which framework, if any, Angular, react, vue, jquery, vanilla or a little bit of a and a little of b? What are you targeting, browsers, node, both, making an electron app? Using es6? Newer? Typescript?
Basically you're seeing surveyjs want infrastructure because they have answered the above questions. Welcome to javascript :)
Related
Is there a recommended way to create consistent project boilerplates when working with modern JavaScript tools?
Currently for my work, new projects will require some combination of:
Webpack
Babel (ES Next)
ESLint
Typescript
Vue/React (framework)
Framework Router + Redux/Vuex Framework
Testing framework
These have taken some effort to become familiar with the configurations and get them working together.
Now, I have a git repo for each configuration that can be cloned for a project, like webpack-babel-eslint, webpack-babel-eslint-typescript, webpack-babel-eslint-typescript-vue, etc.
This solves the problem of initializing projects quickly, but requires making an adjustment to the webpack configuration (for example) in each repos configuration when a change happens, instead of adjusting the base webpack configuration in one location and having it be shared.
I've seen tools like Yeomon, but I very much sympathize with the feeling of it being 'yet another tool' in an already intimidating landscape. I've also seen the monorepo structure of Lerna look like it could be used to keep all of these repos isolated, but this makes sense to me more for traditional packages and not for boilerplate assets.
Is there a way to maintain our projects configurations in a robust, editable way that allows for quick prototyping, like the Create React App or the Vue-Cli?
Is there a recommended way to create consistent project boilerplates when working with modern JavaScript tools?
Yes There is a consistent boilerplate builder, it's called Yeoman, usually people use it to make projects consistent in their organisation, or in projects that have quite a lot of scaffolding use cases into them.
The problem with this, and something you addressed in the last part of your question, is the "one of" scaffoldings. When used in an open source community, the Scaffoldings need to serve a purpose and have visibility otherwise, they won't be just anything else but a grain in the desert.
Things like create-react-app vue cli or the angular cli are there and exist because they serve a very good purpose and also, because they have the support of the community and the visibility
So, if the scaffolding is for your work, or set of tools for your projects with friends, go ahead and use Yeoman, but keep in mind that, unless you are making new projects every other day, this will be more work than benefits.
If you are just doing it "for the community" don't even bother, CreateReactApp, angular/cli, and vue/cli are more than enough, unless there is a git issue with 1000 upvotes, and you will solve the issue by adding this tool
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/
I currently have a large JavaScript application with a lot of code written in vanilla Javascript for a specific platform for where I work.
I need to transform this into a web application I can open in the browser. This should be able to be done relatively easy by swapping out the components from my current application to the components of another web technology.
However since Angular2 is written in TypeScript, if I was to choose it as the framework I use, should I really also be rewriting the rest of my non-component JavaScript to TypeScript to or will I not need to do this.
Would it be a bad idea to have an application which was half TypeScript and half JavaScript like this?
It's not a bad idea to mix TypeScript and JavaScript. I do it every day. But you have to now that it may be very painful in some cases. So I can only advice to enforce migration to TypeScript as fast as possible.
I would suggest you to read this introduction to migration from JavaScript to TypeScript: https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html
This might also be a valuable source: https://basarat.gitbooks.io/typescript/content/docs/types/migrating.html but I have the impression that the author has a very narrow opinion on how to work with typescript so just don't take everything there as it is, but just as a suggestion.
There are also a lot of other resources about migrating from JavaScript to TypeScript.
For the last month of migration to TypeScript I can say, that in many cases you can simply change your JavaScript to a TypeScript file and add exports. Than you need to add the needed imports in the other places and everything works just like before.
If you can make sure, that you only use old JavaScript in your TypeScript and not the other way round you can split your project into to packages. Load the JavaScript into global as done before and than create Typings for the parts of your JavaScript you use in TypeScript.
Wanted to know if there is a good IDE with full support for Ember.JS not just basic JS. Or is there are any command line tooling or code generating tools like Grunt for Backbone.JS?
I have nothing for IDE with intellisense for EmberJS, but Sublime is usually the go-to program of choice for development in Javascript. With a few packages and a jslinter you can get cracking straight away.
In the editor, there are things called 'snippets' that allow you to type a key combination, and a large portion of the code will be instantly filled out for you. For instance this repo has a set that you can add to your Sublime application to help you get going. Apart from that, there's nothing really that can help you code faster and easier as having an automatic Jslinter (or jshinter depending on how much you hate Crockford) and a nice set of snippets.
With ember-rails you can generate an Ember.js app structure as well as controllers, models, etc. Find the generators here.
There is also a ember.js package for Bower. Have a look at Yeoman, which uses Bower for package management.
Background:
I've been building web apps and web sites for many years, but each time I tend to start from scratch as each project has different requirements. However, this has me building my workflow from scratch as well. At this point, I'm about ready to settle on something a little more standard.
But what exactly is that standard? Being a JAVA developer by nature, I'm drawn to tools like Maven. And I've seen some work in the community for better Javascript support in Maven (javascript-maven-tools, javascript-maven-plugin, and others). But is this the best way to do it? I tried for a while to find a good WEB2.0 client/ajax-app maven-archetype to no avail.
I'm going to want to use tools in my workflow including JSLint [[http://www.jslint.com]], JSUnit [[http://jsunit.net/]] for testing, Documentation with things such as JSDoc Toolkit [[http://code.google.com/p/jsdoc-toolkit/]]. Compression and Framework inclusion would be nice too.
So, at this point, I'm even stumped at the the basic ways to start my app. What should a directory structure look like? For a pure client/frontend app (so no controllers, etc), do i just have a single webapp directory?
I guess I'm at that point where I'm questioning "my religion" with webapps. And after talking to everyone I know, I figured it was time for me to open it up to a hive-mind far smarter than my own.
Note. This is a question I also wrote
about in general on my site at
[[http://blog.jbjonesjr.com/?p=283]]
, but no one every cares about it
there.
Thanks for the help, I look forward to your thoughts.
I've started a couple of plugins (this and this) on Codehaus that facilitate the use of Maven for building JavaScript applications following Maven's goal oriented approach. I want to do more of this including the provision of a Surefire-compatible unit testing plugin and a minification plugin that leverages assembles. Take a look at what I've done so far and feel free to help out!
I'm also considering providing a JavaScript DSL for Maven using Polyglot Maven. A colleague kindly pointed out that JavaScript programmers will probably want to express their poms using JavaScript, not XML. In addition they probably won't want the learning curve of Maven. A JavaScript DSL could facilitate that.