Feed powered byStream Blue Logo Copy 5
Webpack

Webpack

DevOps / Build, Test, Deploy / JS Build Tools / JS Task Runners

Decision about HTML5, Ruby, Babel, Webpack, Visual Studio Code, GraphQL, Graphcool Framework, Figma, TypeScript, JavaScript, Framework7, Css

Avatar of jdspugh
Software Engineer / Project Manager / Technical Architect
HTML5HTML5
RubyRuby
BabelBabel
WebpackWebpack
Visual Studio CodeVisual Studio Code
GraphQLGraphQL
Graphcool FrameworkGraphcool Framework
FigmaFigma
TypeScriptTypeScript
JavaScriptJavaScript
Framework7Framework7
#Css

I needed to choose a full stack of tools for cross platform mobile application design & development. After much research, trying different tools, and 18 years of mobile design & development, these are what I came up with that work for me today:

For the client coding I chose Framework7 because of its performance, easy learning curve and very well designed, beautiful UI widgets. I think it's perfect for solo development or small teams. I didn't like React Native. It felt heavy to me and rigid. Framework7 allows the use of #CSS, which I think is the best technology to come out of the #WWW movement. No other tech has been able to allow designers and developers to develop such flexible, high performance, customisable user interface elements that are highly responsive and hardware accelerated before. React Native contains a very limited interpretation of #CSS which I found very frustrating after using #CSS for some years already and knowing its powerful features. The other very nice feature of Framework7 is that you can even build for the browser if you want your app to be available for desktop web browsers. This is not possible with React Native yet.

JavaScript is very far from an ideal language, to say the least. To make life bearable I managed to configure TypeScript to work with the latest version of Framework7. This makes me feel like I'm back in the good old Java days. I consider TypeScript to be one of the rare best creations to come out of Microsoft in some time. They must have an amazing team working on it. It's very powerful and flexible.

For the user interface design and prototyping I use Figma. Figma has an almost identical user interface to Sketch but has the added advantage of being cross platform (MacOS and Windows). Its real-time collaboration features are outstanding and I use them a often as I work mostly on remote projects. Clients can collaborate in real-time and see changes I make as I make them. The clickable prototyping features in Figma are also very well designed and mean I can send clickable prototypes to clients to try user interface updates as they are made and get immediate feedback.

For the UI icons I use Font Awesome Pro. They have the largest selection and best looking icons you can find on the internet.

For the backend I chose Graphcool Framework. It has great customer support and a very accessible free startup plan for working on new projects. I was never a fan of relational databases so I'm very pleased to see NoSQL / GraphQL databases coming to the fore and I'm happy to use them. No more server side API development required! NoSQL databases are so much more flexible and the way I think databases were meant to be from the start.

For the IDE I use Visual Studio Code which is blazingly fast and silky smooth for editing code with the ultimate TypeScript checking (since both products are written by Microsoft).

I use Webpack and Babel to compile the JavaScript. TypeScript can compile to JavaScript directly but Babel offers a few more options and polyfills so you can use the latest JavaScript features today and compile to be backwards compatible with virtually any browser.

I use some Ruby scripts to process images with ImageMagick and pngquant to optimise for size and even auto insert responsive image code into the HTML5. Ruby is the ultimate cross platform scripting language. Even as your scripts become large, Ruby allows you to refactor your code easily and make it Object Oriented if necessary. I find it the quickest and easiest way to maintain certain aspects of my build process.

What tools do you use? Have you tried these ones?

14 upvotes7 comments13.5K views

Decision at StackShare about Redis, CircleCI, Webpack, Amazon CloudFront, Amazon S3, GitHub, Heroku, Rails, Node.js, Apollo, Glamorous, React, FrontEndRepoSplit, Microservices, SSR, StackDecisionsLaunch

Avatar of ruswerner
Lead Engineer at StackShare
RedisRedis
CircleCICircleCI
WebpackWebpack
Amazon CloudFrontAmazon CloudFront
Amazon S3Amazon S3
GitHubGitHub
HerokuHeroku
RailsRails
Node.jsNode.js
ApolloApollo
GlamorousGlamorous
ReactReact
#FrontEndRepoSplit
#Microservices
#SSR
#StackDecisionsLaunch

StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

8 upvotes14.9K views

Decision at Uploadcare about Webpack, React, React Storybook, Frontend

Avatar of Zmoki
Frontend Team Lead at Uploadcare
WebpackWebpack
ReactReact
React StorybookReact Storybook
#Frontend

React Storybook is one of the most favorite tools in our #Frontend team. When we start a new frontend part, we install storybook at first and create visual React components based on our design with usage stories in Storybook. So, we get a live version of design quickly and can sync with designers before developing of whole app and configure Webpack.

8 upvotes2.6K views

Decision about nginx, Webpack, Vue.js, Framework7, npm, MySQL, Ubuntu, Node.js, Plaid, Framework7, HapiJS, Lenovo

Avatar of mbplautz
nginxnginx
WebpackWebpack
Vue.jsVue.js
Framework7Framework7
npmnpm
MySQLMySQL
UbuntuUbuntu
Node.jsNode.js
#Plaid
#Framework7
#HapiJS
#Lenovo

I just designed, developed, and deployed my own budgeting app, dailybudget.cc, which allows me to automate my budgeting the way I have always done it, in a way that I could never fully capture with other budgeting apps, such as Mint, EveryDollar, or YNAB. I spent 4 years from the time I first had the idea to the time I actually sat down to design it and start development. During this time I evaluated many other budgeting app solutions, and had even architected a prototype that I never ended up using. But boy, have technologies come much further in 4 years.

