|
|
|
|
|
Mark T Thomas wrote:Ahh styling. A much contested topic in the React world right now. Basically the divide comes down to "use JS for styling" or "just use CSS". I think there are some incredibly cool things happening in this space, but don't feel like I need to take a side here. I guess in some ideal sense the CSS APIs and model etc. is so good it all happens there, but then you have the issue of encapsulation (making styling only apply to a given component). When CSS alone can do that in a super powerful way, a la, dare I say, web components, I think I'd be more comfortable saying "just use CSS". But there are super cool things that are happening w/ the "css in js" space. Check out https://emotion.sh/ especially!
Junilu Lacar wrote:Ideally, refactoring should be done often and in small increments and you should try to do it as soon as a failing test has been made to pass. The main motivation for refactoring is to eliminate duplication and to clarify intent. Simplification is also a good goal.
Of course, getting into the habit of refactoring is kind of like flossing your teeth: you know you should do it often but many people only do it once in a while or not at all.
The way you asked the question makes me think that you're not doing refactoring very often and when you do, they tend to be large efforts with a lot of code being affected. This almost makes me think that you're not actually refactoring your code but rather you're reworking it.
Runar Bjarnason wrote:Yes, I think you are wrong about that. Scala is a general-purpose programming language. And if you stick with FP, then building a "huge" system is exactly the same as building a small system. The approach scales very well.
Runar Bjarnason wrote:It's my experience that FP actually reduces the "complexity curve". The space of potential solutions to a given problem is enormous, and FP really puts constraints on the solutions that are allowed. This simplifies your search through the solution space.
I also find that when developing functionally you do not need huge teams. A small team of programmers well versed in FP can be extraordinarily productive. You will do more with less code. That code is harder to write, to be sure, but it is easier to maintain, extend, and test.
Runar Bjarnason wrote:Phelipe Maia:
In the book we try to give concrete examples of the benefits of functional programming. In short, those benefits are modularity and compositionality.
Modularity is the extent to which the parts of your programs can be separated and recombined in new ways. One practical benefit of this is code reuse. If it's easy to separate a part of your program out and reuse it in a different context, that enhances your productivity. Paul likes to say that "if you just eliminate all the duplicate code in your programs, you end up with functional programming". Another benefit of this is parallelization. If parts of your program can be cleanly separated, then those separate parts can be safely run in parallel. Testability is another. Again if you can isolate parts of your program, then they can be individually tested, which gives you confidence in the quality of your overall program.
Compositionality is the extent to which your program is composed of parts, each individually understandable, with clear rules of combining them. A compositional program can be understood just by looking at its parts and the rules of combination. Pure functions have this property because they are black boxes, and you can build larger black boxes just by plugging the output of one function into the input of another. The practical benefit here is that large systems can be assembled out of simple components.
A third and often overlooked benefit of FP is that it promotes programmer happiness. It is too easy to "create monsters", like you say, with other methodologies. Code that is hard to maintain makes your life as a programmer miserable. The accumulating technical debt creates friction, and makes it feel like you are trudging through a swamp whenever you need to change anything in the code. FP counteracts this. Code that is modular and compositional feels clean and is pleasant to work with, because it promotes clear separation of concerns (modularity), and safe recombination (compositionality). I have been programming for 28 years now, and I know how easy it is to create an unmaintainable mess with methodologies like OO. I think that if I hadn't come across FP, I would have stopped programming 10 years ago.
Damon Oehlman wrote:Hey Phelipe,
Thanks for the question. I think it is probably one of the best questions that anyone can ask before buying either this book, or any book on cross-platform (or device) mobile development.
It really comes down to the 80/20 rule (as so many things do). Essentially, 80% (and sometimes more, depending on what you are doing) of the code you write will work on any mobile device that comes with a WebKit browser, but the device OSes do require slightly different treatment for programming for the mobile web. Additionally, one of the things that I like to keep as an option is packaging an application for native distribution, which technologies like PhoneGap make possible.
I think that for now, an Android Web Apps book makes sense, but less so in a few years time when mobile web app programming has matured and starts to become the preferred approach - well, that's my prediction anyway.
The good news is that the majority of the books content is applicable to programming for other mobile device platforms that ship with WebKit browsers (iOS, WebOS, Blackberry Torch, some Nokia), but this still leaves a lot of devices that code samples in the book just won't work on. For example, Windows Phone7 as it ships with a browser roughly equivalent to IE7 (so no HTML5 or CSS3 support). As I said, this will almost certainly change in time, and when it does, then having a book titled "Pro Mobile Web Apps" (or similar) makes sense and will be able to provide content that someone buying the book would probably expect.
I hope this answers your question, but if not, I'll definitely try and provide more info.
Cheers,
Damon.
Perry Hoekstra wrote:Define other devices? Android-based devices is a yes. iPhone, Windows Mobile, or Blackberry is a no.
What is the difference between a development of android web app and other devices web app? For example: If I develop a web app for android I can access from other devices, can't I? So, Why a book specifically for android?
Gregg Bolinger wrote:
Phelipe Maia wrote:I was thinking that in the case of native app I could build a local cache to work offline some basics operations. Is it possible?
Use the OS's built in SqlLite database. It's perfect for this scenario.