This is great. I definitely feel like the front-end could use a more ORM-like, feature rich data layer. I generally use an ORM on the backend. When I get the data to the front-end, it's still relational in nature, and I still want similar tools for working with it (e.g. schema definition, validations, and an api that lets me query and manipulate related data). It seems like Ember Data is closest thing. I wish it could more easily be used outside of the context of Ember.
But then you have to host it and maintain it. It's a slippery slope. How many 3rd party services do you in-house with hosted OS software. Pretty soon you're spending a huge chunk of your time doing ops work. And, where do you host it? On AWS, which can also go down, or on hardware hosted at your office. With on premise hosting, now you're in the hardware game too.
I think you're throwing the baby out with the bathwater here. GitHub has an enormous codebase where they've done a lot of work digging around in and modifying Rails under the hood. I think their situation calls for it and they have the internal talent to successfully "go off the rails" a bit. But it makes the upgrade path difficult. This is par for the course. Can you think of a technology/framework that would fare better than Rails in this case? I mean, you'd be in the same boat with Django, Spring, [your framework of choice], right?
I totally agree. One of the things that keeps me in Ruby land is the absolutely phenomenal debugging/repl environment provided by Pry and related gems. When I want to understand how something works, I drop a binding.pry, run the code and start digging through the stack with the Pry toolchain. I feel like this process is so important and it's the first thing I find myself missing when I work with other languages. (I suspect you can get similar debugger/repl functionality with Python's iPython, but I don't have a lot of experience with it.)
Yeah, I was confused about that as well. I came to the comments hoping to find good suggestions for doing market research. Most of the comments (at least at this point) seem to be geared towards trading.
Wait. You've made a choice to engage in unhealthy work habits. It may not seem like it, but this _is_ your choice. I've been working as a remote contractor for almost 20 years. If you want to remain sane and happy, you need to set boundaries, both with clients and yourself.
Yeah, I totally agree. I use VSCode and I'm happy with it. Electron apps are slower, but not to the extent that I won't use Electron based apps. Personally, I'm excited to try out Oni.
Maybe I'm missing it, but I'm not seeing what the cost is for higher resolution maps. As I understand it, in addition to usage beyond what the free account allowed, a paid account used to also give you access to higher resolution map tiles and a higher zoom level via their API.
Thanks for the reply. MobX does look interesting. I recently watched Preethi Kasireddy's presentation comparing MobX and Redux (https://www.youtube.com/watch?v=76FRrbY18Bs), which I'd recommend watching to anyone in my shoes. A couple of things give me pause about MobX. One, it doesn't quite have the inertia or industry buy-in that Redux has. It's popular, but in terms of GitHub stars, it's less than half as popular as Redux. Alone this isn't super meaningful, but if you look at the contributors page for MobX, it seems like it's predominantly the work of one person. Again, not super meaningful on it's own, but Redux seems to have the benefit of a larger group of core contributors working on it and larger community support. Just circumstantial evidence, but I feel like it's a safer bet for client work on this front. There's value in following the well worn path. The other thing that gives me pause about MobX is this opinion I've heard a few times and you've just re-iterated, which is that MobX is easier to work with and possibly better for smaller projects, but Redux scales better. I'll concede, it's possible I need to quit whining about the funkiness of Redux and live with it for awhile. It might grow on me. :)
My main smart component is several hundred lines long at this point. The methods in the component are largely event handlers used to manipulate the component's state object. The methods are passed down into the hierarchy of "dumb" components via props, and are called when actions occur in those components (e.g. onClick some element). The methods are conceptually group-able into 4 distinct areas of data manipulation. However, the catch is that many of the event handler methods need to modify other pieces of the state object too. So, for example, I have a number of methods related to polygon state management. I'd like to move these into a <Polygons /> smart component, but when updating a polygon, I also, in some cases, need to update data for another potentially extractable smart component <Toolbar />. A state management library would allow me to move/group data management logic into smart components that would also still have access to other parts of the state tree.
I've built a couple of applications with React. I've spent the last 6 weeks on a contract where I'm building a React based Google maps widget. I'm getting to the point where I'd like to break up a large "smart" component into smaller, more maintainable smart components. So, I'm looking for a state management library to help. I've walked through some training courses at Udemy on Redux and I've built a small personal project with it. I don't want to beat a dead horse, but the boilerplate is really off putting. I feel like I'm being exposed to the internals of a framework that's missing some higher level API abstraction that makes state management less onerous. I think the Rematch library presents a nicer surface API: https://github.com/rematch/rematch. But, I'm hesitant to use it over Redux for client work because I want to make sure I develop something that's easy to hand off, and Redux is sort of king right now. I just spent some time with the apollo-link-state docs. I know it's young, but this does not look like an improvement over the Redux state management API. Hopefully if this is to be the Redux successor, the API will improve with maturity. I kind of wish Ember Data was usable as a standalone library. It looks like such a nice, easy to use wrapper around state and data management.
I mean, Facebook is losing money right now, but I don't think they're going anywhere.
But, for the sake of argument, let's say everyone deletes their account and Facebook goes away. React is open source. The people from Facebook working on React would probably just get jobs with some other company that relies on React and continue working on React.
No kidding. I'm so impressed with most of Go, but this is just silly. I feel like Rust started out with solid dependency management in place, at least it's been there from the early days. I work a bit with Node and Ruby too. Both have solid dependency management in place. I mean there are warts, but generally the problem is solved. Actually, now that I think about it, Yahuda Katz has had a hand in working out dependency management for all of those technologies, Rust, Ruby and Node. Maybe the Go guys should bring in Yahuda to help out. If nothing else, he could probably help them get out of the paralysis of analysis loop they seem to be in here.
I live in San Francisco. I don't take public transit regularly but I've lived in this area for 17 years and have personally witnessed several incidents on BART, Caltrain, and Muni. I also lived near Koln Germany for four years where I took public transit hundreds of times without issue. I think it's fair to say that some places have public transit that is just safer than others.
Oh, it looks like Bundler didn't make it into the standard library for the 2.5 release. The commit to bring it in was reverted just before the release, with very little explanation. I mean, it's not like `gem install bundler` is that hard to do, but I'd be curious to hear why.
I literally thought, "This has to be a poorly executed April Fool's joke... but, no, Adobe wouldn't attempt an April Fools joke". So, I read the comments here to see what other people are thinking. I guess I'm not alone. The video is hilariously vague. It's like some Nucleus marketing blurb where Hooli execs decided they shouldn't mention that the product does compression.
I agree with this. If you're augmenting a traditional request/html-response web app with some JavaScript functionality, a lighter weight view library fits the bill nicely. But, if you're developing a SPA that consumes an API, you might really enjoy what a more holistic framework provides in terms of code structure, front-end data management, and just general guidance on how to do certain standard things, like basic CRUD.
So, I'm still a noob with this stuff, but it's my take that Elm is both a language and a front-end framework. It's a language that compiles down to JavaScript that also gives you a React-like toolset to develop front-end code with.
I was really excited about Elm after listening to The Changelog episode #218 (https://changelog.com/podcast/218). Elm is in the style of React, but the flavor of Haskell. For my part, I had a hard time with the syntax and functional approach of it from the get-go. It was very new and awkward to me, which was a speed bump to my adoption. However, I felt like it held the promise of allowing potentially better/ more maintainable code. Evan Czaplicki (the creator) and Richard Feldman (a prominent evangelist) both talk about how the Elm language and style led to more effortless refactorings in larger front-end codebases they were working on. Sounded really good to me! But, I eventually ended up leaving my Elm journey and starting my Vue journey because the Vue documentation was so good (comparatively) and the style of Vue felt more natural to me. It kind of came down to the question "how do I do CRUD with this?". For me, the story was easier and more fleshed out with Vue. Currently, I'm working with Angular 2 mostly because it had a more definite answer to this question than Vue. And, the testing situation seemed way more fleshed out than Vue's (at least at this point). But, I plan to check back in on both Vue and Elm in the next year or so to see where they've landed. I understand what people are saying about JavaScript fatigue, but there's also so much exciting and cool stuff happening in this space right now. It's hard not to love all this innovation.
I'm mostly a backend Rails developer, but I've spent the last 3 months developing stuff with Vue, Elm, React, and Angular 2 in an effort to see which of the front-end frameworks I would like best (I messed with Ember a year ago but haven't had a chance to revisit since). To me it seems like React is about putting logic in code instead of templates/markup. Vue is more in the vein of Angular, where you have logic in your templates/markup. So it's sort of a question of what you feel more comfortable with, the style of Vue or the style of React.
Instead of Vue or React, you might choose Angular 2. Vue is sort of touted as "Angular done right". I did enjoy working with Vue (I actually enjoyed working with all of them), but I think Angular 2 may be "Angular done right". However, Vue seems to try to be more lightweight and less of a framework than Angular (1 or 2). It has this in common with React. I think both Vue and React would be easier to start introducing into an existing app incrementally. Angular 2 seems like it's more of a framework/holistic choice. It has this in common with Ember, although this is true of Ember to an even larger degree.
I like how, in their README on GitHub, they mention that they're not interested in playing the benchmark game. That's great. For the most part, I don't care about benchmarks. I mostly just care about tooling that helps me to be more productive.
I'm really excited about the web version of this. I think Google is doing fantastic work, making material design available to and usable by the community. I'm sure their motives aren't entirely altruistic, but I appreciate them nonetheless.
As a nit, I'm not very fond of their CSS naming conventions, using a lot of double underscores and double dashes. For example:
Yeah, right?! I had the exact same thought when I saw this. Okay, video... that's cool. But, we've been waiting for the ScreenHero purchase to turn into Slack screen sharing for ages.
I've been developing apps with Rails since it was announced. It's been an amazing tool/toolchain, providing a very useful level of abstraction that allows rapid development.
Recently, I've been doing a lot of Go (Golang) development. For me, it's sort of the anti-Ruby-Rails. I really like the fact that it requires me to "roll my own" in so many situations. I need to understand what's happening under the hood to make things work.
But, the abstraction/magic of Rails is useful. Speed to market with trustable, battle tested magic is a profitable proposition.
I want to introduce Golang into my current project, but I haven't quite found the right place for it yet. Rails makes it so much easier and faster to add functionality at our scale.
I like the idea of SOA. The separation of concerns feels right to me on some level. But, every time I look at it being applied, it's clear to me how much more money and time is being spent implementing it. With SOA you incur the additional cost and headache of orchestration into your system. If you're big enough or complex enough, this may make sense. But, I feel like a lot of dev teams applying this approach don't have the specific problems of scale that SOA solves.
Yeah, I agree with this. I can buy an external monitor, mouse and keyboard for something in the ballpark of a $120. This is much nicer. It's more compact and portable. But, close to $300 seems a bit extreme.