Though my first prototype used Java and Tomcat, I completely abandoned those 4 years later in favor of Node.js technologies, which I have found are equally as stable, more flexible (for better or for worse), and capable of significantly more rapid development. Since what I have deployed now is in beta and is primarily for limited user use, I favored rapid development over slower development where I would write more automated unit tests. I chose to build the app as a HTML5 web application (rather than native iOS or Android, for now), and I used a separated API backend/Web frontend model. My target platform for use with the app is mobile handheld touch devices, though it can work on any laptop or desktop with a touchscreen. Given these design targets, many of the technologies I chose were because of familiarity with them as well as a strong online community, and some technologies I chose that I had to learn anew, because they appeared to fit my needs.

My entire app runs on a #lenovo IdeaCentre desktop on my home network, on which I have installed Ubuntu 18.04. Ubuntu is something I have switched to after a long time of use and familiarity with RedHat Enterprise Linux and CentOS, because the online support for Ubuntu is now tremendous, and there is so much documentation and examples online of how to configure and use Ubuntu; not to mention I have not been thrilled with the direction new releases of CentOS. Ubuntu is also a good environment for development - it is so easy to follow the many online examples. Lastly, I may migrate my app and configuration to Amazon AWS, which also uses Ubuntu for its EC2 Linux VMs, so having Ubuntu now is helpful for that prospect.

The API backend uses Node.js, with #HapiJS as the API server framework and MySQL as my persistence database. HapiJS is something I have had familiarity with and is just a phenomenal framework to plug into and configure, especially if you use it for a route-based API. #Mysql has a great online community. I could've used PostgreSQL too, but I am more familiar with MySQL. Also, if I migrate to Amazon AWS, Amazon's RDS uses MySQL. I use npm as a one-stop-shop package manager and environment manager.

The Web frontend uses a combination of Framework7 and Vue.js. I cannot evangelize Framework7 enough! It is a fantasic tool by @nolimits4web (GitHub) that is really easy to use, really well thought out, and really performant. Framework7 simulates the native iOS or Android (Google Material) experiences, all using HTML5 constructs (HTML+CSS+JS). Vue.js is another very fantastic binding and frontend framework which has a good online community and is well documented and easy to use. I had to choose between VueJS and ReactJS, and ultimately chose VueJS over ReactJS because it seemed to favor more rapid development with less ramp-up time, whereas I understood ReactJS to be more of an enterprise level framework (though still good for smaller projects like mine). When using Framework7 with VueJS, NodeJS is used along with Webpack to transpile my code into browser-friendly JavaScript, HTML, etc. Webpack was nice to use because it has a hot-deploy development mode to enable rapid development without me having stop, recompile, and start my server (this was one of several reasons against using Java with Tomcat). I had no familiarity with Framework7, VueJS, or Webpack prior to this project.

I use nginx as my web server and have the API running behind a reverse proxy, and all of the web frontent content hosted as static content.

I use the plaid API to sync my bank transactions to my database. This is another fantastic framework (though not free beyond development use) that it turns out is extremely easy to use for the complex job that it solves.

5 upvotes5.9K views

Decision at ReactQL about Koa, React Router, Foundation, Semantic UI, Bootstrap, PostCSS, Less, Sass, styled-components, React Helmet, Webpack, TypeScript, JavaScript, Apollo, GraphQL, React, JSX, React., Css, StyledComponents., Async, HTML, GraphQL, Apollo

Avatar of leebenson
KoaKoa
React RouterReact Router
FoundationFoundation
Semantic UISemantic UI
BootstrapBootstrap
PostCSSPostCSS
LessLess
SassSass
styled-componentsstyled-components
React HelmetReact Helmet
WebpackWebpack
TypeScriptTypeScript
JavaScriptJavaScript
ApolloApollo
GraphQLGraphQL
ReactReact
#JSX
#React.
#Css
#StyledComponents.
#Async
#HTML
#GraphQL
#Apollo

ReactQL is a React + GraphQL front-end starter kit. #JSX is a natural way to think about building UI, and it renders to pure #HTML in the browser and on the server, making it trivial to build server-rendered Single Page Apps. GraphQL via Apollo was chosen for the data layer; #GraphQL makes it simple to request just the data your app needs, and #Apollo takes care of communicating with your API (written in any language; doesn't have to be JavaScript!), caching, and rendering to #React.

ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.

React Helmet was chosen to handle <head> content, because it works universally, making it easy to throw back the correct <title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.

styled-components, Sass, Less and PostCSS were added to give developers a choice of whether to build styles purely in React / JavaScript, or whether to defer to a #css #preprocessor. This is especially useful for interop with UI frameworks like Bootstrap, Semantic UI, Foundation, etc - ReactQL lets you mix and match #css and renders to both a static .css file during bundling as well as generates per-page <style> tags when using #StyledComponents.

React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.

Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.

4 upvotes9.9K views

Decision about Babel, Webpack, Ember.js, Create React App, Next.js, JS

Avatar of gwintrob
Newfront Insurance
BabelBabel
WebpackWebpack
Ember.jsEmber.js
Create React AppCreate React App
Next.jsNext.js
#JS

We needed a frontend framework for to make it easier to work with JavaScript. We chose Next.js since it maintains the flexibility of something like Create React App but gives some structure on how to organize the app similar to Ember.js.

Webpack and Babel are configured out of the box for #ServerSideRendering, #TreeShaking, and other nice #JS features.

3 upvotes3K views

Decision at Inato about Webpack, Yarn, React

Avatar of bastoche
VP Engineering at Inato
WebpackWebpack
YarnYarn
ReactReact

At Inato, we wanted to separate our React components from our application code in order to standardize them and facilitate re-use. But we also wanted to be able to edit them and immediatly see the results in the application. We managed to make hot-reload work using Yarn workspaces and Webpack

2 upvotes548 views