Reducing complexity in general, especially for new and small projects, is very good advice.
For the past several years I've started new personal projects with PostgreSQL+Python+[Flask|Django] on the backend and Bootstrap+Knockout on the frontend. I recently tried to start a new project with React instead, and while the actual act of development on a working React-based codebase is fairly nice, getting it to that state apparently requires a load of dependencies that I simply wasn't prepared for.
I retreated back to using Bootstrap alone for the prototype and found it much easier to work with than I remember. I'm sure part of that is that I've gained a ton of experience since I last used jQuery without a UX framework like Knockout, Ember, or React - but part of it also seems to be that browsers have come a long way since then.
In fact, I'm considering eschewing all front-end dependencies for my next prototype - ES6 has far better support in modern browsers than I recall, as do the more recent CSS capabilities like flexbox.
I figure that at best I'll have a lightweight, clean project that works well enough for a prototype; at worst I'll learn a lot about where modern web standards are.
>In fact, I'm considering eschewing all front-end dependencies for my next prototype - ES6 has far better support in modern browsers than I recall, as do the more recent CSS capabilities like flexbox.
I think this is a good idea for personal projects and solo developers. But I've found that as soon as you bring other people on board, you end up spending more time explaining design decisions and dealing with unforeseen complexities related to scale than building features. It's really tempting to go without a framework for sake of simplicity, but you tend to hit a brick wall in productivity until eventually just reinventing the wheel and rolling your own "framework" which can end up an undocumented bespoke nightmare if you aren't extremely careful. I wouldn't equate reducing dependencies with reducing complexity. Good abstractions are what programming is all about.
React - Component Design, Folder Structure, CSS Implementation, Data structuring, Testing Frameworks, Linting Frameworks, GraphQL vs Traditional REST vs GRPC...
It doesn't solve all of your problems like you think it would. You still have onboarding, and you'll always need onboarding.
I spent years using the same stack (bootstrap and knockoutjs) just recently replaced knockout with vuejs and it's been very nice, vuejs and knockout feel like close cousins, the big win has been typescript though, it just catches all those stupid cases (and adds some nice syntax).
I'm primarily a backend developer and definitely have developed a hatred of large frameworks (have been forced to work with Spring and OSGi in the past).
For front-end work, I moved from Backbone/Marionette to mithril about a year ago and love it. I've tried a few of the heavyweight frameworks (Angular, Ember) and absolutely hated them.
if you're already accustomed to python+flask and want to try react, try https://github.com/keredson/bottle-react. (Bottle is a lighter-weight version of Flask.)
> In fact, I'm considering eschewing all front-end
dependencies for my next prototype - ES6 has far better
support in modern browsers than I recall, as do the
more recent CSS capabilities like flexbox.
This is something I have been trying to do a bit on a couple of side projects. The main issue for me is that I would like to avoid to manipulate a lot of DOM from JS, but there is not much alternative to that. Web Components are what I would love to use, but they still miss important functionality (in particular data binding) , so for now I settled in using vue.js for that and "pure" ES6 for all the rest.
(this was a while ago, maybe things have changed meanwhile)
As soon as you are doing more than simple HTML forms, a framework is useful. There are some things that HTML does very well, but you hit the limits on interactive UIs fairly quickly, managing state with plain HTML and HTTP is a pain.
Also, it's possible Ember is bloated. The nice thing about Mithril and some other frameworks is it takes so little to have routing, reusable, components, etc. We're talking 20-30 lines. At that point you are hurting yourself if you have a UI of any complexity and you aren't using a modern approach.
Does the author have any experience with anything but Ember? How interactive are their interfaces? How does the person responsible for UX feel about only using server-side rendering? Did he/she just do a crappy frontend implementation and is now falling back to a fixed mindset rationalization?
I feel like I answered most of these questions on the post, but anyway:
1 - I've tried a number of frameworks, although ember is the only one I've used extensively. As I said, the issue was mostly with the thick client / thin backend api set up rather than specific ember stuff, with the exception of ember being overly opinionated.
2 - not interactive enough to require a js framework
3 - BugMuncher is just me, so I'm also the UX guy and I think server side rendering is awesome
I've found there's a correlation between expertise in a given technology stack and the gravitas given to complaints about that stack.
Having built with all the methods mentioned in the article, I couldn't imagine building a modern web application without a framework (my current preference being Angular 4).
I was recently able to package an entire 30+ view application into a single 650k bundle with webpack. If you tie that kind of app to bare minimum microservices, running off of well planned DB and caching schemas (that can power any interface imaginable), then having to go back to the server for every single micro-view doesn't make sense.
This is doubled... tripled if you think about the effect on mobile page load speed from anything but the best connections.
My point being, it might make more sense to exhaust every avenue and refine your own development skills before writing a generalized, negative leaning blog post on your company's site.
Absolutely not. I've literally never thought while actually coding in 20 years that something would be easier with a framework, not once.
However, almost every day, I think things would be easy without the framework constraints of projects I've inherited.
Often I subvert them because I don't have time for the ceremony and formalities and instead I have actual work to do.
And 100% of the time, without exception, the result is faster, simpler, and more maintainable without the thousands of lines of framework code and the FactoryFactoryProviders tagging along.
Making things as fancy as possible isn't a virtue. It's grossly inept and deeply negligent. They are the antithesis of engineering. the prime objective is to remove complexity and have direct functionality.
I don't see avoiding frameworks is superior to using a microframework like Sinatra. The point of a good framework is it abstracts things that you have to do repeatedly.
You can't really operate without a framework in some domains, if you aren't using an existing one, it's because you've written your own.
at some point it's a debate on definition. To me, a "framework" as a strawman (and unfortunately, usually in reality) has the following features
* hoses the stack trace and makes stepping through code useless and futile
* introduces nearly indistinguishable vague abstract ideas that have very real differences in code that are not well-documented
* changes core api and underlying functionality every few months and breaks backwards compatibility
* makes code action-at-a-distance spaghetti where one task is strewn around multiple files in different directories through some mystical dance of indirection
* is an order of magnitude slower while claiming to be zippy, lightweight, and fast
* constrains and restricts how you can use the language and express your ideas
* rewrites or suppresses core diagnostic, logging, and debugging features built into the language with their own variation (usually called something like EasyLog or SplendidDebug or some nonsense)...
* shoehorns your problem into a very specific and narrow domain
* introduces new configuration files and changes their formats at nearly every version
* does things very naively (such as busy-polling a file to look for changes, pegging a cpu core, instead of using inotify(2))
* has marketing like a new iPhone so everyone is onboard with the hot-newness of it all
* will be dead and abandoned in about 18 months.
It's essentially people who don't know what they're doing trusting other people who don't know what they're doing all surrounded by mountains of hubris
>You can't really operate without a framework in some
>domains, if you aren't using an existing one, it's because
>you've written your own.
Can you share some examples of domains where it's not feasible to operate in without a framework?
I share the GP's experience in that I've never found a framework useful. I have tried some, and even had some forced upon me. But anytime I compare what the framework actually did for me, vs how much I had to fight it to do what I want, I always find I would have been better off not using it.
TL;DR OP chose Ember for a small project, found himself [1] "fighting with Ember a lot", and felt that it would have been easier/quicker to build just a Rails CRUD app in the first place.
This is a standard challenge with any framework, but the issue is especially acute in Javascript-land.
Many JS libraries and frameworks exist to cover missing libraries and functions that would be "batteries included" in other languages. As core JS has evolved (along with CSS), the value of those frameworks decreases, but their legacy is deeply present in Github, StackOverflow discussions, and other libraries.
JQuery is one example: a minuscule wrapper around document.querySelectorAll() plus ES6 arrow functions gets you 75% of the way there, without having to understand how/where JQuery is being "clever" in various event handling corner cases.
Bootstrap is another: flexbox is not perfect, but it replaces a lot of CSS cruft and JS hackery.
Moral: above and beyond the usual tradeoffs for framework decisions, make sure the framework/library is still as relevant today as it was N years ago. Don't just go with inertia.
Well. Inertia is powerful: A new project I start in jQuery today? Next to 100% chance I can pick up a dev who has seen jQuery, even in three or four years. Worldwide.
A new project I start in AngularJS or whatever is the current fad? Good luck if the framework hasn't done yet another BC break or hasn't vanished into oblivion by then.
At this point, I think React seems popular and stable enough that there's not much of a point in going with jQuery for the sake of stability/popularity. And there's still a huge pool of people with AngularJS 1.x experience, too. What's more important, in my opinion, is what tools are going to be easiest for you and/or your current team to get stuff done.
I've seen jquery code that looked like spaghetti, it was very hard to read or change even if you knew jquery. This is the problem that most libraries and frameworks tries to fix. I think react has succeeded.
> JQuery is one example: a minuscule wrapper around document.querySelectorAll() plus ES6 arrow functions gets you 75% of the way there, without having to understand how/where JQuery is being "clever" in various event handling corner cases.
jQuery predates querySelectorAll - that's why it's so popular. It sticks around because now it's to JavaScript what Boost is to C++: things that are needed a lot of the time that the official standard library moves too slowly to add themselves. I don't use jQuery myself anymore, but if the DOM added support for "element collections" and if JavaScript added lodash-style functional methods to all collection types (e.g. if `Array.prototype.map/forEach/filter/etc` worked on NodeList) then we'd be fine.
Most likely will get bashed for it, but.. I absolutely love Angular 1. Productivity is through the roof for me. (caveat, I build small dashboards/automation/tooling frontends). And no fancy build process, sometimes I just work off 2 files (1 HTML, 1 JS)
I am working on a product with multiple engineers and we adopted Reactiflux + SPA + Node + a bunch of fancy tools.
While I love that stack, it took me a while to realize that for most of my side projects, building alone a prototype with all those things is killing my productivity. A messy Rails api with angular1 or even Rails + ERB are way quicker.
Letting go best/latest practices and go for the the non-fancy (and sometimes a bit dirty) way is harder than it seems.
> I used quite an early beta of Ember to build BugMuncehr’s new feedback interface.
> I wanted to add a full REST API to BugMuncher, even though no-one had asked for it.
> I committed to using Ember before I knew enough about it.
> I didn’t keep it simple, I was stupid.
> Web apps often look complicated from the outsite, but underneath most of what they do is simply Create Read Update Delete, and you really don’t need a fancy JavaScript framework to do that.
So, to summarize, you failed at your first usage of a JavaScript framework due to your own bad decisions. Therefore, all the benefits SPA structure can offer the multitude of other projects is meaningless as, "...most of what they do is simply Create Read Update Delete." Honestly, you've just swapped the bandwagon effect for confirmation bias as you fell back to Rails.
I never said "all the benefits SPA structure can offer the multitude of other projects" were meaningless, in fact I specifically said there's a time and place for them. My point was most web apps, particularly an SaaS control panel, may be better served with a simple CRUD app
> I never said "all the benefits SPA structure can offer the multitude of other projects" were meaningless, in fact I specifically said there's a time and place for them.
No, you said:
> There’s a time and a place for JavaScript frameworks, and whatever it is you’re building probably isn’t it.
Do tell us when a SPA structure is appropriate... Then, explain how that sentiment is any less "arrogant" than Ember.
Yeah I feel guilty and also not hired full time, currently using plain LAMP and freelance, but I can develop with it. In particular with WordPress, I'm able to open plugins read the code and change/add to them. Speed of development too. But yeah... Starting to learn Angular will decide which PHP Framework... Throw Go in there too. Damn... Gotta catch up.
Edit: I don't personally use WordPress but saying the stack is LAMP/LEMP so I can work with it. It's just a matter of dealing with the random unclosed PHP tags and figuring out the interconnected classes. It's good for learning how to structure code I still have to use classes myself but assume I need a reason to use object oriented like a video game.
Same with implementing personal GIT server and CI/CD design.
One thing, I imemented defuse/php-encryption recently with memcache was watching the server's htop and see the php-fpm pool requests appear in the processes neat.
So far using Angular CLI, the real time updating is sweet, also the event bindings loops on what appear to be HTML... Yeah gotta spend more time on it this Angular 4 in 60 minutes was a good intro but gotta use it.
I was slightly confused at first I thought rxjs was React nevermind haha.
Thanks for the insight. I don't know it may be bad I'd like to get hired and everytime I check indeed I keep seeing Angular. so I should learn it but not arguing with faster dev, secure, best practices...
Was thinking too what's the difference with being hired somewhere versus getting your own clients... I don't know. Good to be single
Also I don't have a car to get to the jobs so... I'm thinking I'd rather have the "burn rate" and work online/learn more in the mean time. Do my 2 days restaurant work.
Edit: sorry rambling, I love this freedom, work, sleep whenever. I don't have a sleep pattern and sometimes can't sleep at all. Then I can crawl into a dark spot and sleep almost an entire day. Still surreal getting paid from the internet.
I couldn't tell the difference. Offhand it seems nuts like when you create a project and it builds all the folders. I am under the impression to deploy you just move the folders over... Something said somewhere "they're just static files" unless you're using postgresql or something as well. Yeah... Man I'm behind.
Good thought but I am not sure if OP's examples illustrate his thought well.
Same thought, another example: I like React + its ecosystem quite a lot but often, no, actually most of the times, I realize that I don't need React because the project I am just building is more or less kind of a landing page with some simple UI.
Then, I rather use Pug (former Jade) + Stylus + Node. Super simple, proven and you can go quite far.
Sounds a bit like crying to me. You built something using a framework and it didn't workout, "so what", rebuild it again. What's next, another blog post about why Rails wasn't right either because of scaling issues? There is no write once and live forever model. Build what you need today, learn, and if you have to rewrite it 10 times then do it.
Frameworks save people time. Not every framework is perfect or maybe 90% of the functionality is never used, but alot of good stuff that solves problems. Maybe the lack of research on your part before you chose something like ember is the real root cause, or maybe the lack of building a proof of concept to determine if ember was the right choice before yapping about your own failure with a framework that you really don't know.
However, please do enumerate all the wheels you'll be reinventing if you choose not to.
If you do choose a framework, please make sure it covers most of the requirements of your project. If it doesn't, or you're not sure, then maybe you don't understand something so ask for help.
There are server-side libraries like Unpoly (https://unpoly.com/) that give you most of the benefits of heavyweight JavaScript frameworks, but without the complexity and code duplication.
I am surprised at the number of people who think they can do everything without a framework and that everything would just be better if they weren't weighed down by the horrible affliction of using one. Frameworks provide real value and while not required for many small applications they can be a huge advantage in large enterprise applications.
For example if you are using Ember you gain the advantage of a client-side ORM called Ember Data which handles caching and cache invalidation for your API data. Did you handle that in your non-framework application? If you did, how long did it take you to implement? How well tested is it? How many developers besides yourself have reviewed it? How much documentation did you write and how long does it take to bring new developers up to speed on it? If it breaks, who will fix it?
Multiply that by ten or twenty depending on the framework and you start to see what the benefits are.
> Having separate codebases for the API, control panel and feedback interface seemed like a good idea, but in reality it just meant more software with more dependencies to keep updated, more tests to run, and a much more complicated deployment process.
Huh? What am I missing here? He made the mistake of creating separate code bases blames it on using a Javascript framework? He could have kept in in the same code base just like using Javascript without a framework.
He then complains about Ember and that's all the explanation we get for why Javascript frameworks are bad. That paragraph didn't even remotely answer the question.
> Even if I was a seasoned pro with Ember, it’s still a case of two frameworks vs one, two codebases vs one, two test suites, two deployments processes, you get the idea.
He makes the same argument again but even worse. Why do you need 2 codebases and 2 deployment processes? You don't. I still don't get how this has anything to do with Javascript frameworks. Sure, you need 2 test suites, but you also do without a Javascript framework.
I do agree that more code bases and deployment processes is more complicated, but has absolutely nothing to do with Javascript frameworks.
I looked at a lot of them at todomvc.com and decided I didn't want or need a framework. Instead I chose to use Apache web server, CouchDB, PouchDB, jQuery, and Bootstrap.
I chose those tools after boiling my brain over which of the JS Frameworks there was "best" and really couldn't come to a conclusion.
After a few beers one night it occurred to me that maybe I should look for what was "easiest for me" instead and that changed how I looked at it entirely.
56 comments
[ 1.9 ms ] story [ 88.5 ms ] threadFor the past several years I've started new personal projects with PostgreSQL+Python+[Flask|Django] on the backend and Bootstrap+Knockout on the frontend. I recently tried to start a new project with React instead, and while the actual act of development on a working React-based codebase is fairly nice, getting it to that state apparently requires a load of dependencies that I simply wasn't prepared for.
I retreated back to using Bootstrap alone for the prototype and found it much easier to work with than I remember. I'm sure part of that is that I've gained a ton of experience since I last used jQuery without a UX framework like Knockout, Ember, or React - but part of it also seems to be that browsers have come a long way since then.
In fact, I'm considering eschewing all front-end dependencies for my next prototype - ES6 has far better support in modern browsers than I recall, as do the more recent CSS capabilities like flexbox.
I figure that at best I'll have a lightweight, clean project that works well enough for a prototype; at worst I'll learn a lot about where modern web standards are.
I think this is a good idea for personal projects and solo developers. But I've found that as soon as you bring other people on board, you end up spending more time explaining design decisions and dealing with unforeseen complexities related to scale than building features. It's really tempting to go without a framework for sake of simplicity, but you tend to hit a brick wall in productivity until eventually just reinventing the wheel and rolling your own "framework" which can end up an undocumented bespoke nightmare if you aren't extremely careful. I wouldn't equate reducing dependencies with reducing complexity. Good abstractions are what programming is all about.
React - Component Design, Folder Structure, CSS Implementation, Data structuring, Testing Frameworks, Linting Frameworks, GraphQL vs Traditional REST vs GRPC...
It doesn't solve all of your problems like you think it would. You still have onboarding, and you'll always need onboarding.
For front-end work, I moved from Backbone/Marionette to mithril about a year ago and love it. I've tried a few of the heavyweight frameworks (Angular, Ember) and absolutely hated them.
> (Bottle is a lighter-weight version of Flask.)
Well, technically, Flask is a parody of Bottle that accidentally turned into a real library. :)
http://web.archive.org/web/20100406024359/http://denied.imme...
This is something I have been trying to do a bit on a couple of side projects. The main issue for me is that I would like to avoid to manipulate a lot of DOM from JS, but there is not much alternative to that. Web Components are what I would love to use, but they still miss important functionality (in particular data binding) , so for now I settled in using vue.js for that and "pure" ES6 for all the rest.
(this was a while ago, maybe things have changed meanwhile)
Also, it's possible Ember is bloated. The nice thing about Mithril and some other frameworks is it takes so little to have routing, reusable, components, etc. We're talking 20-30 lines. At that point you are hurting yourself if you have a UI of any complexity and you aren't using a modern approach.
1 - I've tried a number of frameworks, although ember is the only one I've used extensively. As I said, the issue was mostly with the thick client / thin backend api set up rather than specific ember stuff, with the exception of ember being overly opinionated.
2 - not interactive enough to require a js framework
3 - BugMuncher is just me, so I'm also the UX guy and I think server side rendering is awesome
4 - no (in my own humble opinion)
Why is server-side rendering awesome?
I've only found that:
1. It consumes a lot of server CPU that's of limited capacity
2. It's often slower than rendering on the client (Since the client usually isn't under load)
3. You loose interactivity in the browser because you have to reload the whole DOM on every new page
Have to say, that's quite impressive :)
Having built with all the methods mentioned in the article, I couldn't imagine building a modern web application without a framework (my current preference being Angular 4).
I was recently able to package an entire 30+ view application into a single 650k bundle with webpack. If you tie that kind of app to bare minimum microservices, running off of well planned DB and caching schemas (that can power any interface imaginable), then having to go back to the server for every single micro-view doesn't make sense.
This is doubled... tripled if you think about the effect on mobile page load speed from anything but the best connections.
My point being, it might make more sense to exhaust every avenue and refine your own development skills before writing a generalized, negative leaning blog post on your company's site.
It was beautiful.
http://vanilla-js.com/
However, almost every day, I think things would be easy without the framework constraints of projects I've inherited.
Often I subvert them because I don't have time for the ceremony and formalities and instead I have actual work to do.
And 100% of the time, without exception, the result is faster, simpler, and more maintainable without the thousands of lines of framework code and the FactoryFactoryProviders tagging along.
Making things as fancy as possible isn't a virtue. It's grossly inept and deeply negligent. They are the antithesis of engineering. the prime objective is to remove complexity and have direct functionality.
You can't really operate without a framework in some domains, if you aren't using an existing one, it's because you've written your own.
* hoses the stack trace and makes stepping through code useless and futile
* introduces nearly indistinguishable vague abstract ideas that have very real differences in code that are not well-documented
* changes core api and underlying functionality every few months and breaks backwards compatibility
* makes code action-at-a-distance spaghetti where one task is strewn around multiple files in different directories through some mystical dance of indirection
* is an order of magnitude slower while claiming to be zippy, lightweight, and fast
* constrains and restricts how you can use the language and express your ideas
* rewrites or suppresses core diagnostic, logging, and debugging features built into the language with their own variation (usually called something like EasyLog or SplendidDebug or some nonsense)...
* shoehorns your problem into a very specific and narrow domain
* introduces new configuration files and changes their formats at nearly every version
* does things very naively (such as busy-polling a file to look for changes, pegging a cpu core, instead of using inotify(2))
* has marketing like a new iPhone so everyone is onboard with the hot-newness of it all
* will be dead and abandoned in about 18 months.
It's essentially people who don't know what they're doing trusting other people who don't know what they're doing all surrounded by mountains of hubris
Can you share some examples of domains where it's not feasible to operate in without a framework?
I share the GP's experience in that I've never found a framework useful. I have tried some, and even had some forced upon me. But anytime I compare what the framework actually did for me, vs how much I had to fight it to do what I want, I always find I would have been better off not using it.
This is a standard challenge with any framework, but the issue is especially acute in Javascript-land.
Many JS libraries and frameworks exist to cover missing libraries and functions that would be "batteries included" in other languages. As core JS has evolved (along with CSS), the value of those frameworks decreases, but their legacy is deeply present in Github, StackOverflow discussions, and other libraries.
JQuery is one example: a minuscule wrapper around document.querySelectorAll() plus ES6 arrow functions gets you 75% of the way there, without having to understand how/where JQuery is being "clever" in various event handling corner cases.
Bootstrap is another: flexbox is not perfect, but it replaces a lot of CSS cruft and JS hackery.
Moral: above and beyond the usual tradeoffs for framework decisions, make sure the framework/library is still as relevant today as it was N years ago. Don't just go with inertia.
[1] The author's name is "Matt".
Well. Inertia is powerful: A new project I start in jQuery today? Next to 100% chance I can pick up a dev who has seen jQuery, even in three or four years. Worldwide.
A new project I start in AngularJS or whatever is the current fad? Good luck if the framework hasn't done yet another BC break or hasn't vanished into oblivion by then.
Instead of choosing JQuery (on inertia) or the current fad, consider just using current base language features and best practices.
It might be a better choice.
As a bonus, to your point, you're then far less worried about finding future devs with your library/framework-specific experience.
jQuery predates querySelectorAll - that's why it's so popular. It sticks around because now it's to JavaScript what Boost is to C++: things that are needed a lot of the time that the official standard library moves too slowly to add themselves. I don't use jQuery myself anymore, but if the DOM added support for "element collections" and if JavaScript added lodash-style functional methods to all collection types (e.g. if `Array.prototype.map/forEach/filter/etc` worked on NodeList) then we'd be fine.
> [1] The author's name is "Matt".
I hate to say it but these days you just can't assume the previously obvious.
While I love that stack, it took me a while to realize that for most of my side projects, building alone a prototype with all those things is killing my productivity. A messy Rails api with angular1 or even Rails + ERB are way quicker.
Letting go best/latest practices and go for the the non-fancy (and sometimes a bit dirty) way is harder than it seems.
> I wanted to add a full REST API to BugMuncher, even though no-one had asked for it.
> I committed to using Ember before I knew enough about it.
> I didn’t keep it simple, I was stupid.
> Web apps often look complicated from the outsite, but underneath most of what they do is simply Create Read Update Delete, and you really don’t need a fancy JavaScript framework to do that.
So, to summarize, you failed at your first usage of a JavaScript framework due to your own bad decisions. Therefore, all the benefits SPA structure can offer the multitude of other projects is meaningless as, "...most of what they do is simply Create Read Update Delete." Honestly, you've just swapped the bandwagon effect for confirmation bias as you fell back to Rails.
No, you said:
> There’s a time and a place for JavaScript frameworks, and whatever it is you’re building probably isn’t it.
Do tell us when a SPA structure is appropriate... Then, explain how that sentiment is any less "arrogant" than Ember.
I'm doing some projects using only React/React Native and static edn files to load the data and it has been a great experience.
Actually, probably not. It's trivially easy to create a simple Python web application using only Werkzeug, or even using WSGI directly.
Edit: I don't personally use WordPress but saying the stack is LAMP/LEMP so I can work with it. It's just a matter of dealing with the random unclosed PHP tags and figuring out the interconnected classes. It's good for learning how to structure code I still have to use classes myself but assume I need a reason to use object oriented like a video game.
Same with implementing personal GIT server and CI/CD design.
One thing, I imemented defuse/php-encryption recently with memcache was watching the server's htop and see the php-fpm pool requests appear in the processes neat.
So far using Angular CLI, the real time updating is sweet, also the event bindings loops on what appear to be HTML... Yeah gotta spend more time on it this Angular 4 in 60 minutes was a good intro but gotta use it.
Thanks for the insight. I don't know it may be bad I'd like to get hired and everytime I check indeed I keep seeing Angular. so I should learn it but not arguing with faster dev, secure, best practices...
Was thinking too what's the difference with being hired somewhere versus getting your own clients... I don't know. Good to be single
Also I don't have a car to get to the jobs so... I'm thinking I'd rather have the "burn rate" and work online/learn more in the mean time. Do my 2 days restaurant work.
Edit: sorry rambling, I love this freedom, work, sleep whenever. I don't have a sleep pattern and sometimes can't sleep at all. Then I can crawl into a dark spot and sleep almost an entire day. Still surreal getting paid from the internet.
Thanks
Same thought, another example: I like React + its ecosystem quite a lot but often, no, actually most of the times, I realize that I don't need React because the project I am just building is more or less kind of a landing page with some simple UI.
Then, I rather use Pug (former Jade) + Stylus + Node. Super simple, proven and you can go quite far.
Frameworks save people time. Not every framework is perfect or maybe 90% of the functionality is never used, but alot of good stuff that solves problems. Maybe the lack of research on your part before you chose something like ember is the real root cause, or maybe the lack of building a proof of concept to determine if ember was the right choice before yapping about your own failure with a framework that you really don't know.
However, please do enumerate all the wheels you'll be reinventing if you choose not to.
If you do choose a framework, please make sure it covers most of the requirements of your project. If it doesn't, or you're not sure, then maybe you don't understand something so ask for help.
For example if you are using Ember you gain the advantage of a client-side ORM called Ember Data which handles caching and cache invalidation for your API data. Did you handle that in your non-framework application? If you did, how long did it take you to implement? How well tested is it? How many developers besides yourself have reviewed it? How much documentation did you write and how long does it take to bring new developers up to speed on it? If it breaks, who will fix it?
Multiply that by ten or twenty depending on the framework and you start to see what the benefits are.
> Having separate codebases for the API, control panel and feedback interface seemed like a good idea, but in reality it just meant more software with more dependencies to keep updated, more tests to run, and a much more complicated deployment process.
Huh? What am I missing here? He made the mistake of creating separate code bases blames it on using a Javascript framework? He could have kept in in the same code base just like using Javascript without a framework.
He then complains about Ember and that's all the explanation we get for why Javascript frameworks are bad. That paragraph didn't even remotely answer the question.
> Even if I was a seasoned pro with Ember, it’s still a case of two frameworks vs one, two codebases vs one, two test suites, two deployments processes, you get the idea.
He makes the same argument again but even worse. Why do you need 2 codebases and 2 deployment processes? You don't. I still don't get how this has anything to do with Javascript frameworks. Sure, you need 2 test suites, but you also do without a Javascript framework.
I do agree that more code bases and deployment processes is more complicated, but has absolutely nothing to do with Javascript frameworks.
I chose those tools after boiling my brain over which of the JS Frameworks there was "best" and really couldn't come to a conclusion.
After a few beers one night it occurred to me that maybe I should look for what was "easiest for me" instead and that changed how I looked at it entirely.