Caddy is an HTTP/2 webserver written in Go that integrates with ACME and serves websites of TLS by default. It powers https://paragonie.com and manages our HTTPS certificates automatically.
A lot of the "PHP sucks" arguments focus on things that haven't been true about the language since 5.4 (or earlier), but one thing that truly did suck was dependency management (before composer came around).
Dependency management also sucks in other languages (and still sucks in those). I suspect that's why few used that as a criticism of PHP.
I've been using PHP for most of my life, and used various template engine and it always end up with one question : what is the real purpose of a template engine in PHP instead of just using PHP ? When I see the examples in twig homepage it just looks like they tried to make PHP examples verbose for the sake of it.
I don't really mind them, but I find it extremely boring to have to register in the template engine every function that you will end up using somewhere else in your code and eventually have a language with less feature than plain old PHP and an other layer of cache.
So which use cases make you need Twig, for instance ?
Okay, I've never worked with a designer that would touch code, so there is that. Macros seem a bit redundant with partial views in my opinion, except they take fixed parameters, but this is a interesting concept.
+1 for twig when using PHP. Also, if working in Wordpress, the combination of ACF and Timber (twig for Wordpress) will get rid of a lot of frustrations.
I have way too many to list, so I figure that I'll list one old school one that I have been using for years and one that I only started using in 2016.
This year, I made my first foray into building non-trivial web applications with Angular. Despite (or perhaps because of) that, I was quickly filled with a brand new respect for good old jQuery. I have yet to find such a simple, maintainable, readable way to parse complicated DOMs.
I can't believe I excluded VS Code from my list--and I wrote the article yesterday. It really shows how much we take for granted when it comes to open source.
VS Code became my primary code/Markdown editor in 2016. It improves steadily each month [1] and already has a great extension ecosystem and community. It also spurred my switch to Markdown for all note-taking due to its powerful integrated Markdown features.
Thank you to the VS Code team and Microsoft for sponsoring the project.
If you are grateful for some open source projects you should try to contribute to them next year as a new years resolution either by donating your time or money to them.
I completely agree. I try to support the open source projects I depend on via financial contributions (purchasing books/training/services offered by the organizations or Patreon). I also submit pull requests for documentation updates and answer questions in forums. One of my goals for 2017 is to contribute some source code pull requests.
I'm going to go with Preact [1]. I'm a 'full-stack' developer (primarily backend) who recently took my first frontend gig and my first real foray into this world has been with Preact and I really enjoy it. I don't feel as if I'm 'losing out' by not using React, since it has the same API, and have really come to believe in it's ethos as a project to keep the library size, and therefore the download + parse time, incredibly small but also providing performant functionality. The author is a great guy who's really responsive as well.
I do all my group collaboration with it, and am no longer subject to Google's whims about my data. Sandstorm predates 2016, but has really accomplished a lot in 2016.
I love it. To the point that I think it's application architecture to rule all architectures. I dream of a brand new Unix based OS that adopts this architecture as it's standard over MVC.
I'm increasingly convinced that redux is the wrong way to manage most state. I see the pattern get abused greatly for state that should be more localized.
I understand the feeling that it seems strange to manage all state, no matter how small, in a large global state. However, every now and then I'll work with a designer or UX person who will connect seemingly unrelated elements in a powerful way, and I'll realize how freeing the global state becomes. The potential to easily explore new relationships between UI elements is wonderful.
Edit: Also, I should mention that taking advantage of the great middleware options for isolating side effects makes redux a treat to work with. I am using redux-observables, but I have heard great things about redux-sagas as well.
I've definitely felt that when using Redux even in some very simple projects. Just last night, for instance, I felt like I was doing acrobatics just to make a simple state update because a particular branch of the state required knowledge of state that was handled by a different reducer in order to do the update. However, as I struggled with navigating that issue, it slowly became really clear to me that the patterns Redux was enforcing (and which I was trying aggressively to circumvent) were actually to my benefit, and instead of circumventing it I just thought a bit harder about how my architecture and how to properly achieve what I wanted within the Redux paradigm. There will always be cases where libraries like Redux break down and you will feel like you are trying to fit a round peg in a square hole. But, at the end of the day, it's all just functions and objects being passed around and you have to judge the value in the library in the kinds of conventions and patterns it encourages and discourages. For me -- especially since I am admittedly a mediocre programmer at best -- the structure it enforced on my code organization and logic has been a blessing.
Im not sure I agree (or maybe I dont understand what you're saying). For me, all state, no matter how trivial, should be on the store. For UI state that can seem excessive, but its possible to use middleware and decorators to simplify that. Local state in my experience means bugs.
The problem is when different views require the same concept of some state but they don't really want it global to the application to bleed into other views. A redux-like pattern makes it very simple to put that state into a store, but then you're stuck reseting it every time you switch views, which can make it very easy to introduce timing bugs and just increases the surface area where bugs can introduce since more code gets written for logic that ultimately is the wrong abstraction for these situations.
I suspected this would be the case when first reading about redux, and dealing with it at practice in work, the consequences can be quite bad.
Not to say that some concept of global application state is bad - one always has it. It is incorrectly making it global when you really want an instance of it for a particular view. Redux itself isn't bad as it helps manage an important situation, but it is too much of a facilitator of this antipattern when it comes to state that absolutely should not bleed across views.
I still dont think I grasp what your describing. The store isnt global. And you usually have domains on the store to namespace particular bits of state. But if need be, any part of your app can access that state if it needs to without having to dig down into your UI hierarchy which will likely change over time.
without wanting to sound patronising, but I wonder wether you're structuring things incorrectly.
If I'm picking just one it would be webpack. It might not be sexy but it wrangles so much complexity out of my projects - files for disparate technologies (JS, CSS, Vue.js templates, CSV, whatever) can all declare dependencies against one another, and somehow each one gets parsed and bundled and minimized the way it needs to be. It's pretty glorious.
It would be Yehuda Katz for participating in TC39 to improve javascript while also running a company (Skylight) and making a completely open source framework (Ember) and helping with two package managers (Cargo and Yarn). It is hard to believe it is a single person.
My vote goes to Michel Weststrate for his amazing work with MobX [1]. I was really unhappy with all of the client-side data management options (Flux, redux, et al) until this came along. Many thanks Michel for making my day to day frontend life much more enjoyable!
It's a remote backup tool that solved all the problems. It's basically duplicity[2] but without the unfortunate design fault of having to re-upload all your data every few months.
Our[3] customers love it and we see new deployments of it (even among existing customers) every single day.
The list is massive. But the short list is Ruby and the entire Ruby on Rails ecosystem, PostgreSQL, Linux, and bash. Upon these rocks I earn most of my living. And none of this would be possible without the GNU Compiler Collection.
Definitely Matteo Centenaro[0] and Andrea Dal Ponte[1] for their incredible contributions to Tomatoes[2], and our supporters[3] who boosted our morale and made the project sustainable.
This year I decided to hunker down and use vim (specifically, neovim). It has been the best decision I have made.
Using vim and thinking of the satellite of tools in my terminal as my IDE has made me a better programmer and I have a better appreciation for building on the foundation of other developers work (huge reduction in desire to invent everything myself).
So I want to thank all of you who write articles, share tips and tricks about using vim and utility programs, and especially those of you who contribute to open source software. I've learned a great deal from you all.
Do you have a strong preference? I've been using CSS Modules but I'm constantly wondering if Styled Components is better -- it seems like less work to add styles, at least.
No strong preference, I like both. But styled-components beed to ve road tested in a large project before we can appraise wether they're ready for a production ready boilerplate.
The jump from 4.5.x to 4.6.x included a huge number of commits from a small core of people, and the future looks bright. My 'thank you' is in the form of written thanks to the development team and contributors, and I'm aiming to increase my regular commitments to helping with docs and other non-dev tasks to half a day per week in 2017.
The developer of Vue.js even though I haven't finished by project just yet thanking him ahead of time for giving me an alternative to working with big company projects. Also the teams behind node and express.the team behind Mariadb for giving me an alternative to oracles MySQL. The Apache Prediction team as well so I can use machine learning without having to write everything from scratch with tensor flow.
Indeed, it doesn't. But I think it's not the tools, it's the businesses who do not understand tech, and the engineers, who are not strong enough to say no to random, tight deadlines, accepting worse quality for the sake of shipping.
It's curious to me how unpopular this sentiment is here. Are there actually people who think the Web provides a better user experience in 2016 than it did in 2006? I'm frankly baffled at that and would love to hear from somebody who feels that way.
People have always made bad, unusable websites. If we wanted to prevent them from doing that we should have never moved away from Gopher.
I write SPAs for a living and a lot of the technologies mentioned in this thread are a godsend. Whenever somebody expresses the above sentiment I feel it's only because they never had to maintain a complicated web app.
Correct: we used to write websites that were as simple as it was feasible for them to be, with as few client-side requirements as possible. It's the whole idea that "complicated web apps" are good things that I dislike.
Do you think Facebook could exist if we eschewed building complicated things on the web? The alternative is not building a simpler website, it's building desktop applications. Just because some developers choose the wrong tools for the job doesn't mean the tools aren't necessary.
- https://github.com/mholt/caddy
Caddy is an HTTP/2 webserver written in Go that integrates with ACME and serves websites of TLS by default. It powers https://paragonie.com and manages our HTTPS certificates automatically.
- https://github.com/twigphp/Twig
Twig is one of the sane templating languages for PHP projects that I use extensively.
- https://github.com/composer/composer
Composer revolutionized PHP development.
A lot of the "PHP sucks" arguments focus on things that haven't been true about the language since 5.4 (or earlier), but one thing that truly did suck was dependency management (before composer came around).
Dependency management also sucks in other languages (and still sucks in those). I suspect that's why few used that as a criticism of PHP.
- https://github.com/jedisct1/libsodium
Libsodium: modern cryptography that you can likely find bindings for in your favorite programming language.